Do not check for border iterator values inside the loop,
move the code before/after the loop instead.

It is used to break out of the loop early if one regex does not match.
Use the 'break' statement instead.

In all other drivers we are doing so. Moreover, we don't want to parse
runtime information in attach (even if the attach is meant as live)
because we are generating the runtime info ourselves. We can't trust
users they supply sane values anyway.

==1140== 9 bytes in 1 blocks are definitely lost in loss record 72 of 1,151
==1140==    at 0x4A06C2B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1140==    by 0x623C758: xmlStrndup (in /usr/lib64/libxml2.so.2.9.1)
==1140==    by 0x50FD763: virXMLPropString (virxml.c:483)
==1140==    by 0x510F8B7: virDomainDeviceInfoParseXML (domain_conf.c:3685)
==1140==    by 0x511ACFD: virDomainChrDefParseXML (domain_conf.c:7535)
==1140==    by 0x5121D13: virDomainDeviceDefParse (domain_conf.c:9918)
==1140==    by 0x13AE6313: qemuDomainAttachDeviceFlags (qemu_driver.c:6926)
==1140==    by 0x13AE65FA: qemuDomainAttachDevice (qemu_driver.c:7005)
==1140==    by 0x51C77DA: virDomainAttachDevice (libvirt.c:10231)
==1140==    by 0x127FDD: remoteDispatchDomainAttachDevice (remote_dispatch.h:2404)
==1140==    by 0x127EC5: remoteDispatchDomainAttachDeviceHelper (remote_dispatch.h:2382)
==1140==    by 0x5241F81: virNetServerProgramDispatchCall (virnetserverprogram.c:437)

When doing live attach, we are passing the inactive definition anyway
since we are passing the result of virDomainDeviceDefCopy() which does
inactive copy by default.

Moreover, we are doing the same mistake in qemuhotplugtest.

Just a side note - it makes perfect sense to parse the runtime info
like alias in qemuDomainDetachDevice and qemuDomainUpdateDeviceFlags()
as in some cases the only difference to distinguish two devices can be
just their alias.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The test is loosely inspired from qemucapabilitiestest
and qemuxml2xmltest.

Added a new test instead of extending an existing one because
the feature being tested don't really fits nicely in any
existing place.

This patch decouples the binary and the capabilities detection
from the guest initialization.

The purpose is to make testing easier.

This patch adds an element to QEMU's capability XML, to
show if the underlying QEMU binary supports the live disk
snapshotting or not.
This allows any client to know ahead of time if the feature
is available.

Without this information available, the only way to check
for the snapshot support is to request one and check for
errors.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

Currently, the Linux kernel treats values of '0' and '1' as
the minimum of 2. Values larger than the maximum are changed
to the maximum.

Re-reading the shares value after setting it reflects this in
the live domain XML.

Currently, <cputune><shares>0</shares></cputune> is treated
as if it were not specified.

Treat is as a valid value if it was explicitly specified
and write it to the cgroups.

On error the lofd would have been leaked.

Recent changes in the module seemed to have caused Coverity to reanalyze
certain parts of the code. Previously the code was modified via commit
id '11a11812' to resolve a different error (perhaps DEADCODE).  Up through
commit id '7b3f1f8c' there were no issues.

The new error indicats the 'outbuf' was checked for NULL and then complains
because of the dereference. Adding checks for non-NULL prior to the deref
resulted in a DEADCODE message.

So, resolve using an sa_assert() to keep Coverity quiet especially since
it doesn't understand that outbuf will change as a result of a successful
virCommandRun() call.

Recent changes to the module seemed to have caused Coverity to find a new
issue regarding the failure to check the return from a sendmsg. The code
doesn't seem to care about the return status, so just added an ignore_value
to keep Coverity quiet.

qemuDomainSetSchedulerParametersFlags() calls virQEMUDriverGetConfig() twice
and makes the reference counter leak. This removes redundant call.

Problem introduced in commit 45ad1adbSigned-off-by: NEric Blake <eblake@redhat.com>

We use virBhyveTapGetRealDeviceName() to map network interface name
to a real device path, trying to open possible devices and getting
names by ioctl.

Make it skip devices that fail to open with EBUSY because they're
most likely already used by other VMs.

Commit d9f19c30 moved a lot of the
configuration setup into libxlDriverConfigNew().
However that tries to create the libxl/libxl-driver.log before the
libxl directory gets created in libxlStateInitialize().

This causes the daemon to fail on systems that have not had the directory
created before.

Move the code to create the libxl directory into libxlDriverConfigNew().
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

Indent top-level labels by one space.

Add the rule to HACKING and enforce it by syntax-check.

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

When lock failure is detected by sanlock, our sanlock_helper kill script
will try to restart (shutdown followed by start) the affected domain
when RESTART action is configured for it. While shutting down kills QEMU
and removes all its leases (which is what sanlock wants to happen),
trying to start it again just hangs because libvirt tries reacquire the
locks in the failed lock space. Hence, this action cannot be supported
by sanlock driver.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Sanlock expects that the configured kill script either kills the PID on
lock failure or removes all locks the PID owns. If none of the two
options happen, sanlock will reboot the host. Although IGNORE action is
supposed to ignore the request to kill the PID or remove all leases,
it's certainly not designed to cause the host to be rebooted. That said,
IGNORE action is incompatible with sanlock and should be forbidden by
libvirt.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>