Using libvirt to do live migration over RDMA via IPv6 address failed.

For example:
    rhel73_host1_guest1 qemu+ssh://[deba::2222]/system --verbose
root@deba::2222's password:
error: internal error: unable to execute QEMU command 'migrate': RDMA
ERROR: could not rdma_getaddrinfo address deba

As we can see, the IPv6 address used by rdma_getaddrinfo() has only
"deba" part because we didn't properly enclose the IPv6 address in []
and passed rdma:deba::2222:49152 as the migration URI in
qemuMonitorMigrateToHost.
Signed-off-by: NDavid Dai <zdai@linux.vnet.ibm.com>

In cases where CPU hotplug is supported by qemu force the monitor to
reject invalid or broken responses to 'query-cpus'. It's expected that
the command returns usable data in such case.

query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>

Add support to read/parse the iotune group setting for qemu.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit 3f71c797 added 'qemu_id' field to track the id of the cpu
as reported by query-cpus. The patch did not include changes necessary
to propagate the id through the functions matching the data to the
libvirt cpu structures and thus all vcpus had id 0.

We don't need to call qemuMonitorGetCPUInfo which is very inefficient to
get data required to update the vcpu 'halted' state.

Add a monitor helper that will retrieve the halted state and return it
in a bitmap so that it can be indexed easily.

Call 'query-qmp-schema' and store the returned types in a hash table
keyed by the 'name' field so that the capabilities code can traverse it.

Add support for a duration/length for the bps/iops and friends.

Modify the API in order to add the "blkdeviotune." specific definitions
for the iotune throttling duration/length options

    total_bytes_sec_max_length
    write_bytes_sec_max_length
    read_bytes_sec_max_length
    total_iops_sec_max_length
    write_iops_sec_max_length
    read_iops_sec_max_length

Extended the qemuMonitorCPUInfo with a halted flag. Extract the halted
flag for both text and JSON monitor.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Attaching to a existing qemu process allows to get us into a situation
when qemu is new enough to have JSON monitor and new vCPU hotplug but
the json monitor is not used. The vCPU detection code would require it
though. This broke attaching to qemu processes.

Make the condition less strict and just skip the vCPU hotplug detection
if JSON monitor is not available.

Resolves one of the symptoms in:
https://bugzilla.redhat.com/show_bug.cgi?id=1378401

The list of supported CPU models in domain capabilities is stored in
virDomainCapsCPUModels. Let's use the same object for storing CPU models
in QEMU capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Both qemu monitor and agent print the same
log on HUANGUP event, which would be confusing
when reading libvirtd log.

This patch will give a different log message to them.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Return whether a vcpu entry is hotpluggable or online so that upper
layers don't have to infer the information from other data.

Advantage is that this code can be tested by unit tests.

Add separate iterator for iterating all the entries

The algorithm that matches data from query-cpus and
query-hotpluggable-cpus is quite complex. Start using descriptive
iterator names to avoid confusion.

When migration fails, we need to poke QEMU monitor to check for a reason
of the failure. We did this using query-migrate QMP command, which is
not supposed to return any meaningful result on the destination side.
Thus if the monitor was still functional when we detected the migration
failure, parsing the answer from query-migrate always failed with the
following error message:

    "info migration reply was missing return status"

This irrelevant message was then used as the reason for the migration
failure replacing any message we might have had.

Let's use harmless query-status for poking the monitor to make sure we
only get an error if the monitor connection is broken.

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

For hotplug purposes it's necessary to retrieve data using
query-hotpluggable-cpus while the old query-cpus API report thread IDs
and order of hotplug.

This patch adds code that merges the data using a rather non-trivial
algorithm and fills the data to the qemuMonitorCPUInfo structure for
adding to appropriate place in the domain definition.

To allow matching up the data returned by query-cpus to entries in the
query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract
the QOM path as it's the only link between the two.

Prepare to extract more data by returning an array of structs rather than
just an array of thread ids. Additionally report fatal errors separately
from qemu not being able to produce data.

The function will gradually add more returned data. Return a struct for
every vCPU containing the data.

Use a name that contains the command used to get the information.

Assure that it's just one statement to avoid problems when used with
conditions.

Rather than formatting a string and splitting it back to a JSON object
add API that will take a JSON object directly.

Avoid reporting a stale errno value when the syscall succeeds,
instead always pass 0.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 4a585a88 introduced searching QOM device path by alias, let's use it for
memballoon too.  This may speedup the search because in most cases we will find
the correct QOM device path directly by using alias without the need for the
recursion code.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit ce745914 introduced detection of actual video ram sizes to fix migration
if QEMU decide to modify the values provided by libvirt.  This works perfectly
for domains with number of video devices up to two.

If there are more than two video devices in the guest all the secondary devices
in the XML will have the same memory values.  This is because our current code
search for QOM device path only by the device type name and all the secondary
video devices has the same name "qxl".

This patch introduces a new search function that will try to search a QOM device
path using also device's alias if the alias is available. After that it will
fallback to the old recursive code if the alias search found no results.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358728Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

qemuMonitorMigrationParams is a better name for a structure which
contains various migration parameters. While doing that, we should use
full names for individual parameters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Checking whether the function has anything to do is better done in the
function rather then requiring callers to do that.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The caller is already aware that the params are missing and the
extractor is ignoring the missing ones so the parameter isn't necessary.

Extract information for all disks and update tray state and source only
for removable drives. Additionally store whether a drive is removable
and whether it has a tray.

It was only called for QEMUs without QEMU_CAPS_DEVICE,
which we no longer support.

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Code was obsoleted by using -device.

QEMU introduced the query-gic-capabilities QMP command
with commit 4468d4e0f383: use the command, if available,
to probe available GIC capabilities.

The information obtained is stored in a virQEMUCaps
instance, and will be later used to fill in a
virDomainCaps instance.

In a few places in libvirt we busy-wait for events, for example qemu
creating a monitor socket.  This is problematic because:

 - We need to choose a sufficiently small polling period so that
   libvirt doesn't add unnecessary delays.

 - We need to choose a sufficiently large polling period so that
   the effect of busy-waiting doesn't affect the system.

The solution to this conflict is to use an exponential backoff.

This patch adds two functions to hide the details, and modifies a few
places where we currently busy-wait.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>