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>

Any job which touches migration parameters will first store their
original values (i.e., QEMU defaults) to qemuDomainJobObj to make it
easier to reset them back once the job finishes.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since the function is tightly connected to migration, it was renamed as
qemuMigrationCapsCheck and moved to qemu_migration_params.c.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Introduced in d3db304d. Instead of returning immediately we
need to jump onto cleanup label where @paths is freed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we assume QEMU_CAPS_NETDEV, the only thing left to check
is whether we need to use the legacy -net syntax because of
a non-conforming armchitecture.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This makes qemuDomainSupportsNetdev identical to
qemuDomainSupportsNicdev and leaves some code in
qemuDomainAttachNetDevice to be cleaned up later.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Rather than VIR_ALLOC, use the New function for allocation. We
already use the Free function anyway.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

The array of strings we are building is indeed array of const
strings. We are not STRDUP()-ing them nor FREE()-ing them.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

The new controller will not yet be used automatically by
libvirt, but at this point it's already possible to configure
a guest to use it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The qemu command line generator code set disk caching of shareable disks
to 'none' when formatting the command line silently. Move this code to a
common place when preparing the domain definition for startup so that it
does not have to be duplicated.

The new test case shows that the actual cache mode will now be recorded
in the live XML definition.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Reject configurations when qemu would not support the image.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This format is used by the storage driver and other hypervisors but qemu
does not have notion of the 'iso' format and libvirt does not translate
it to anything useful, so it would not work anyways. Users should use
'raw' instead.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This is a storage driver type, which is not handled in qemu driver
properly. For accessing directories, disk type 'dir' is used instead.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

QEMU does not support it so save us the hassle and forbid it right away.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>