Attaching a newly created vhostuser port to a VM fails due to an
apparmor denial
internal error: unable to execute QEMU command 'chardev-add': Failed
to bind socket to /run/openvswitch/vhu838c4d29-c9: Permission denied
In the case of a net device type VIR_DOMAIN_NET_TYPE_VHOSTUSER, the
underlying chardev is not labeled in qemuDomainAttachNetDevice prior
to calling qemuMonitorAttachCharDev.
A simple fix would be to call qemuSecuritySetChardevLabel using the
embedded virDomainChrSourceDef in the virDomainNetDef vhostuser data,
but this incurs the risk of incorrectly restoring the label. E.g.
consider the DAC driver behavior with a vhostuser net device, which
uses a socket for the chardev backend. The DAC driver uses XATTRS to
store original labelling information, but XATTRS are not compatible
with sockets. Without the original labelling information, the socket
labels will be restored with root ownership, preventing other
less-privileged processes from connecting to the socket.
This patch avoids overloading chardev labelling with vhostuser net
devices by introducing virSecurityManager{Set,Restore}NetdevLabel,
which is currently only implemented for the apparmor driver. The
new APIs are then used to set and restore labels for the vhostuser
net devices.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that resource structure can have appid as well we need to adapt code
that creates default resource partition if not provided by user.
Otherwise starting a VM with appid defined would fail with following
error:
error: unsupported configuration: Resource partition '(null)' must start with '/'
Fixes: 38b5f4faab
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Clang on Rawhide started to complain that @tmp variable in
virSCSIDeviceListDel() is set but not used. This is obviously a
false positive because the variable is used to free device stolen
from the list. Anyway, we can do without the variable so in this
specific case let's fix our code to appease Clang.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In qemumigrationcookiexmltest and qemustatusxml2xmltest there is
@cfg variable that is unused. It's set via virQEMUDriverGetConfig()
but then never used. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The virPCIDeviceIsBehindSwitchLackingACS() function checks
whether given PCI device is not behind a switch that lacks ACS.
It does so by starting at given device and traversing up, one
parent at time towards the root. The parent device is obtained
via virPCIDeviceGetParent() which allocates new virPCIDevice
structure. For freeing the structure we use g_autoptr() and a
temporary variable @tmp. However, Clang fails to understand our
clever algorithm and complains that the variable is set but never
used. This is obviously a false positive, but using a small trick
we can shut Clang up.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When the VM is inactive the 'virStorageSource' struct doesn't have the
necessary data pointing to the actual storage. This is a problem for
inactive snapshot operations on VMs which use disk type='volume'.
Add the translation steps for reversion and deletion of snapshots.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1977155
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/202
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cases when we are adding a <transient/> disk with sharing backend
(and thus hotplugging it) we need to re-initialize ACPI tables so that
the VM boots from the correct device.
This has a side-effect of emitting the RESET event and forwarding it to
the clients which is not correct.
Fix this by ignoring RESET events during startup of the VM.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When qemu supports 'set-action' command we can update what happens on
reboot. Additionally we can fully relax the checks as we now properly
update the lifecycle actions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We don't use the value of the flag when the new handling is in place so
we don't have to initialize it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The '-no-shutdown' flag prevents qemu from terminating if a shutdown was
requested. Libvirt will handle the termination of the qemu process
anyways and using this consistently will allow greater flexibility for
the virDomainSetLifecycleAction API as well as will allow using
the 'system-reset' QMP command during startup to reinitiate devices
exported to the firmware.
This efectively partially reverts 0e034efaf9
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than using '-no-reboot' use the QMP command to update the
lifecycle action of 'on_reboot'.
This will be identical to how we set the behaviour during lifetime and
also avoids problems with use of the 'system-reset' QMP command during
bringup of the VM (used to update the firmware table of disks when disks
were hotplugged as part of startup).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The RESET event is delivered by qemu only when the guest OS is actually
allowed to reboot ('-no-reboot' or equivalent is not used) and due to
the nature of async handling of the events VM is actually already
executing guest code after the reboot, until our code gets to killing
it.
In general it should have been impossible to reach a state where the
reboot action is 'destroy' but we didn't use '-no-reboot' but due to
various bugs it was.
Due to the fact that this was not a desired operation and additionally
guest code already is executing I think the best option is not to kill
the VM any more (possible data loss?) and rely for the proper fix where
we use the new 'set-action' QMP command to enable an equivalent
behaviour to '-no-reboot' during runtime.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Without the ability to tell qemu to change the behaviour on reboot of
the guest it's fundamentally unsafe to change the action as the guest
would be able to execute instructions after the reboot before libvirt
terminates it due to the async nature of QMP events.
Stricten the code for now until we implement support for 'set-action'
QMP command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Directly use 'priv->allowReboot' as we now document what the behaiour is
to avoid another lookup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The original idea was to ensure that the destination has the same
original state of the '-no-reboot' flag to ensure identical behaviour of
the 'vidDomainModifyLifecycleAction' API.
With newer qemu's we'll be able to modify the behaviour using the
monitor so old daemons won't be able to keep up anyways.
Remove this feature as it's not very useful and will be replaced by a
proper solution.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Save further readers the headache of determining what it actually does
and note that it's not used with qemu version supporting the
'set-action' command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will modify how '-no-reboot' is handled when qemu
supports the 'set-action' QMP command. Add a test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If current qemu supports 'set-action' use it instead of the single-use
command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'set-action' QMP command allows modifying the behaviour when the
guest resets.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We simply terminate qemu instead of issuing a reset as the semantics of
the setting dictate.
Fix it by handling it identically to 'fake reboot'.
We need to forbid the combination of 'onReboot' -> 'destroy' and
'onPoweroff' -> reboot though as the handling would be hairy and it
honetly makes no sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The qemu driver didn't ever implement any meaningful handling for the
'preserve' action.
Forbid the flag in the qemu def validator and update the documentation
to be factual.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Some actions are not supported by qemu. Use the recently added
'qemuValidateLifecycleAction' helper to ensure that the API does the
same validation as we do on startup in the validation callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The qemu driver didn't ever implement any meaningful handling for the
'rename-restart' action.
At this point the following handling would take place:
'on_reboot' set to 'rename-restart' is ignored on guest-initiated
reboots, the guest simply reboots.
For on_poweroff set to 'rename-restart' the following happens:
guest initiated shutdown -> 'destroy'
libvirt initiated shutdown -> 'reboot'
In addition when 'on_reboot' is 'destroy' in addition to 'on_poweroff'
being 'rename-restart' the guest is able to execute instructions after
issuing a reset before libvirt terminates it. This will be addressed
separately later.
Forbid the flag in the qemu def validator and update the documentation
to be factual.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We've got multiple random open-coded versions. Switch to the helper
function which doesn't report errors as they'd be mostly wrong as the
operation was indeed successful.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The public API wrapper range-checks the arguments. Save the next reader
the hassle of looking it up.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This one will be slightly unstable given that CPU features are being
modified frequently in qemu especially when used with a modern cpu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The host model expansion depends on the capability data, so in this case
it makes sense to have specific invocations of the test for all qemu
versions we have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch to q35 in anticipation of using DO_TEST_CAPS* in further patches.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the larger number in the original test to avoid having two files.
Additionally this avoids use of 'host-model' with DO_TEST_CAPS_LATEST in
cases when it isn't necessary for the purpose of the test as the CPU
model tends to change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case doesn't really test anything about the specific CPU. Using
a host-model cpu with DO_TEST_CAPS_LATEST results in commandline changes
every time qemu updates the cpu definiton.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need to validate the XML against schema if option '--validate'
was passed to the virsh command. This patch also includes
propagation of flags into the virStoragePoolDefParse() function.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I removed negation from the name of a variable to make the code
more readable.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
They require the caller to provide the maximum number
of array elements upfront, leading to either incomplete
results or violations of the zero-one-infinity rule.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Q35 machine types 2.3 and older had an integrated floppy controller.
Support for these machine types was removed by QEMU commit
commit 86165b499edf8b03bb2d0e926d116c2f12a95bfe
q35: Remove old machine versions
git describe: v2.5.0-1530-g86165b499e contains: v2.6.0-rc0~76^2~4
In libvirt, we have bumped the minimum QEMU version to 2.11:
commit b4cbdbe90b
qemu: Formally deprecate support for qemu < 2.11
git describe: v7.3.0-13-gb4cbdbe90b contains: v7.4.0-rc1~300
Since this QEMU version only supports Q35 machine versions 2.4+,
remove the code dealing with older ones.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Simon Rowe <simon.rowe@nutanix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
