Automatically assign addresses to USB devices.

Just like reserving, this is only done for newly defined domains.

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

Check if they fit on the USB controllers the domain has,
and error out if two devices try to use the same address.

Resolves a CI test integration failure with a RHEL6/Centos6 environment.

In order to use a LUKS encrypted device, the design decision was to
generate an encrypted secret based on the master key. However, commit
id 'da86c6c2' missed checking for that specifically.

When qemuDomainSecretSetup was implemented, a design decision was made
to "fall back" to a plain text secret setup if the specific cipher was
not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC))
as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup
there is no fall back to the plaintext secret, thus if that gets set
up by qemuDomainSecretSetup, then we need to fail.

Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET
bit, it didn't take into account the second requirement that the
ability to generate the encrypted secret is possible. So modify the
test to not attempt to run the luks-disk if we know we don't have
the encryption algorithm.

A post push realization that the boolean should be set inside the condition

A post push realization that the setting of the boolean needed to be
inside the if condition.

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

Generate the luks command line using the AES secret key to encrypt the
luks secret. A luks secret object will be in addition to a an AES secret.

For hotplug, check if the encinfo exists and if so, add the AES secret
for the passphrase for the secret object used to decrypt the device.

Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle
find a uuid or a volume usage with a specific path prefix in the XML
(corresponds to the already generated XML tests). Add error message
when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39'
altered the error message generation to rely on the errors from the
secret_driver (or it's faked replacement).

Add the .args output for adding the LUKS disk to the domain
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Soon we will be adding luks encryption support. Since a volume could require
both a luks secret and a secret to give to the server to use of the device,
alter the alias generation to create a slightly different alias so that
we don't have two objects with the same alias.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id 'a1344f70' added AES secret processing for RBD when starting
up a guest. As such, when the hotplug code calls qemuDomainSecretDiskPrepare
an AES secret could be added to the disk about to be hotplugged. If an AES
secret was added, then the hotplug code would need to generate the secret
object because qemuBuildDriveStr would add the "password-secret=" to the
returned 'driveStr' rather than the base64 encoded password.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move to virqemu and rename to virQEMUBuildBufferEscapeComma. This can then
be shared by the storage driver when it builds the command line for qemuimg

A recent adjustment to qemuDomainAttachRNGDevice to properly cleanup
the props object after a qemuMonitorAddObject also would affect this
code. Alter the cleanup to be similar to RNG changes.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Older libvirt versions send persistent XML in a migration cookie even
when VIR_MIGRATE_PERSIST_DEST flag is not used, but current libvirt
properly fails if the cookie contains unexpected flags. Thus migration
from old libvirt fails with

    internal error: Unsupported migration cookie feature persistent

unless VIR_MIGRATE_PERSIST_DEST flag is set.

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

In preparation to tracking which USB addresses are occupied.
Introduce two helper functions for printing the port path
as a string and appending it to a virBuffer.

We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).

Only format the port if it has been specified and mark it as optional
in the XML schema.

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>

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>

<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>

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>

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.

Rather than storing them in an external array store them directly.

Note the vcpu ID so that once we allow non-contiguous vCPU topologies it
will be possible to pair thread id's with the vcpus.

Further patches will be adding index and modifying the source variables
so this will make it more clear.

Members will be added in follow-up patches.

Allow to store driver specific data on a per-vcpu basis.

Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.

Most callers make sure that it's never called with an out of range vCPU.
Every other caller reports a different error explicitly. Drop the error
reporting and clean up some dead code paths.