Later on, more stuff will be added so prevent the main function growing
out of control.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Allow saving various aspects necessary to do NBD migration via blockdev
by storing a 'virStorageSource' in the disk private data meant to store
the NBD target of migration. Along with this add code to parse and
format it into the status XML.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Extract the NBD portion of the 'job' status XML element parser into a
separate function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We will be adding source data to it so extract it to a separate function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Rather than always re-generating the alias store it in the definition
and in the status XML.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Rather than always checking which path to use pre-assign it when
preparing storage source.

This reduces the need to pass 'vm' around too much. For later use the
path can be retrieved from the status XML.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

To allow storing status information in the XML move the validation that
the 'path' is not valid for managed PR daemon case into
qemuDomainValidateStorageSource and allow parsing of the data even in
case when managed='yes'.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The function now does not do anything useful. Replace it by the pointer
check.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Disk source definition should be validated in
qemuDomainValidateStorageSource rather than in individual generators of
command line arguments.

Change to the XML2XML test is required since now the definition is
actually validated at define time.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge
and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments
which identify support for ccw devices.

The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7.
The QEMU_CAPS_CCW capability is based on the existence of the QEMU type.

Let us also add the capability QEMU_CAPS_CCW to the tests which
require support for ccw devices.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Before we exec() qemu we have to spawn pr-helper processes for
all managed reservations (well, technically there can only one).
The only caveat there is that we should place the process into
the same namespace and cgroup as qemu (so that it shares the same
view of the system). But we can do that only after we've forked.
That means calling the setup function between fork() and exec().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

If qemu-pr-helper is compiled with multipath support the first
thing it does is open /dev/mapper/control. Since we're going
to be running it inside qemu namespace we need to create it
there. Unfortunately, we don't know if it was compiled with or
without multipath so we have to create it anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

For command line we need two things:

1) -object pr-manager-helper,id=$alias,path=$socketPath
2) -drive file.pr-manager=$alias

In -object pr-manager-helper we tell qemu which socket to connect
to, then in -drive file-pr-manager we just reference the object
the drive in question should use.

For managed PR helper the alias is always "pr-helper0" and socket
path "${vm->priv->libDir}/pr-helper0.sock".
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Couple of reasons for that:

a) there's no monitor command to change path where the pr-helper
connects to, or
b) there's no monitor command to introduce a new pr-helper for a
disk that already exists.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Use the new helper when checking that the VM needs to be tainted as a
host-cdrom passthrough.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

The function will be reused in the test code where we don't care much
that the gluster debug level can't be populated from the qemu config.

Set the level only when 'cfg' is passed.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

It will be used in the qemublocktest.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Use virFileIsCDROM to detect whether a block device is a cdrom drive and
store it in virStorageSource. This will be necessary to correctly create
the 'host_cdrom' backend in qemu when using -blockdev.

We assume that host_cdrom makes only sense when used directly as a raw
image, but if a backing chain would be put in front of it, libvirt will
use 'host_device' in that case.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Move it to the validation callback and make it more robust. This will
also put the checks in the correct place to use with -blockdev.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Add a flag denoting that a virStorageSource is going to be used as a
floppy image. This will be useful in cases where the user passes in
files which shall be exposed as an image to the guest.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Some properties don't make sense to be configured for every single layer
of the backing chain, but to avoid needing to pass the disk structure we
will copy them to the individual virStorageSource.

Zero detection is applied only for the top layer image, while caching
and iomode for all layers.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Save and restore node names if we know them or when we will be
generating them in the status XML.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When adding a new object to the domain object list, there should
have been 2 virObjectRef calls made one for each list into which
the object was placed to match the 2 virObjectUnref calls that
would occur during Remove as part of virHashRemoveEntry when
virObjectFreeHashData is called when the element is removed from
the hash table as set up in virDomainObjListNew.

Some drivers (libxl, lxc, qemu, and vz) handled this inconsistency
by calling virObjectRef upon successful return from virDomainObjListAdd
in order to use virDomainObjEndAPI when done with the returned @vm.
While others (bhyve, openvz, test, and vmware) handled this via only
calling virObjectUnlock upon successful return from virDomainObjListAdd.

This patch will "unify" the approach to use virDomainObjEndAPI
for any @vm successfully returned from virDomainObjListAdd.

Because list removal is so tightly coupled with list addition,
this patch fixes the list removal algorithm to return the object
as entered - "locked and reffed".  This way, the callers can then
decide how to uniformly handle add/remove success and failure.
This removes the onus on the caller to "specially handle" the
@vm during removal processing.

The Add/Remove logic allows for some logic simplification such
as in libxl where we can Remove the @vm directly rather than
needing to set a @remove_dom boolean and removing after the
libxlDomainObjEndJob completes as the @vm is locked/reffed.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The virStorageFileSupportsSecurityDriver and
virStorageFileSupportsAccess currently just return a boolean
value. This is ok because they don't have any failure scenarios
but a subsequent patch is going to introduce potential failure
scenario. This changes their return type from a boolean to an
int with values -1, 0, 1.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The current private XML parsing code relies on the assumption
that NUMA node IDs start from 0 and are densely allocated,
neither of which is necessarily the case.

Change it so that the bitmap size is dynamically calculated by
looking at NUMA node IDs instead, which ensures all nodes will
be able to fit and thus the bitmap will be parsed successfully.

Update one of the test cases so that it would fail with the
previous approach, but passes with the new one.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490158Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Allocated in qemuMigrationParamsNew() we need to free
priv->job.migParams when no longer needed.

==8061== 234 (192 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 112 of 123
==8061==    at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==8061==    by 0x5325D05: virAlloc (viralloc.c:144)
==8061==    by 0x1984F9: qemuMigrationParamsNew (qemu_migration_params.c:218)
==8061==    by 0x19A352: qemuMigrationParamsParse (qemu_migration_params.c:1185)
==8061==    by 0x1604D8: qemuDomainObjPrivateXMLParseJob (qemu_domain.c:2390)
==8061==    by 0x160AE9: qemuDomainObjPrivateXMLParse (qemu_domain.c:2517)
==8061==    by 0x5419EAE: virDomainObjParseXML (domain_conf.c:20442)
==8061==    by 0x541A25E: virDomainObjParseNode (domain_conf.c:20555)
==8061==    by 0x541A2FC: virDomainObjParseFile (domain_conf.c:20574)
==8061==    by 0x13607D: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:75)
==8061==    by 0x14F3E8: virTestRun (testutils.c:180)
==8061==    by 0x14DCD0: mymain (qemuxml2xmltest.c:1200)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add helper which will map values of disk cache mode to the flags which
are accepted by various parts of the qemu block layer.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

There were two places where we'd check this independently. Move it to
the disk definition validation callback. This also fixes possible use of
NULL in a printf for network storage.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

So far we are repeating the following lines over and over:

  if (!(virSomeObjectClass = virClassNew(virClassForObject(),
                             "virSomeObject",
                             sizeof(virSomeObject),
                             virSomeObjectDispose)))
      return -1;

While this works, it is impossible to do some checking. Firstly,
the class name (the 2nd argument) doesn't match the name in the
code in all cases (the 3rd argument). Secondly, the current style
is needlessly verbose. This commit turns example into following:

  if (!(VIR_CLASS_NEW(virSomeObject,
                      virClassForObject)))
      return -1;
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

In order to not affect running VMs, refreshing the halted state
is only performed if QEMU supports the query-cpus-fast QAPI.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Use query-cpus-fast instead of query-cpus if supported by QEMU.
Based on the QEMU_CAPS_QUERY_CPUS_FAST capability.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This will help us decide what to do when libvirtd is restarted while an
async job is running.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We store the flags passed to the API which started the migration. Let's
use them instead of a separate bool to check if post-copy migration was
requested.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We store the flags passed to the API which started QEMU_ASYNC_JOB_DUMP
and we can use them to check whether a memory-only dump is running.
There's no need for a specific bool flag.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When an async job is running, we sometimes need to know how it was
started to distinguish between several types of the job, e.g., post-copy
vs. normal migration. So far we added a specific bool item to
qemuDomainJobObj for such cases, which doesn't scale very well and
storing such bools in status XML would be painful so we didn't do it.

A better approach is to store the flags passed to the API which started
the async job, which can be easily stored in status XML.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

To be able to restore all migration parameters when libvirtd is
restarting during an active migration job, we need to store the original
values of all parameters (stored in priv->job.migParams) in the status
XML.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The function checks whether QEMU supports TLS migration and stores the
original value of tls-creds parameter to priv->migTLSAlias. This is no
longer needed because we already have the original value stored in
priv->migParams.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>