Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Sorted feature list is easier to review or compare.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*po*: regenerated

Commit id 'cd490086' added a VIR_FORCE_CLOSE of the 'sock', but it
was after the VIR_FREE() of phyp_driver, resulting in a possible/likely
NULL dereference.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIDriverDir to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIDriverFile to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIFile to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:

  virsh # start --console test
  error: Reconnected to the hypervisor
  error: Failed to start domain test
  error: internal error: guest failed to start: unexpected exit status 125

So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:

static virCommandPtr
virLXCProcessBuildControllerCmd(virLXCDriverPtr driver,
                                ..
                                int logfd,
                                const char *pidfile)
{
    ...
    virCommandSetOutputFD(cmd, &logfd);
    virCommandSetErrorFD(cmd, &logfd);
    ...
}

Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.

In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.

The bug was introduced in e1de5521.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit id 'f967e7a6' didn't place the closing parentheses quite right
causing DEADCODE errors since the rc setting/comparison was wrong.

Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.

The memory device hot(un)plug was missing calls to the auditing code.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1226234

Since the balloon driver does not guarantee that it returns memory to
the host, using the value in the audit message is not a good idea.

This patch removes auditing from updating the balloon size and reports
the total physical size at startup.

The code which generates paths for UNIX socket blindly used target name
without checking if it was set. Thus for the following device XML

    <channel type='unix'>
      <source mode='bind'/>
      <target type='virtio'/>
    </channel>

we would generate "/var/lib/libvirt/qemu/channel/target/NAME.(null)"
path which works but is not really correct. Let's not use the
".target_name" suffix at all if target name is not set.

https://bugzilla.redhat.com/show_bug.cgi?id=1226854Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

While CPU0 was made unpluggable in Linux a while ago it's not desirable
to unplug it since some parts of the kernel (suspend-to-ram) still
depend on it.

This patch fixes the vCPU selection code in libvirt so that it will not
be disabled.

Signed-off-by: NLuyao Huang <lhuang@redhat.com>

The target type comparison in qemuDomainDetachChrDevice
used the VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE enum, so virtio-serial
addresses were not freed properly for channel devices.

Call qemuDomainReleaseDeviceAddress uncoditionally and decide
based on the address type instead of the target/device types.

Also check the device type when deciding what type the address should
be. Commit 9807c471 (aiming to fix another error in address allocation)
only checked the target type, but its value is different for different
device types. This resulted in an error when trying to attach
a channel with target type 'virtio':

error: Failed to attach device from channel-file.xml
error: internal error: virtio serial device has invalid address type

Make the logic for releasing the address dependent only on
* the address type
* whether it was allocated earlier
to avoid copying the device and target type checks.

https://bugzilla.redhat.com/show_bug.cgi?id=1230039Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

def->vcpus was never updated after successfully changing the live
vcpu count of a domain. Subsequent queries for vcpu info would
return incorrect results.  E.g.:

virsh vcpucount test
maximum      config         4
maximum      live           4
current      config         4
current      live           4

virsh setvcpus test 2

virsh vcpucount test
maximum      config         4
maximum      live           4
current      config         4
current      live           4

After patch, live current config is reported correctly:

virsh vcpucount test
maximum      config         4
maximum      live           4
current      config         4
current      live           2

While fixing this, noticed that the live config was not saved
to cfg->stateDir via virDomainSaveStatus. Save the live config
and change error handling of virDomainSave{Config,Status} to
log a message via VIR_WARN, instead of failing the entire
DomainSetVcpusFlags operation.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The libxl driver always uses virDomainObj->def when formatting
the domain XML description.  Use virDomainObj->newDef when
--inactive flag is set.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

libxlDomainCreateXML() would remove a persistent domain if
libxlDomainStart() failed.  Check if domain is persistent
before removing.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

When restarting libvirtd and reconnecting to running domains,
libxlReconnectDomain() would unconditionally set the domain state
to VIR_DOMAIN_RUNNING, overwriting the state maintained in
$statedir/<domname>.xml.  A domain in a paused state would have
the state changed to running, even though it was actually in a
paused state.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1201760

When the domain "<on_crash>coredump-destroy</on_crash>" is set, the
domain wasn't being destroyed, rather it was being rebooted.

Add VIR_DOMAIN_LIFECYCLE_CRASH_COREDUMP_DESTROY to the list of
on_crash types that cause "-no-reboot" to be added to the qemu
command line.