Running shutdown with mode agent on a shutoff domain gives cryptic
error message:

    virsh # shutdown --mode agent gentoo
    error: Failed to shutdown domain gentoo
    error: Guest agent is not responding: QEMU guest agent is not connected

After this patch, the error is more clear:

    virsh # shutdown --mode agent gentoo
    error: Failed to shutdown domain gentoo
    error: Requested operation is not valid: domain is not running
Reported-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Upping an interface for no reason and not configuring it is a cardinal sin.

With the default addrgenmode if eui64 it sticks a link-local address to the
interface. That is not good, as NetworkManager would see an address configured,
assume the interface is already configured and won't touch it iself and the
interface might stay unconfigured until the end of the days.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1124721Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Allow ccw devices to be used with multiqueues. ccw provides a one to
one relation of fds to queues and does not support the vectors option.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

Coverity points out that qemuMonitorGetAllBlockStatsInfo could return a
-1 and thus not fill in 'stats' (leaving it NULL). Then the call to
qemuMonitorBlockStatsUpdateCapacity will dereference it.

Coverity complains over the [n]values pairing in virQEMUCapsFreeStringList
and rather than make a bunch if "if values" checks prior to calling, by
just adding the values check inside the free function we avoid the chance
that somehow nvalues is > 0, while values == NULL

Coverity points out it was possible to have a zero return from
qemuBuildRNGBackendProps thus not filling in 'props' and then
causing a NULL dereference on the next call.

Coverity found that xenXMConfigCacheAddFile has an error path in which
no error message and a -1 was not returned which could have resulted in
a NULL dereference in a VIR_DEBUG statement and of course an erroneous
0 value returned!

Coverity notes that ->ifname is used after the VIR_FREE done in the
code path after the call to virNetDevMacVLanDeleteWithVPortProfile
by a call to virNetDevOpenvswitchRemovePort.

Since the ->ifname will be VIR_FREE()'d eventually in virDomainNetDefFree
just remove the extraneous VIR_FREE here.

When originally added, the Openvswitch code wasn't present and checks
were made for non NULL prior to use.

Coverity complains that in the error paths both the < 0 condition and
the success path after the qemuDomainObjExitMonitor failure will end
up going to cleanup.  So just use ignore_value in this error path to
resolve the complaint.

If the virStringSearch() returns a 0 (zero), then each of the uses
of the call will just jump to cleanup forgetting to free the returned
empty list. Expand the scope a bit of each use and free at cleanup.

The returned socks from virNetSocketNewListenTCP needs to be VIR_FREE'd
as well as seach of the Close/Unref on all the socks[i] that is
already done

The xend driver and the parsing/formating code in src/xenconfig
have long supported soundhw.  Add support in the libxl driver too.

Add logrotate config for log files in /var/log/libvirt/libxl.

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

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

We had a check for the vcpu count total number in <numa>
before, however this check is not good enough. There are
some examples:

1. one of cpu id is out of maxvcpus, can set success(cpu count = 5 < 10):

<vcpu placement='static'>10</vcpu>
<cell id='0' cpus='0-3,100' memory='512000' unit='KiB'/>

2. use the same cpu in 2 cell, can set success(cpu count = 8 < 10):
<vcpu placement='static'>10</vcpu>
<cell id='0' cpus='0-3' memory='512000' unit='KiB'/>
<cell id='1' cpus='0-3' memory='512000' unit='KiB'/>

3. use the same cpu in 2 cell, cannot set success(cpu count = 11 > 10):
<vcpu placement='static'>10</vcpu>
<cell id='0' cpus='0-6' memory='512000' unit='KiB'/>
<cell id='1' cpus='0-3' memory='512000' unit='KiB'/>

Add a check for numa cpus, check if duplicate use one cpu in more
than one cell.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The only version that's supported in QEMU is version 2, currently.
Fortunately, it is enabled by aarch64 automatically, so there's
nothing for us that needs to be put onto command line.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some platforms, like aarch64, don't have APIC but GIC. So there's
no reason to have <apic/> feature turned on. However, we are
still missing <gic/> feature. This commit introduces the feature
to XML parser and formatter, adds documentation and updates RNG
schema.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When migrating a domain while changing its name and using
VIR_MIGRATE_PERSIST_DEST flag, libvirt would fail to properly change the
name in the persistent definition. The inconsistency results in weird
behavior when dumping domain XML, destroying the domain, restarting
libvirtd and likely in several other situations.

Since the new name is already stored in vm->def->name, we just need to
make sure the persistent definition uses this new name too.

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

Many users, who admin their own machines, want to be able to access
system libvirtd via tools like virt-manager without having to enter
a root password. Just google 'virt-manager without password' and
you'll find many hits. I've read at least 5 blog posts over the years
describing slightly different ways of achieving this goal.

Let's finally add official support for this.

Install a polkit-1 rules file granting password-less auth for any user
in the new 'libvirt' group. Create the group on RPM install

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

Currently we try to chown any directory passed to virDirCreate,
even if the user didn't request any explicit owner/group via the
pool/vol XML.

This causes issues with qemu:///session: try to build a pool of
a root owned directory like /tmp, and it fails trying to chown the
directory to the session user. Instead it should just leave things
as they are, unless the user requests changing permissions via
the pool XML.

Similarly this is annoying if creating a storage pool via system
libvirtd of an existing directory in user $HOME, it's now owned
by root.

The virDirCreate function is pretty convoluted, since it needs to
fork off in certain specific cases. Try to document that, to make
it clear where exactly we are changing behavior.

The current code attempts to handle this, but it only catches mkdir
failing with EEXIST. However if say trying to build /tmp for an
unprivileged qemu:///session, mkdir will fail with EPERM.

Rather than catch any errors, just don't attempt mkdir if the directory
already exists.

This means pool XML actually reports accurate user/group/mode/label.

This uses UpdateVolTargetInfoFD in a bit of a hackish way, but it works

virDirCreate will give us fine grained details about what actually failed.

Just pass anything a user specified to the appropriate API. It's the API
or libvirtd that should be responsible for checking its parameters.

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

Neither migrate URI nor lister address make any sense for tunnelled
migration.

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

Replace all occurrences of "stream write to differences to"
with "stream to write differences to".

Check that the vmport feature is correctly used in qemu commande line.

Fill qemu command line vmport argument as required.

The vmport machine argument works with pc machine kind, not with xen for
example.

Move common functions being used by the following
virQEMUCapsSupportsVmport commit.

Set the capability based on qmp query, or qemu version.  The qmp query
includes vmport with 2.2, but no longer with 2.3. It lists only
non-machine specific capabilities, so check the qemu version too until a
machine-specific query is supported.

A new feature that can be turned on or off.

The QEMU machine vmport option allows to set the VMWare IO port
emulation. This emulation is useful for absolute pointer input when the
guest has vmware input drivers, and is enabled by default for kvm.

However it is unnecessary for Spice-enabled VM, since the agent already
handles absolute pointer and multi-monitors. Furthermore, it prevents
Spice from switching to relative input since the regular ps/2 pointer
driver is replaced by the vmware driver. It is thus advised to disable
vmport when using a Spice VM. This will permit the Spice client to
switch from absolute to relative pointer, as it may be required for
certain games or applications.

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

Jump to endjob instead of cleanup to fix this deadlock.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

The --maximum option wasn't properly parsed and the equivalent flag
wasn't set.  Fix this bug and also rewrite the way we check this option
by using new macro.  The new approach is that --maximum requires
--config, no other combination is allowed, because they don't make sense.

The new error will be:

 # virsh setvcpus test --maximum 10
 error: Option --config is required by option --maximum

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1204033Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Now that we have macros for exclusive flags and flag requirements we can
use them to cleanup the code for setvcpus and error out for all wrong
flag combination.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>