The cleanup path expects that 'def' is assigned to 'priv->backup', but
that's not the case for early failures. Add a check to stop overwriting
of 'def' so that it can be freed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reuse qemuBlockGetBitmapMergeActions which allows the removal of the
ad-hoc implementation of bitmap merging for block copy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
New semantics of the bitmap handling don't need this. Remove the field
and all uses of it including the status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reuse qemuBlockGetBitmapMergeActions which allows removing the ad-hoc
implementation of bitmap merging for block commit. The new approach is
way simpler and more robust and also allows us to get rid of the
disabling of bitmaps done prior to the start as we actually do want to
update the bitmaps in the base.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reuse qemuBlockGetBitmapMergeActions which allows removal of the ad-hoc
implementation of bitmap merging for backup. The new approach is simpler
and also more robust in case some of the bitmaps break as they remove
the dependency on the whole chain of bitmaps working.
The new approach also allows backups if a snapshot is created outside of
libvirt.
Additionally the code is greatly simplified.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Add a function which allows merging bitmaps according to the new
semantics and will allow replacing all the specific ad-hoc functions
currently in use for 'backup', 'block commit', 'block copy' and will
also be usable in the future for 'block pull' and non-shared storage
migration.
The semantics are a bit quirky for the 'backup' case but these quirks
are documented and will prevent us from having two slightly different
algorithms.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Now that we've switched to the simple handling, the first thing that can
be massively simplified is checkpoint deletion. We now need to only go
through the backing chain and find the appropriately named bitmaps and
delete them, no complex lookups or merging.
Note that compared to other functions this deletes the bitmap in all
layers compared to others where we expect only exactly 1 bitmap of a
name in the backing chain to prevent potential problems.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reject duplicates and other problematic bitmaps according to the new
semantics of bitmap use in libvirt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Chaining bitmaps for checkpoints (disabling the active one and creating
a new) severely overcomplicated all operations in regards to bitmaps.
Specifically it requires us re-matching the on-disk state to the
internal metadata and in case of merging during block jobs it makes it
almost impossible to cover all corner cases.
Since the checkpoints and incremental backups were not yet enabled,
let's change the design to keep one bitmap per checkpoint. In case of
layered snapshots this will be filled in by using dirty-bitmap-populate.
Finally the main reason for this unnecessary complexity was the fear
that qemu's performance could degrade. In the end I think that
addressing the performance issue will be better done in qemu (e.g by
keeping an internal bitmap updated with changes and merging it
periodically back to the real bitmaps. QEMU writes out changes to disk
at shutdown so consistency is not a problem).
Removing the relationships between bitmaps frees us from complex
handling and also makes all the surrounding code more robust as one
broken bitmap doesn't necessarily invalidate whole chains of backups.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Fetch the checkpoint list for every disk specifically based on the new
per-disk 'incremental' field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
If a disk is not captured by one of the intermediate checkpoints the
code would fail, but we can easily calculate the bitmaps to merge
correctly by skipping over checkpoints which don't describe the disk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The algorithm is getting quite complex. Split out the lookup of range of
backing chain storage sources and bitmaps contained in them which
correspond to one checkpoint.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
In a few cases we might set seclabels on a path outside of
namespaces. For instance, when restoring a domain from a file,
the file is opened, relabelled and only then the namespace is
created and the FD is passed to QEMU (see v6.3.0-rc1~108 for more
info). Therefore, when restoring the label on the restore file,
we must ignore domain namespaces and restore the label directly
in the host.
This bug demonstrates itself when restoring a domain from a block
device. We don't create the block device inside the domain
namespace and thus the following error is reported at the end of
(otherwise successful) restore:
error : virProcessRunInFork:1236 : internal error: child reported (status=125): unable to stat: /dev/sda: No such file or directory
error : virProcessRunInFork:1240 : unable to stat: /dev/sda: No such file or directory
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The function calls virSecurityManagerDomainRestorePathLabel()
after all.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The new name is virSecurityManagerDomainRestorePathLabel().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
After previous commit this function is used no more.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
There are two places within qemu driver that misuse
qemuSecuritySetSavedStateLabel() to set seclabels on tempfiles
that are not state files: qemuDomainScreenshot() and
qemuDomainMemoryPeek(). They are doing so because of lack of
qemuSecurityDomainSetPathLabel() at the time of their
introduction.
In all three secdrivers (well, four if you count NOP driver) the
implementation of .domainSetSavedStateLabel and
.domainSetPathLabel callbacks is the same anyway.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Libvirt allows the user to define an incomplete NUMA topology, where
the sum of all CPUs in each cell is less than the total of VCPUs.
What ends up happening is that QEMU allocates the non-enumerated CPUs
in the first NUMA node. This behavior is being flagged as 'to be
deprecated' at least since QEMU commit ec78f8114bc4 ("numa: use
possible_cpus for not mapped CPUs check").
In [1], Maxiwell suggested that we forbid the user to define such
topologies. In his review [2], Peter Krempa pointed out that we can't
break existing guests, and suggested that Libvirt should emulate the
QEMU behavior of putting the remaining vCPUs in the first NUMA node
in these cases.
This patch implements Peter Krempa's suggestion. Since we're going
to most likely end up with disjointed NUMA configuration in node 0
after the auto-fill, we're making auto-fill dependent on QEMU_CAPS_NUMA.
A following patch will update the documentation not just to inform
about the auto-fill mechanic with incomplete NUMA topologies, but also
to discourage the user to create such topologies in the future. This
approach also makes Libvirt independent of whether QEMU changes
its current behavior since we're either auto-filling the CPUs in
node 0 or the user (hopefully) is aware that incomplete topologies,
although supported in Libvirt, are to be avoided.
[1] https://www.redhat.com/archives/libvir-list/2019-June/msg00224.html
[2] https://www.redhat.com/archives/libvir-list/2019-June/msg00263.html
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
No default model should be added to the interface
entry at post parse when its actual network type is hostdev
as doing so might cause a mismatch between the interface
definition and its actual device type.
Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The same functionality can be achieved using migrate-set-parameters QMP
command with xbzrle-cache-size parameter.
https://bugzilla.redhat.com/show_bug.cgi?id=1845012
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The same functionality can be achieved using query-migrate-parameters
QMP command and checking the xbzrle-cache-size parameter.
https://bugzilla.redhat.com/show_bug.cgi?id=1829544
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The same functionality can be achieved using migrate-set-parameters QMP
command with downtime-limit parameter.
https://bugzilla.redhat.com/show_bug.cgi?id=1829543
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The same functionality can be achieved using migrate-set-parameters QMP
command with max-bandwidth parameter.
https://bugzilla.redhat.com/show_bug.cgi?id=1829545
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These parameters were originally set via dedicated commands which are
now deprecated. We want to use migrate-set-parameters instead if
possible.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This function handles the change of NUMA nodeset for a given
guest, setting CpusetMems for the emulator, vcpus and IOThread
sub-groups. It doesn't set the same nodeset to the root cgroup
though. This means that cpuset.mems of the root cgroup ends up
holding the new nodeset and the old nodeset as well. For
a guest with placement=strict, nodeset='0', doing
virsh numatune <vm> 0 8 --live
Will make cpuset.mems of emulator, vcpus and iothread to be
"8", but cpuset.mems of the root cgroup will be "0,8".
This means that any new tasks that ends up landing in the
root cgroup, aside from the emulator/vcpus/iothread sub-groups,
will be split between the old nodeset and the new nodeset,
which is not what we want.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement secure guest check for AMD SEV (Secure Encrypted
Virtualization) in order to invalidate the qemu capabilities
cache in case the availability of the feature changed.
For AMD SEV the verification consists of:
- checking if /sys/module/kvm_amd/parameters/sev contains the
value '1': meaning SEV is enabled in the host kernel;
- checking if /dev/sev exists
Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This patch introduces a common function to verify if the
availability of the so-called Secure Guest feature on the host
has changed in order to invalidate the qemu capabilities cache.
It can be used as an entry point for verification on different
architectures.
For s390 the verification consists of:
- checking if /sys/firmware/uv is available: meaning the HW
facility is available and the host OS supports it;
- checking if the kernel cmdline contains 'prot_virt=1': meaning
the host OS wants to use the feature.
Whenever the availability of the feature does not match the secure
guest flag in the cache then libvirt will re-build it in order to
pick up the new set of capabilities available.
Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This is pretty straightforward and self explanatory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1837990
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This capability tracks whether QEMU supports -fw_cfg command line
option, more specifically whether it allows specifying filename.
There are some releases of QEMU which support -fw_cfg but not
filename. If this is ever a problem we can refine the capability
later on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are recommendations and limitations to the name of the
config blobs we need to follow [1].
We don't want users to change any value only add new blobs. This
means, that the name must have "opt/" prefix and at the same time
must not begin with "opt/ovmf" nor "opt/org.qemu" as these are
reserved for OVMF or QEMU respectively.
1: docs/specs/fw_cfg.txt from qemu.git
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has -fw_cfg which allows users to tweak how firmware
configures itself and/or provide new configuration blobs.
Introduce new <sysinfo/> type "fwcfg" that will hold these
new blobs.
It's possible to either specify new value as a string or
provide a filename which contents then serve as the value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Before QEMU introduced migratable CPU property, "-cpu host" included all
features that could be enabled on the host, even those which would block
migration. In other words, the default was equivalent to migratable=off.
When the migratable property was introduced, the default changed to
migratable=on. Let's record the default in domain XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit b50a8354f6 added call to qemuDomainDiskBlockJobIsSupported prior
to filling the 'disk' variable resulting in a crash when attempting a
block commit.
https://gitlab.com/libvirt/libvirt/-/issues/31
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If virDomainUpdateDeviceFlags() was used to update an <interface>, and
the interface type changed from type='network' where the network was
an unmanaged bridge (so actualType == bridge) to type='bridge'
(i.e. actualType *also* == bridge), the update would fail due to the
perceived change in type.
In practice it is okay to switch between any interface types that end
up using a tap device, since libvirt just needs to attach the device
to a new bridge. But in this case we were erroneously rejecting it due
to a conditional that was too restrictive. This is what the code was doing:
if (old->type != new->type)
[allow update]
else
if ((oldActual == bridge and newActual == network)
|| (oldActual == network and newActual == bridge)) {
[allow update]
else
[error]
In the case described above though, old->type and new->type don't match,
but oldActual and newActual are both 'bridge', so we get an error.
This patch changes the inner conditional so that any combination of
'network' and 'bridge' for oldActual and newActual, since they both
use a tap device connected to a bridge.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The ref count will be private to the GObject base class
and we must not peek at it, even for debugging messages.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
To prepare for a conversion to GObject, we need virObjectUnref
to have the same API design as g_object_unref, which means it
needs to be void.
A few places do actually care about the return value though,
and in these cases a thread local flag is used to determine
if the dispose method was invoked.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Some, but not all, of the monitor event handlers check
the virObjectUnref return value to see if the domain
was disposed.
It should not be possible for this to happen, since
the function already holds a lock on the domain and
has only just acquired an extra reference on the
domain a few lines earlier.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Upon migration with disks, libvirt determines if each disk exists
on the destination and tries to pre-create missing ones. Well,
NVMe disks can't be pre-created, but they can be checked for
presence.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1823639
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to the context, here we are checking net->downscript's validity,
Signed-off-by: Liao Pingfang <liao.pingfang@zte.com.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Support downscript for booting vm,
and hotunplug interface device.
Signed-off-by: Chen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit v3.10.0-182-g237f045d9a ("qemu: Ignore fallback CPU attribute
on reconnect") forced CPU 'fallback' to ALLOW, regardless of user
choice. This fixed a situation in which guests created with older
Libvirt versions, which used CPU mode 'host-model' in runtime, would
fail to launch in a newer Libvirt if the fallback was set to FORBID.
This would lead to a scenario where the CPU was translated to 'host-model'
to 'custom', but then the FORBID setting would make the translation
process fail.
PSeries can operate with 'host-model' in runtime due to specific PPC64
mechanics regarding compatibility mode. The update() implementation of
the cpuDriverPPC64 driver is a NO-OP if CPU mode is 'host-model', and
the driver does not implement translate(). The commit mentioned above
is causing PSeries guests to get their 'fallback' setting to ALLOW,
overwriting user choice, exposing a design problem in
qemuProcessRefreshCPU() - for PSeries guests, handling 'host-model'
as it is being done does not apply.
All other cpuArchDrivers implements update() and changes guest mode
to VIR_CPU_MODE_CUSTOM, meaning that PSeries is currently the only
exception to this logic. Let's make it official.
https://bugzilla.redhat.com/show_bug.cgi?id=1660711
Suggested-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200525123945.4049591-2-danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The host CPU related info stored in the capabilities cache is no longer
valid after the host CPU changes. This is not a frequent situation in
real world, but it can easily happen in nested scenarios when a disk
image is started with various CPUs.
https://bugzilla.redhat.com/show_bug.cgi?id=1778819
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use automatic cleanup on qemuProcessUpdateCPU and the functions called
by it.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-5-danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The intention of these split Load*Entry functions is to prevent
virQEMUDriverConfigLoadFile from getting too large.
There's no need to signal to the caller whether an entry was found
or not, only whether there was an error.
Remove the non-standard return 1.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
virConfGetValueString returns an allocated string that needs to be
freed.
Fixes: 34a59fb570
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
qemuxml2argv test suite is way more comprehensive than the hotplug
suite. Since we share the code paths for monitor and command line
hotplug we can easily test the properties of devices against the QAPI
schema.
To achieve this we'll need to skip the JSON->commandline conversion for
the test run so that we can analyze the pure properties. This patch adds
flags for the comand line generator and hook them into the
JSON->commandline convertor for -netdev. An upcoming patch will make use
of this new infrastructure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Now that all code paths generate JSON props we can remove the conversion
to command line arguments and back in the monitor code.
Note that the test which is removed in this commit will be replaced by a
stronger testsuite later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Syntax of guestfwd channel also needs to be modified to conform to the
QAPI schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The 'netdev_add' command was recently formally described in qemu via the
QMP schema. This means that it also requires the arguments to be
properly formatted. Our current approach is to generate the command line
and then use qemuMonitorJSONKeywordStringToJSON to get the JSON
properties for the monitor. This will not work if we need to pass some
fields as numbers or booleans.
In this step we re-do internals of qemuBuildHostNetStr to format a JSON
object which is converted back via virQEMUBuildNetdevCommandlineFromJSON
to the equivalent command line. This will later allow fixing of the
monitor code to use the JSON object directly rather than rely on the
conversion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Use automatic pointer cleanup for virJSONValuePtrs to get rid of the
cleanup label and ret variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
In qemu the argument of 'ipv6-net' is split up into 'ipv6-prefix' and
'ipv6-prefixlen'. Additionally now that 'netdev_add' was qapified, only
the real properties are allowed. Switch to using them explicitly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The output of the function is fed as argument to '-device' command line
argument or 'device_add' monitor command except for 'guestfwd' channels
where it needs to be fed to -netdev/netdev_add. This is confusing and
error prone. Split it up since the caller needs to know which
command/option to use anyways, so the caller can call the appropriate
function without any magic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Both active branches create the same backend chardev. Since there is no
other case, extract it before the switch so that we don't have to
duplicate it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
'tftp' storage protocol was supported by qemu until 2.7.0. Add an
interlock when blockdev is used and drop the test case for it as it's
IMO not worth adding another test file just for that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The qemu.conf change broke our augeas test:
qemu/test_libvirtd_qemu.aug:96.3-203.1:exception thrown in test
qemu/test_libvirtd_qemu.aug:96.8-.34:exception: Iterated lens matched less than it should
Lens: ../../src/qemu/libvirtd_qemu.aug:170.13-.43:
Last match: ../../src/qemu/libvirtd_qemu.aug:18.52-.113:
Not matching: ../../src/qemu/libvirtd_qemu.aug:12.19-.31:
Error encountered at 48:27 (1615 characters into string)
<\n "/dev/ptmx", "/dev/kvm"|=|,\n]\nsave_image_format = "raw>
Fixes: ab5ba57012
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The RTC and HPET modes for the QEMU emulation tick have been dropped
almost 9 years ago, in commit 25f3151ece1d5881826232bebccc21b588d4e03e.
Do not allow them in the devices cgroup policy.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Although the original patches to support controllers with
hotplug='off' were checking during hotplug/attach requests that the
device was being plugged into a PCI controller that didn't have
hotplug disabled, but I forgot to do the same for device detach (the
main impetus for adding the feature was to prevent unplugs originating
from within the guest, so it slipped my mind). So although the guest
OS was ultimately unable to honor the unplug request, libvirt could
still be used to make such a request, and since device attach/detach
are asynchronous operations, the caller to libvirt would receive a
success status back (the device would stubbornly/correctly remain in
the domain status XML however)
This patch remedies that, by looking at the controller for the device
in the detach request, and immediately failing the operation if that
controller has hotplug=off.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If the mirror destination is not a file but a NVMe disk, then
call qemuHostdevReAttachOneNVMeDisk() to reattach the NVMe back
to the host.
This would be done by blockjob code when the job finishes, but in
this case the job won't finish - QEMU is killed meanwhile.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1825785
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In v5.10.0-rc1~42 (which was later fixed in v6.0.0-rc1~487) I am
removing XATTRs for a file that QEMU is mirroring a disk into but
it is killed meanwhile. Well, we can call
qemuSecurityRestoreImageLabel() which will not only remove XATTRs
but also use them to restore the original owner of the file.
This would be done by blockjob code when the job finishes, but in
this case the job won't finish - QEMU is killed meanwhile
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In previous commit we started tracking whether QEMU supports
'-numa mem='. This is tied to the machine type because migration
from '-numa mem=' to '-numa memdev' is impossible (or vice
versa). But since it's tied to a machine type (where migration
from one to another is also unsupported) we can allow QEMU to get
rid of the deprecated command line.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1783355
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When building -numa command line there is a for() loop that
builds '-numa memdev=' for each guest NUMA node. And also
records in a local variable whether any of memory-object-*
backends must be used to satisfy desired config. Well, instead of
checking in each iteration whether corresponding capabilities are
set, we can do swap if() and for() and check only once.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There is 'numa-mem-supported' machine attribute which specifies
whether '-numa mem=' is supported. Store it in our capabilities
as it will be used in later commits when building the command
line.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
==179663== 35 (24 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 205 of 461
==179663== at 0x4839EC6: calloc (vg_replace_malloc.c:762)
==179663== by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1)
==179663== by 0x190C79: qemuDomainObjPrivateXMLParseBlockjobDataCommit (qemu_domain.c:3295)
==179663== by 0x190DF7: qemuDomainObjPrivateXMLParseBlockjobDataSpecific (qemu_domain.c:3331)
==179663== by 0x19157D: qemuDomainObjPrivateXMLParseBlockjobData (qemu_domain.c:3469)
==179663== by 0x1918E8: qemuDomainObjPrivateXMLParseBlockjobs (qemu_domain.c:3498)
==179663== by 0x193841: qemuDomainObjPrivateXMLParse (qemu_domain.c:3944)
==179663== by 0x4A1BA9D: virDomainObjParseXML (domain_conf.c:22306)
==179663== by 0x4A1BFE9: virDomainObjParseNode (domain_conf.c:22429)
==179663== by 0x4A1C0B4: virDomainObjParseFile (domain_conf.c:22443)
==179663== by 0x1431E1: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:61)
==179663== by 0x177722: virTestRun (testutils.c:142)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
==156803== 58 (40 direct, 18 indirect) bytes in 1 blocks are definitely lost in loss record 306 of 463
==156803== at 0x4839EC6: calloc (vg_replace_malloc.c:762)
==156803== by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1)
==156803== by 0x48F60DC: virAlloc (viralloc.c:48)
==156803== by 0x18DD74: qemuStorageSourcePrivateDataAssignSecinfo (qemu_domain.c:2384)
==156803== by 0x18DFD5: qemuStorageSourcePrivateDataParse (qemu_domain.c:2433)
==156803== by 0x49EC884: virDomainStorageSourceParse (domain_conf.c:9857)
==156803== by 0x49ECBA3: virDomainDiskBackingStoreParse (domain_conf.c:9909)
==156803== by 0x49F129D: virDomainDiskDefParseXML (domain_conf.c:10785)
==156803== by 0x4A1804E: virDomainDefParseXML (domain_conf.c:21543)
==156803== by 0x4A1B60C: virDomainObjParseXML (domain_conf.c:22254)
==156803== by 0x4A1BFE9: virDomainObjParseNode (domain_conf.c:22429)
==156803== by 0x4A1C0B4: virDomainObjParseFile (domain_conf.c:22443
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
A failure in qemuProcessLaunch would lead to qemuExtDevicesStop
being called twice - once in the cleanup section and then again
in qemuProcessStop.
However, the first one is called while the QEMU process is
still running, which is too soon for the swtpm process, because
the swtmp_ioctl command can lock up:
https://bugzilla.redhat.com/show_bug.cgi?id=1822523
Remove the first call and only leave the one in qemuProcessStop,
which is called after the QEMU process is killed.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This is not yet supported by virtiofsd.
Fixes#23 a.k.a. https://gitlab.com/libvirt/libvirt/-/issues/23
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Availability of the vmpvscsi controller model is gated by the pvscsi
capability.
Signed-off-by: Chris Jester-Young <cky@cky.nz>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This capability flags support for `-device pvscsi`, which provides the
VMware paravirtual SCSI controller.
Signed-off-by: Chris Jester-Young <cky@cky.nz>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
'blockdev-mirror' requires the write permission internally to do the
copy. This means that we have to force the image to be read-write for
the duration of the copy and can fix it after the copy is done.
https://bugzilla.redhat.com/show_bug.cgi?id=1832204
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With -blockdev or when reusing externally created images and thus
without the need for formatting the image we actually can support
snapshots of read-only disks. Arguably it's not very useful so they are
not done by default but users of libvirt such as oVirt are actually
using this.
https://bugzilla.redhat.com/show_bug.cgi?id=1832204
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need qemu to be able to write the newly created images so that it can
format them to the specified storage format.
Force write access by relabelling the images when formatting.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modern way to store <auth> and <encryption> of a <disk> is under
<source>. This was added to mirror how <backingStore> handles these and
in fact they are relevant to the source rather than to any other part of
the disk. Historically we allowed them to be directly under <disk> and
we need to keep compatibility.
This wasn't a problem until introduction of -blockdev in qemu using of
<auth> or <encryption> plainly wouldn't work with backing chains.
Now that it works in backing chains and can be moved back and forth
using snapshots/block-commit we need to ensure that the original
placement is properly kept even if the source changes.
To achieve the above semantics we need to store the preferred placement
with the disk definition rather than the storage source definitions and
also ensure that the modern way is chosen when the VM started with
<source/encryption> only in the backing store.
https://bugzilla.redhat.com/show_bug.cgi?id=1822878
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Any non-raw block layer feature will not work with raw SCSI command
passthrough via 'scsi-block'. Explicitly refuse use of luks encryption,
storage slices and copy on read.
https://bugzilla.redhat.com/show_bug.cgi?id=1820040
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically the virtio-blk frontend by default enabled SCSI emulation
and tried to do SCSI command passthrough. As this was enabled by default
there's a fallback mechanism in place in cases when the backend doesn't
support SCSI for any reason.
This is not the case when disk type=lun is used with 'scsi-block' via
'virtio-scsi'.
We did not restrict configurations when the user picks 'qcow2' or any
other format as format of the disk, in which case the emulation is
disabled as such configuration doesn't make sense.
This patch unifies the approach so that 'raw' is required both when used
via 'virtio-blk' and 'virtio-scsi' so that the user is presented with
the expected configuration. Note that use of <disk type='lun'> is
already very restrictive as it requires a block device or iSCSI storage.
Additionally the scsi emulation is now deprecated by qemu with
virtio-blk as it conflicts with virtio-1 and the alternative is to use
'virtio-scsi' which performs better and is along for a very long time.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The property was deprecated. Don't format it based on the new capability
if the user didn't explicitly request it.
https://bugzilla.redhat.com/show_bug.cgi?id=1829550
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically the 'scsi' passthrough feature of virtio-blk-pci
was enabled by default. Libvirt was disabling it due to security
implications outlined in libvirt commit v0.9.9-4-g177db08775 if it was
not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the
default value was changed to disabled in preparation for virtio-1.
Starting from QEMU-5.0 the 'scsi' property was also deprecated. There
replacement for the functionality is to use 'virtio-scsi' for the
purpose. This isn't a direct replacement though.
Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which
allows us to stop formatting the 'scsi=' property if it's disabled by
default and not requested so that we don't use deprecated features.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU-5.0 added 'default-value' field for any applicable property
returned by 'device-list-properties'. Add an optional callback for any
device property definition which will allow detection of features and
default values based on this new data.
This unfortunately means that the description of properties had to move
from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new
type (virQEMUCapsDevicePropsFlags) which also has the callback property
and the corresponding change in the initializers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Create a hash table of device property names which also stores the
corresponding JSON object so that the detection code can look at the
recently added 'default-value' field and possibly others.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use automatic cleanup of variables and current style of header.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virQEMUCapsProbeQMPGenericProps is used only in one place now. Move the
code directly to virQEMUCapsProbeQMPObjectTypes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reimplement device property detection directly rather than using
virQEMUCapsProbeQMPGenericProps in preparation for changes to the
detection code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function was parsing 'qom-list-types' and then also calling function
which parses 'device-list-properties' and also 'qom-list-properties'.
Split it up into individual functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Help QEMU in deprecation of -drive if=none without the need to refactor
all old boards. Stop masking out -blockdev support when -drive if=sd
needs to be used. We achieve this by forbidding blockjobs and
special-casing all other code paths. Blockjobs are sacrificed in this
case as SD cards are a corner case for some ARM boards and are thus not
used commonly.
https://bugzilla.redhat.com/show_bug.cgi?id=1821692
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
SD cards need to be instantiated via -drive if=sd. This means that all
cases where we use the blockdev path need to be special-cased for SD
cards.
Note that at this point QEMU_CAPS_BLOCKDEV is still cleared if the VM
config has a SD card.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use the drive alias for all cases when we can't generate qomName. This
is meant to handle disks on 'sd' bus which are instantiated via -drive
if=sd as there isn't any specific QOM name for them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We still have to use -drive to instantiate sd disks. Combining that with
the new logic for blockjobs would be very complicated and not worth it
given that 'sd' cards work only on few rarely used machine types of
non-common architectures and libvirt didn't implement support for 'sd'
bus controllers. This will allow us to use -blockdev for other kinds on
such machines while sacrificing block jobs.
Note: this is currently no-op as we mask-out the QEMU_CAPS_BLOCKDEV
capability if any of the disks has bus='sd'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We can't set the type of the device on the 'sd' bus and realistically a
cdrom doesn't even make sense there. Forbid it.
Note that the output of in disk-cdrom-bus-other.x86_64-latest.args
switched to blockdev as it's no longer locked out due to use of a disk
on 'sd' bus.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In case of 'sd' cards we'll use pre-blockdev code also if qemu supports
blockdev. In that specific case we'll need to mask out blockdev support
for 'sd' disks. Plumb in a boolean to allow it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make sure that we don't try to reload node names with -blockdev. If
something doesn't have a node name the update will not make the
situation better.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
