Migration to an older libvirt (pre v1.3.0-175-g71408079) is broken
because older versions of libvirt generated different channel paths and
they didn't drop the default paths when parsing domain XMLs. We'd get
such a nice error message:

    internal error: process exited while connecting to monitor:
    2016-07-08T15:28:02.665706Z qemu-kvm: -chardev socket,
    id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/
    domain-3-nest/org.qemu.guest_agent.0,server,nowait: Failed to bind
    socket to /var/lib/libvirt/qemu/channel/target/domain-3-nest/
    org.qemu.guest_agent.0: No such file or directory

That said, we should not even format the default paths when generating a
migratable XML.

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

Playing directly with our live definition, updating it, and reverting it
back once we are done is very nice and it's quite dangerous too. Let's
just make a copy of the domain definition if needed and do all tricks on
the copy.

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

If size_t is the same size as long long, then we can skip
some of the range checks. This avoids triggering some
bogus compiler warning messages.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virConf 'l' field is a 'signed long long', so whenever
the 'type' field is VIR_CONF_ULONG, we should explicitly cast
'l' to a 'unsigned long long' before doing range checks.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This function tries to get a ssize_t value from a config file.
But before returning it, it checks whether the value would fit in
ssize_t and if not an error is printed out among with the range
for the ssize_t type. However, on some platforms SSIZE_MAX may
actually be a signed long type:

util/virconf.c: In function 'virConfGetValueSSizeT':
util/virconf.c:1268:9: error: format '%zd' expects argument of type 'signed size_t', but argument 9 has type 'long int' [-Werror=format=]
         virReportError(VIR_ERR_INTERNAL_ERROR,
         ^
$ grep -r SSIZE_MAX /usr/include/
/usr/include/bits/posix1_lim.h:#ifndef  SSIZE_MAX
/usr/include/bits/posix1_lim.h:# define SSIZE_MAX       LONG_MAX
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Revert the remainder of commit id 'c8438010'

MinGW complained that we might be dereferencing a NULL pointer.  While
that can't be true, the logic certainly allows for that.

../../src/conf/domain_conf.c: In function 'virDomainDefPostParse':
../../src/conf/domain_conf.c:4224:18: error: potential null pointer dereference [-Werror=null-dereference]
         if (!vcpu->online && vcpu->cpumask) {
              ~~~~^~~~~~~~
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

MinGW complained that we might be dereferencing a NULL pointer.  While
that can't be true, the logic certainly allows for that.

src/conf/domain_conf.c: In function 'virDomainDefGetVcpuPinInfoHelper':
src/conf/domain_conf.c:1545:17: error: potential null pointer dereference [-Werror=null-dereference]
         if (vcpu->cpumask)
              ~~~~^~~~~~~~~
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

IPv6 RA always contains an implicit default route via
the link-local address of the source of RA. This forces
the guest to install a route via isolated network, which
may disturb the guest's networking in case of multiple interfaces.
More info in 013427e6.

The validity of this route is controlled by "default [route] lifetime"
field of RA. If the lifetime is set to 0 seconds, then no route
is installed by receiver.

dnsmasq 2.67+ supports "ra-param=<interface>,<RA interval>,<default
lifetime>" option. We pass "ra-param=*,0,0"
(here, RA_interval=0 means default) to disable default gateway in RA
for isolated networks.

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

So we spend some time and effort constructing perfect file name
for an automatic coredump of a domain, but then just leak it and
use the domain name anyway. This is probably due to a silly
mistake that slipped even through review.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

At least with systemd v210, NOTIFY_SOCKET is abstact, e.g.
@/org/freedesktop/systemd1/notify. sendmsg() fails on such a socket
with "Connection refused". The unix(7) man page contains the following
details wrt abstract socket addresses

abstract: an abstract socket address is distinguished (from a
          pathname socket) by the fact that sun_path[0] is a null byte
          ('\0').  The socket's address in this namespace is given by the
          additional bytes in sun_path that are covered by the specified
          length of the address structure.  (Null bytes in the name have
          no special significance.)

So we need to be more precise about the address length, setting it to
the sizeof sa_family_t + length of address copied to sun_path instead
of setting it to the sizeof the entire sockaddr_un struct.

Resolves: https://bugzilla.opensuse.org/show_bug.cgi?id=987668Signed-off-by: NJim Fehlig <jfehlig@suse.com>

When fetching domains with virConnectListAllDomains() and when filtering
by snapshot existence is requested the ESX driver first lists all the
domains and then check one-by-one for snapshot existence. This process
takes unnecessarily long time.

To significantly improve the time necessary to finish the query we can
request the snapshot related info directly when querying the list of
domains from VMware.
Signed-off-by: NTomáš Golembiovský <tgolembi@redhat.com>

In an unlikely event of execve() failing, the virCommandExec()
function does not report any error, even though checks that are
at the beginning of the function are verbose when failing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The modification of .volWipe callback wipes ploop volume using one of
given wiping algorithm: dod, nnsa, etc.
However, in case of ploop volume we need to reinitialize root.hds and DiskDescriptor.xml.

v2:
- added check on ploop tools presens
- virCommandAddArgFormat changed to virCommandAddArg
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

<devices>
  <iommu model='intel'/>
</devices>

results in:

-device intel-iommu

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

Check whether QEMU supports -device intel-iommu

Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.

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

A device with an attribute 'model', with just one model
so far:

<devices>
  ...
  <iommu model='intel'/>
</devices>

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

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently many users of virConf APIs are defining the same
macros for calling virConfValue() and then doing type
checking. To remove this repeated code, add a set of
typesafe accessor methods.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If the config file does not end with a \n, the parser will append
one. When re-allocating the array though, it is mistakenly assuming
that 'len' is the length including the trailing NUL, but it does
not. So we must add 2 to len, when reallocating, not 1.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This one's a bit more complicated. In qemuProcessPrepareDomain()
a master key for encrypting secret for ciphered disks is created.
This object lives within qemuDomainObjPrivate object. It is freed
in qemuProcessStop(), but if nobody calls it (for instance like
our qemuxml2argvtest does), the key object leaks.

==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707
==17078==    at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==17078==    by 0xAD924DF: virAllocN (viralloc.c:191)
==17078==    by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166)
==17078==    by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678)
==17078==    by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913)
==17078==    by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542)
==17078==    by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==17078==    by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==17078==    by 0x446E7A: virTestRun (testutils.c:179)
==17078==    by 0x445BD9: mymain (qemuxml2argvtest.c:2022)
==17078==    by 0x44886F: virTestMain (testutils.c:969)
==17078==    by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just like every other qemuBuild*CommandLine() function, this uses
a buffer to hold partial cmd line strings too. However, if
there's an error, the control jumps to 'cleanup' label leaving
the buffer behind and thus leaking it.

==2013== 1,006 bytes in 1 blocks are definitely lost in loss record 701 of 711
==2013==    at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==2013==    by 0x4C2C32F: realloc (vg_replace_malloc.c:692)
==2013==    by 0xAD925A8: virReallocN (viralloc.c:245)
==2013==    by 0xAD95EA8: virBufferGrow (virbuffer.c:130)
==2013==    by 0xAD95F78: virBufferAdd (virbuffer.c:165)
==2013==    by 0x5097F5: qemuBuildCpuModelArgStr (qemu_command.c:6339)
==2013==    by 0x509CC3: qemuBuildCpuCommandLine (qemu_command.c:6437)
==2013==    by 0x51142C: qemuBuildCommandLine (qemu_command.c:9174)
==2013==    by 0x47CA3A: qemuProcessCreatePretendCmd (qemu_process.c:5546)
==2013==    by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==2013==    by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==2013==    by 0x446E7A: virTestRun (testutils.c:179)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When storage secret is parsed in virStorageEncryptionSecretParse(),
virSecretLookupParseSecret() which allocates some memory. This is
however never freed.

==21711== 134 bytes in 6 blocks are definitely lost in loss record 70 of 85
==21711==    at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==21711==    by 0xBCA0356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==21711==    by 0xA9F432E: virXMLPropString (virxml.c:479)
==21711==    by 0xA9D25B0: virSecretLookupParseSecret (virsecret.c:70)
==21711==    by 0xA9D616E: virStorageEncryptionSecretParse (virstorageencryption.c:172)
==21711==    by 0xA9D66B2: virStorageEncryptionParseXML (virstorageencryption.c:281)
==21711==    by 0xA9D68DF: virStorageEncryptionParseNode (virstorageencryption.c:338)
==21711==    by 0xAA12575: virDomainDiskDefParseXML (domain_conf.c:7606)
==21711==    by 0xAA2CAC6: virDomainDefParseXML (domain_conf.c:16658)
==21711==    by 0xAA2FC75: virDomainDefParseNode (domain_conf.c:17472)
==21711==    by 0xAA2FAE4: virDomainDefParse (domain_conf.c:17419)
==21711==    by 0xAA2FB72: virDomainDefParseFile (domain_conf.c:17443)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Setting up cgroups and other things for all kinds of threads (the
emulator thread, vCPU threads, I/O threads) was copy-pasted every time
new thing was added.  Over time each one of those functions changed a
bit differently.  So create one function that does all that setup and
start using it, starting with I/O thread setup.  That will shave some
duplicated code and maybe fix some bugs as well.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The code in qemuDomainObjPrivateXMLParseVcpu for parsing
the 'idstr' string was comparing the overall boolean
result against 0 which was always true

qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu':
qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]
     if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
                                                           ^

It was further performing two distinct error checks in
the same conditional and reporting a single error message,
which was misleading in one of the two cases.

This splits the conditional check into two parts with
distinct error messages and fixes the logic error.

Fixes the bug in

  commit 5184f398
  Author: Peter Krempa <pkrempa@redhat.com>
  Date:   Fri Jul 1 14:56:14 2016 +0200

    qemu: Store vCPU thread ids in vcpu private data objects
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

An error in virHostCPUGetKVMMaxVCPUs() means we've been unable
to access /dev/kvm, or we're running on a platform that doesn't
support KVM in the first place.

If that's the case, we shouldn't ignore the error and report
domcapabilities even though we know the user won't be able to
start any KVM guest.