Allow migration over IPv6 by listening on [::] instead of 0.0.0.0
when QEMU supports it (QEMU_CAPS_IPV6_MIGRATION) and there is
at least one v6 address configured on the system.

Use virURIParse in qemuMigrationPrepareDirect to allow parsing
IPv6 addresses, which would cause an 'incorrect :port' error
message before.

Move setting of migrateFrom from qemuMigrationPrepare{Direct,Tunnel}
after domain XML parsing, since we need the QEMU binary path from it
to get its capabilities.

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

Code added by commit id '523207fe'

TEST: qemuxml2argvtest
      ........................................ 40
      ........................................ 80
      ........................................ 120
      ........................................ 160
      ........................................ 200
      ........................................ 240
      .................................        273 OK
==30993== 39 bytes in 1 blocks are definitely lost in loss record 33 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x41E501: fakeSecretGetValue (qemuxml2argvtest.c:33)
==30993==    by 0x427591: qemuBuildDriveURIString (qemu_command.c:2571)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 46 bytes in 1 blocks are definitely lost in loss record 64 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x38D690A167: __vasprintf_chk (in /usr/lib64/libc-2.16.so)
==30993==    by 0x4CB28E7: virVasprintf (stdio2.h:210)
==30993==    by 0x4CB29A3: virAsprintf (virutil.c:2017)
==30993==    by 0x4275B4: qemuBuildDriveURIString (qemu_command.c:2580)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 385 (56 direct, 329 indirect) bytes in 1 blocks are definitely los
==30993==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==30993==    by 0x4C6B2CF: virAllocN (viralloc.c:152)
==30993==    by 0x4C9C7EB: virObjectNew (virobject.c:191)
==30993==    by 0x4D21810: virGetSecret (datatypes.c:642)
==30993==    by 0x41E5D5: fakeSecretLookupByUsage (qemuxml2argvtest.c:51)
==30993==    by 0x4D4BEC5: virSecretLookupByUsage (libvirt.c:15295)
==30993==    by 0x4276A9: qemuBuildDriveURIString (qemu_command.c:2565)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==
PASS: qemuxml2argvtest

Interesting side note is that running the test singularly via 'make -C tests
check TESTS=qemuxml2argvtest' didn't trip the valgrind error; however,
running during 'make -C tests valgrind' did cause the error to be seen.

f946462e changed behavior by settings
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI upfront. If we do so before invoking
qemuDomainPCIAddressEnsureAddr we merely try to set the PCI slot via
qemuDomainPCIAddressReserveSlot instead reserving a new address via
qemuDomainPCIAddressSetNextAddr which fails with

$ ~/run-tck-test domain/200-disk-hotplug.t
./scripts/domain/200-disk-hotplug.t .. # Creating a new transient domain
./scripts/domain/200-disk-hotplug.t .. 1/5 # Attaching the new disk /var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img

 #   Failed test 'disk has been attached'
 #   at ./scripts/domain/200-disk-hotplug.t line 67.
 # died: Sys::Virt::Error (libvirt error code: 1, message: internal error unable to reserve PCI address 0:0:0.0
 # )

Since we switched from direct host migration scheme to the one,
where we connect to the destination and then just pass a FD to a
qemu, we have uncovered a qemu bug. Qemu expects migration FD to
block. However, we are passing a nonblocking one which results in
cryptic error messages like:

  qemu: warning: error while loading state section id 2
  load of migration failed

The bug is already known to Qemu folks, but we should workaround
already released Qemus. Patch has been originally proposed by Stefan
Hajnoczi <stefanha@gmail.com>

This reverts commit 5ac846e4.

After further discussions with Alon Levy, I learned the following:

The use of '-vga qxl' vs. '-device qxl-vga' is completely orthogonal
to whether ram_size can be exposed.  Downstream distros are interested
in backporting support for multi-head qxl, but this can be done in
one of two ways:
1. Support one head per PCI device.  If you do this, then it makes
sense to have full control over the PCI address of each device. For
full control, you need '-device qxl-vga' instead of '-vga qxl'.
2. Support multiple heads through a single PCI device.  If you do
this, then you need to allocate more RAM to that PCI device (enough
ram to cover the multiple screens).  Here, the device is hard-coded
to 0:0:2.0, both in qemu and libvirt code.

Apparently, backporting ram_size changes to allow multiple heads in
a single device is much easier than backporting multiple device
support.  Furthermore, the presence or absence of qxl-vga.surfaces
is no different than the presence or absence of qxl-vga.ram_size;
both properties can be applied regardless of whether you have one
PCI device (-vga qxl) or multiple (-device qxl-vga), so this property
is NOT a good witness of whether '-device qxl-vga' support has been
backported.

Downstream RHEL will NOT be using this patch; and worse, leaving this
patch in risks doing the wrong thing if compiling upstream libvirt
on RHEL, so the best course of action is to revert it.  That means
that libvirt will go back to only using '-device qxl-vga' for qemu
>= 1.2, but this is just fine because we know of no distros that plan
on backporting multiple PCI address support to any older version of
qemu.  Meanwhile, downstream can still use ram_size to pack multiple
heads through a single PCI device.

This does nothing more than adding the new device and capability.
The device is present since QEMU 1.2.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

A better way to do this would be to use a configuration file like

   [iscsi "target-name"]
   user = name
   password = pwd

and pass it via -readconfig.  This would remove the username and password
from the "ps" output.  For now, however, keep this solution.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Only sheepdog actually required it in the code, and we can use 7000 as the
default---the same value that QEMU uses for the simple "sheepdog:VOLUME"
syntax.  With this change, the schema can be fixed to allow no port.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This enables usage of commands like persistent reservations.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

libiscsi provides a userspace iSCSI initiator.

The main advantage over the kernel initiator is that it is very
easy to provide different initiator names for VMs on the same host.
Thus libiscsi supports usage of persistent reservations in the VM,
which otherwise would only be possible with NPIV.

libiscsi uses "iscsi" as the scheme, not "iscsi+tcp".  We can change
this in the tests (while remaining backwards-compatible manner, because
QEMU uses TCP as the default transport for both Gluster and NBD).
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

When the blockjob fails for some reason an event is emitted but the disk
wasn't unmarked as being part of a active block copy operation.

The VIR_ERR_NO_SUPPORT error code is reserved for cases where an
API is not implemented in a driver. It definitely should not be
used when an API execution fails due to unsupported operation.

We should record the new disk src in the shared disk table for
updating disk (CD-ROM or Floppy) API. Fortunately, we only allow
to update the disk source now, otherwise we might also want to
set the unpriv_sgio setting.

Now that VCPU number are removed from qemu_monitor_text.c
(commit cc78d7ba), VCPU string checking also should be removed.
Report-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>

Intend to reduce the redundant code,use virNumaSetupMemoryPolicy
to replace virLXCControllerSetupNUMAPolicy and
qemuProcessInitNumaMemoryPolicy.

This patch also moves the numa related codes to the
file virnuma.c and virnuma.h
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

qemuGetNumadAdvice will be used by LXC driver, rename
it to virNumaGetAutoPlacementAdvice and move it to virnuma.c
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

The "dtb" option sets the filename for the device tree.
If without this option support, "-dtb file" will be converted into
<qemu:commandline> in domain XML file.
For example, '-dtb /media/ram/test.dtb' will be converted into
  <qemu:commandline>
    <qemu:arg value='-dtb'/>
    <qemu:arg value='/media/ram/test.dtb'/>
  </qemu:commandline>

This is not very friendly.
This patchset add special <dtb> tag like <kernel> and <initrd>
which is easier for user to write domain XML file.
  <os>
    <type arch='ppc' machine='ppce500v2'>hvm</type>
    <kernel>/media/ram/uImage</kernel>
    <initrd>/media/ram/ramdisk</initrd>
    <dtb>/media/ram/test.dtb</dtb>
    <cmdline>root=/dev/ram rw console=ttyS0,115200</cmdline>
  </os>
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit 82d5fe54

    qemu: check backing chains even when cgroup is omitted

added backing file checks just before the code that removes optional
disks if they are not present. However, the backing chain code fails in
case the disk file does not exist, which makes qemuProcessStart fail
regardless on configured startupPolicy.

Note that startupPolicy implementation is still wrong after this patch
since it only check the first file in a possible chain. It should rather
check the complete backing chain. But this is an existing limitation
that can be solved later. After all, startupPolicy is most useful for
CDROM images and they won't make use of backing files in most cases.

QEMU 1.3 and newer support an alternative URI-based syntax to specify
the location of an NBD server.  Libvirt can keep on using the old
syntax in general, but only the URI syntax supports IPv6 addresses.

The URI syntax also supports relative paths to Unix sockets.  These
should never be used but aren't explicitly blocked either by the parser,
so support it just in case.

The URI syntax is intentionally compatible with Gluster's, and the
code can be reused.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

This reuses the XML format that was introduced for Gluster.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

These are supported by nbd-server and by the NBD server that QEMU
embeds for live image access.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Move the code to an external function, and structure it to prepare
the addition of new features in the next few patches.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

QEMU added -drive in 2007, and NBD in 2008.  Both appeared first in
release 0.10.0.  Thus the code to support network disks without -drive
is dead, and in fact it incorrectly escapes commas.  Drop it.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

When getting CPUs' information, it assumes that CPU indexes
are not contiguous. But for ppc64 platform, CPU indexes are not
contiguous because SMT is needed to be disabled, so CPU information
is not right on ppc64 and vpuinfo, vcpupin can't work corretly.

This patch is to remove the assumption to be compatible with ppc64.

Test:
   4 vcpus are assigned to one VM and execute vcpuinfo command.

   Without patch: There is only one vcpu informaion can be listed.
   With patch: All vcpus' information can be listed correctly.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>

Newer versions of QEMU support virtio-scsi and virtio-rng devices
on the virtio-s390 and ccw buses. Adding capability detection,
address assignment and command line generation for that.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

QEMU_CAPS_VIRTIO_SCSI_PCI implies that virtio-scsi is only supported
for the PCI bus, which is not the case. Remove the _PCI suffix.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Multi-head QXL support is so useful that distros have started to
backport it to qemu earlier than 1.2.  After discussion with
Alon Levy, we determined that the existence of the qxl-vga.surfaces
property is a reliable indicator of whether '-device qxl-vga' works,
or whether we have to stick to the older '-vga qxl'.  I'm leaving
in the existing check for QEMU_CAPS_DEVICE_VIDEO_PRIMARY tied to
qemu 1.2 and newer (in case qemu is built without qxl support),
but for those distros that backport qxl, this additional capability
check will allow the correct command line for both RHEL 6.3 (which
lacks the feature) and RHEL 6.4 (where qemu still claims to be
version 0.12.2.x, but has backported multi-head qxl).

* src/qemu/qemu_capabilities.c (virQEMUCapsObjectPropsQxlVga): New
property test.
(virQEMUCapsExtractDeviceStr): Probe for backport of new
capability to qemu earlier than 1.2.
* tests/qemuhelpdata/qemu-kvm-1.2.0-device: Update test.
* tests/qemuhelpdata/qemu-1.2.0-device: Likewise.
* tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta-device:
Likewise.

Qemu's implementation of virtio RNG supports rate limiting of the
entropy used. This patch exposes the option to tune this functionality.

This patch is based on qemu commit 904d6f588063fb5ad2b61998acdf1e73fb4

The rate limiting is exported in the XML as:
<devices>
  ...
  <rng model='virtio'>
    <rate bytes='123' period='1234'/>
    <backend model='random'/>
  </rng>
  ...

We didn't yet expose the virtio device attach and detach functionality
for s390 domains as the device hotplug was very limited with the old
virtio-s390 bus. With the CCW bus there's full hotplug support for
virtio devices in QEMU, so we are adding this to libvirt too.

Since the virtio hotplug isn't limited to PCI anymore, we change the
function names from xxxPCIyyy to xxxVirtioyyy, where we handle all
three virtio bus types.
Signed-off-by: NJ.B. Joret <jb@linux.vnet.ibm.com>
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

This commit adds the QEMU driver support for CCW addresses. The
current QEMU only allows virtio devices to be attached to the
CCW bus. We named the new capability indicating that support
QEMU_CAPS_VIRTIO_CCW accordingly.

The fact that CCW devices can only be assigned to domains with a
machine type of s390-ccw-virtio requires a few extra checks for
machine type in qemu_command.c on top of querying
QEMU_CAPS_VIRTIO_{CCW|S390}.

The majority of the new functions deals with CCW address generation
and management.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

With our recent patch (1715c83b) we thrive to get the correct
number of maximal VCPUs. However, we are using a constant from
linux/kvm.h which may be not defined in every distro. Hence, we
should guard usage of the constant with ifdef preprocessor
directive. This was introduced in kernel:

    commit 8c3ba334f8588e1d5099f8602cf01897720e0eca
    Author: Sasha Levin <levinsasha928@gmail.com>
    Date:   Mon Jul 18 17:17:15 2011 +0300

    KVM: x86: Raise the hard VCPU count limit

    The patch raises the hard limit of VCPU count to 254.

    This will allow developers to easily work on scalability
    and will allow users to test high VCPU setups easily without
    patching the kernel.

    To prevent possible issues with current setups, KVM_CAP_NR_VCPUS
    now returns the recommended VCPU limit (which is still 64) - this
    should be a safe value for everybody, while a new KVM_CAP_MAX_VCPUS
    returns the hard limit which is now 254.

$ git desc 8c3ba334f
v3.1-rc7-48-g8c3ba33

The virCaps structure gathered a ton of irrelevant data over time that.
The original reason is that it was propagated to the XML parser
functions.

This patch aims to create a new data structure virDomainXMLConf that
will contain immutable data that are used by the XML parser. This will
allow two things we need:

1) Get rid of the stuff from virCaps

2) Allow us to add callbacks to check and add driver specific stuff
after domain XML is parsed.

This first attempt removes pointers to private data allocation functions
to this new structure and update all callers and function that require
them.

At least one caller may call qemuSharedDiskEntryFree with NULL as the
first argument. Let's make the function similar to other *Free functions
and do nothing in such case.

The detection of the maximum number of cpus used incorrect ioctl
argument value. This flaw caused that on kvm hosts this returns always
"160" as the maximum. This is just a recommended maximum value. The real
value is higher than that.

This patch tweaks the detection function to behave as described by the
kernel docs:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/virtual/kvm/api.txt?id=refs/tags/v3.9-rc2#n199

When there are two concurrent threads, we may dereference a NULL
pointer, even though it has been checked before:

1. Thread1: starts executing qemuDomainBlockStatsFlags() with nparams != 0.
            It finds given disk and successfully pass check for disk->info.alias
            not being NULL.
2. Thread2: starts executing qemuDomainDetachDeviceFlags() on the very same
            disk as Thread1 is working on.
3. Thread1: gets to qemuDomainObjBeginJob() where it sets a job on a
            domain.
4. Thread2: also tries to set a job. However, we are not guaranteed which
            thread wins. So assume it's Thread2 who can continue.
5. Thread2: does the actual detach and frees disk->info.alias
6. Thread2: quits the job
7. Thread1: now successfully acquires the job, and accesses a NULL pointer.

The current QEMU code for skipping log messages only skips over
'debug' message, switch to virLogProbablyLogMessage to make sure
it skips over all of them

virsh subcommand memtune forgot updating domain live xml
after setting cgroup value.

19c6ad9a (qemu: Refactor qemuDomainSetMemoryParameters) introduced
a new macro, VIR_GET_LIMIT_PARAMETER(PARAM, VALUE). But if statement
in the macro is not correct and so set_XXXX flags are set to false
in the wrong. As a result, libvirt ignores all memtune parameters.
This patch fixes the conditional expression to work correctly.
Signed-off-by: NSatoru Moriya <satoru.moriya@hds.com>

At the start of the guest after the image is unlinked the state wasn't
touched up to match the state on disk.