Dropping the caching of virtio serial address set.
The cached set is not required anymore, because the set is now being
recalculated from the domain definition on demand, so the cache
can be deleted.

Credit goes to Cole Robinson.

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.

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>

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>

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>

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>

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.

Otherwise migration during which we didn't send client_migrate_info QMP
command will get stuck waiting for SPICE migration to finish if libvirtd
sent the QMP command in a previous migration attempt.

Broken by bd7c8a69.

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

Due to the way the hardware works, KVM on ppc64 always requires
memory locking; however, that is not the case for non-KVM ppc64
guests, eg. ppc64 guests that are running on x86_64 with TCG.

Only require memory locking for ppc64 guests if they are using
KVM or, as it's the case for all architectures, they have host
devices assigned using VFIO.

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

Introduce a helper to help determine if a disk src could be possibly used
for a disk secret... Going to need this for hot unplug.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

libvirt's qemu driver doesn't have direct access to the config on the
guest side of a network interface, and currently doesn't have any
method in place to even inform the guest of the desired config. In the
future, an unenforceable attempt to set the guest-side IP info could
be made by adding a static host entry to the appropriate dnsmasq
configuration (or changing the default dhcp client address on the qemu
commandline for type='user' interfaces), or enhancing the guest agent
to allow setting an IP address, but for now it can't have any effect,
and we don't want to give the illusion that it does.

To prevent the "disappearance" of any existing configs with ip
address/route info (due to parser failure), this check is added in the
newly implemented qemuDomainDeviceDefValidate(), which is only called
when a domain is defined or started, *not* when it is reread from disk
at libvirtd startup.

Rather than pass authdef, pass the 'authdef->username' and the
'&authdef->secdef'

Note that a username may be NULL.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than assume/pass the protocol to the qemuDomainSecretPlainSetup
and qemuDomainSecretAESSetup, set and pass the secretUsageType based
on the src->protocol type. This will eventually be used by the
virSecretGetSecretString call
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This new function checks for both the architecture and the
machine type, so we can use it instead of writing the same
checks over and over again.

Remove all external architecture checks that have been
made redundant by this change.

Add 'encinfo' to the extended disk structure. This will contain the
encryption secret (if present).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the enum into a new src/util/virsecret.h, rename it to be
virSecretLookupType. Add a src/util/virsecret.h in order to perform
a couple of simple operations on the secret XML and virSecretLookupTypeDef
for clearing and copying.

This includes quite a bit of collateral damage, but the goal is to remove
the "virStorage*" and replace with the virSecretLookupType so that it's
easier to to add new lookups that aren't necessarily storage pool related.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Pass 'true' if we are not dealing with a migration.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function gets a reference on virQEMUDriverConfig which needs to be
released before returning.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Most the callers pass 0 in one form or another, including
vircapstest which used VIR_ARCH_NONE.

There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.

Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.

While we need to know the difference between the total memory stored in
<memory> and the actual size not included in the possible memory modules
we can't pre-calculate it reliably. This is due to the fact that
libvirt's XML is copied via formatting and parsing the XML and the
initial memory size can be reliably calculated only when certain
conditions are met due to backwards compatibility.

This patch removes the storage of 'initial_memory' and fixes the helpers
to recalculate the initial memory size all the time from the total
memory size. This conversion is possible when we also make sure that
memory hotplug accounts properly for the update of the total memory size
and thus the helpers for inserting and removing memory devices need to
be tweaked too.

This fixes a bug where a cold-plug and cold-remove of a memory device
would increase the size reported in <memory> in the XML by the size of
the memory device. This would happen as the persistent definition is
copied before attaching the device and this would lead to the loss of
data in 'initial_memory'.

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

Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).

This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.

Previously there was no way to have a Q35 domain that didn't have
these two controllers. This patch skips their creation as long as
there are some other kinds of pci controllers at index 1 and 2
(e.g. some pcie-root-port controllers).

I'm hoping that soon we won't add them at all, plugging all devices
into auto-added pcie-*-port ports instead, but in the meantime this
makes it easier to experiment with alternative bus hierarchies.

VNC graphics already supports sockets but only via 'socket' attribute.
This patch coverts that attribute into listen type 'socket'.

For backward compatibility we need to handle listen type 'socket' and 'socket'
attribute properly to support old XMLs and new XMLs.  If both are provided they
have to match, if only one of them is provided we need to be able to parse that
configuration too.

To not break migration back to old libvirt if the socket is provided by user we
need to generate migratable XML without the listen element and use only 'socket'
attribute.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Even though it's auto-generated it's based on qemu.conf option and listen type
address already uses "fromConfig" to carry this information.  Following commits
will convert the socket to listen element so this rename is required because
there will be also an option to get socket auto-generated independently on the
qemu.conf option.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Put it into separate function called qemuDomainPrepareChannel() and call
it from the new qemuProcessPrepareDomain().
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

One of the functions is returning always 0 and the second one uses
unnecessary labels.

Along with the virtlogd addition of the log file appending API implement
a helper for logging one-shot entries to the log file including the
fallback approach of using direct file access.

This will be used for noting the shutdown of the qemu proces and
possibly other actions such as VM migration and other critical VM
lifecycle events.

Introduce a validation callback for qemu and move checking of
min_guarantee to the new callback.