Commit 21ad56e9 introduced a regression where a VM with a corrupted
save image file would fail to start on the first attempt. This was
caused by returning a wrong return code as 'fd' was abused to also hold
the return code.

Since it's easy to miss this nuance, introduce a 'ret' variable for the
return code and return it' value in the error section.

https://bugzilla.redhat.com/show_bug.cgi?id=1791522Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

Catch the individual usage not removed in previous commits.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The file doesn't use virSystemd functions directly.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

External devices are started before cgroup is created. Add the DBus
daemon to the VM cgroup with the rest of the external devices.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Allow calling qemuDBusStart() multiple times (as may be done by
qemu-slirp already).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The slirp helper process should be associated with the VM cgroup, like
other helpers.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Don't stop the DBus daemon if a slirp helper failed to start, as it
may be shared with other helpers.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

e820_host is a Xen-specific option, only available for PV domains, that
provides the domain a virtual e820 memory map based on the host one. It
is enabled with a new Xen hypervisor feature, e.g.

  <features>
    <xen>
      <e820_host state='on'/>
    </xen>
  </features>

e820_host is required when using PCI passthrough and is generally
considered safe for any PV kernel. e820_host is silently ignored if set
in HVM domain configuration. See xl.cfg(5) man page in the Xen
documentation for more details.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

As explained in the previous commit, we need to relabel the file
we are restoring the domain from. That is the FD that is passed
to QEMU. If the file is not under /dev then the file inside the
namespace is the very same as the one in the host. And regardless
of using transactions, the file will be relabeled. But, if the
file is under /dev then when using transactions only the copy
inside the namespace is relabeled and the one in the host is not.
But QEMU is reading from the one in the host, actually.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1772838Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Previously, we used virCapabilitiesDomainDataLookup() to fill
machine type in post parse callback if none was provided in the
domain XML. If machine type couldn't be filled in an error was
reported. After 4a4132b4 we've changed it to
virQEMUCapsGetPreferredMachine() which returns NULL, but we no
longer report an error and proceed with the post parse callbacks
processing. This may lead to a crash because the code later on
assumes def->os.machine is not NULL.

Fixes: 4a4132b4Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

When preparing to do a blockcopy, the mirror image is modified so
that QEMU can access it. For instance, the mirror has seclabels
set, if it is a NVMe disk it is detached from the host and so on.
And usually, the restore is done upon successful finish of the
blockcopy operation. But, if something fails then we need to
explicitly revoke the access to the mirror image (and thus
reattach NVMe disk back to the host).

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1822538Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

When we do parallel migration, The multifd-channels migration parameter
needs to be set on the destination side as well before incoming migration
URI, unless we accept the default number of connections(2).

Usually, This can be correctly handled by libvirtd. But in this case if
we use p2p + xbzrle compression without parameter '--comp-xbzrle-cache',
qemuMigrationParamsDump returns too early, The corresponding migration
parameter will not be set on the destination side, It results QEMU hangs.

Reproducer:
virsh migrate --live --p2p --comp-methods xbzrle \
--parallel --parallel-connections 3 GUEST qemu+ssh://dsthost/system

or

virsh migrate --live --p2p --compressed \
--parallel --parallel-connections 3 GUEST qemu+ssh://dsthost/systemSigned-off-by: NLin Ma <lma@suse.com>
Message-Id: <20200416044451.21134-1-lma@suse.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

We always tried to install backing store for the image even if it didn't
make sense, e.g. for a full backup into a raw image. Additionally we
didn't record the backing file into the qcow2 metadata so the image
itself contained the diff of data but reading from it would be
incomplete as it depends on the backing image.

This patch fixes both issues by carefully installing the correct backing
file when appropriate and also recording it into the metadata when
creating the image.

https://bugzilla.redhat.com/show_bug.cgi?id=1813310Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

virDomainPCIAddressBusSetModel() is called for each PCI controller
when building an address set prior to assiging PCI addresses to
devices.

This patch adds a new argument, allowHotplug, to that function that
can be set to false if we know for certain that a particular
controller won't support hotplug

The most interesting case is in qemuDomainPCIAddressSetCreate(), where
the config of each existing controller is available while building the
address set, so we can appropriately set allowHotplug = false when the
user has "hotplug='off'" in the config of a controller that normally
would support hotplug. In all other cases, it is set to true or false
in accordance with the capability of the controller model.

So far we aren't doing anything with this bus flag in the address set.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When the HOTPLUGGABLE flag was originally added, it was set for all
the PCI controllers that accepted hotplugged devices, and requested
for all devices that were auto-assigned to a controller. While we're
still autoassigning to the same list of controllers, those controllers
may or may not support hotplug, so let's use the flag that fits what
we're actually doing.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If a pcie-root-port or pcie-downstream-port has hotplug='off' in its
<target> subelement, and if the qemu binary supports the hotplug=false
option, then it will be added to the commandline for the pcie
controller. This controller will then not allow any hotplug/unplug of
devices while the guest is running (and the hotplug capability won't
be advertised to the guest OS, so the guest OS also won't present
unplugging of PCI devices as an option).

  <controller type='pci' model='pcie-root-port'>
    <target hotplug='off'/>
  </controller>

For any PCI controllers other than pcie-downstream-port and
pcie-root-port, of for qemu binaries that don't support the hotplug
commandline option, an error will be logged during validation.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This caps flag is set when the qemu binary supports the option
"hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and
xio3130-downstream (Intel pcie-downstream-port). If it's available,
it's possible to disable hotplugging/unplugging devices on a
particular port by adding ",hotplug=off" to the qemu device
commandline. This option first appears in qemu-5.0.0.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Pass the packed option on the QEMU command line of the capability for
packed virtqueues is detected and the parameter is set explicitly.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Add the capability for QEMU's packed virtqueues for virtio that supposedly have
better cache utilization and performance compared to the default split queues.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Replace vm->def->disks[i] with dom_disk variable which is
initialized to the same disk.
Signed-off-by: NYi Li <yili@winhong.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

So far, libvirt generates the following path for automatic dumps:

  $autoDumpPath/$id-$shortName-$timestamp

where $autoDumpPath is where libvirt stores dumps of guests (e.g.
/var/lib/libvirt/qemu/dump), $id is domain ID and $shortName is
shortened version of domain name. So for instance, the generated
path may look something like this:

  /var/lib/libvirt/qemu/dump/1-QEMUGuest-2020-03-25-10:40:50

While in case of embed driver the following path would be
generated by default:

  $root/lib/libvirt/qemu/dump/1-QEMUGuest-2020-03-25-10:40:50

which is not clashing with other embed drivers, we allow users to
override the default and have all embed drivers use the same
prefix. This can create clashing paths. Fortunately, we can reuse
the approach for machined name generation
(v6.1.0-178-gc9bd08ee) and include part of hash of the root in
the generated path.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

So far, libvirt generates the following path for memory:

  $memoryBackingDir/$id-$shortName/ram-nodeN

where $memoryBackingDir is the path where QEMU mmaps() memory for
the guest (e.g. /var/lib/libvirt/qemu/ram), $id is domain ID
and $shortName is shortened version of domain name. So for
instance, the generated path may look something like this:

  /var/lib/libvirt/qemu/ram/1-QEMUGuest/ram-node0

While in case of embed driver the following path would be
generated by default:

  $root/lib/qemu/ram/1-QEMUGuest/ram-node0

which is not clashing with other embed drivers, we allow users to
override the default and have all embed drivers use the same
prefix. This can create clashing paths. Fortunately, we can reuse
the approach for machined name generation
(v6.1.0-178-gc9bd08ee) and include part of hash of the root in
the generated path.

Note, the important change is in qemuGetMemoryBackingBasePath().
The rest is needed to pass driver around.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

So far, libvirt generates the following path for hugepages:

  $mnt/libvirt/qemu/$id-$shortName

where $mnt is the mount point of hugetlbfs corresponding to
hugepages of desired size (e.g. /dev/hugepages), $id is domain ID
and $shortName is shortened version of domain name. So for
instance, the generated path may look something like this:

  /dev/hugepages/libvirt/qemu/1-QEMUGuest

But this won't work with embed driver really, because if there
are two instances of embed driver, and they both want to start a
domain with the same name and with hugepages, both drivers will
generate the same path which is not desired. Fortunately, we can
reuse the approach for machined name generation
(v6.1.0-178-gc9bd08ee) and include part of hash of the root in
the generated path.

Note, the important change is in qemuGetBaseHugepagePath(). The
rest is needed to pass driver around.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 06a19921.

What I haven't realized when writing this ^^ commit is that the
virQEMUDriver structure already stores the root directory path.
And since the pointer is immutable it can be accessed right from
the structure and thus there is no need to duplicate it in the
driver config.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The cfg->root is going away, therefore get the info right from
the driver structure.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The virDomainGenerateMachineName() function doesn't belong in
src/conf/ really, because it has nothing to do with domain XML
parsing. It landed there because of lack of better place in the
past. But now that we have src/hypervisor/ the function should
live there. At the same time, the function name is changed to
match new location.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Initially introduced in v3.10.0-rc1~172.

When generating a path for memory-backend-file or -mem-path, qemu
driver will use the following pattern:

  $memoryBackingDir/libvirt/qemu/$id-$shortName

where $memoryBackingDir defaults to /var/lib/libvirt/qemu/ram but
can be overridden in qemu.conf. Anyway, the "/libvirt/qemu/" part
looks redundant, because it's already contained in the default,
or creates unnecessary nesting if overridden in qemu.conf.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Introduced in v1.2.17-rc1~121, the assumption was that the
driver->privileged is immutable at the time but it might change
in the future. Well, it did not ever since. It is still immutable
variable. Drop the needless accessor then.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

This option prevents misbehaviours on guest if a qemu 9pfs export
contains multiple devices, due to the potential file ID collisions
this otherwise may cause.
Signed-off-by: NChristian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The QEMU 9pfs 'multidevs' option exists since QEMU 4.2. Probe QEMU's
command line set though to check whether this option is really
available, and if yes enable this new QEMU_CAPS_FSDEV_MULTIDEVS
capability on libvirt side.
Signed-off-by: NChristian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that all its helper functions are in qemu_validate.c, we can
move the function itself. The helpers can become static again since
they're all in the same file.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

This will allow to move qemuDomainDeviceDefValidate() itself in
the next patch in a cleaner way.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Move the function and all its static helper functions.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This function will remain public due to its usage in qemublocktest.c
even after moving qemuDomainDeviceDefValidate(). The position of its
header in qemu_validate.h is no accident.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>