Michal Privoznik [Thu, 18 Jun 2026 07:53:09 +0000 (09:53 +0200)]
virsh: Make --type argument of detach-interface optional
The detach-interface virsh command requires domain (obviously)
and --type to identify <interface/>. Optionally, --mac can be
provided to chose from multiple interfaces. Well, that renders
--type argument redundant. I mean, if there are but unique MACs
within domain XML, then interface type is implied. If there are
duplicate MACs then --type can help to differentiate, though at
that point detach-device seems like a better fit.
Long story short, make --type optional.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 18 Jun 2026 07:20:25 +0000 (09:20 +0200)]
lxc: Rework cleanup section in lxcDomainAttachDeviceNetLive()
The cleanup section in lxcDomainAttachDeviceNetLive() is
suspicious. It checks @ret for success and adds net into domain
definition. This is not something fits into cleanup. It belongs
right before 'ret = 0' line when we know everything before
succeeded. Moving that piece of code where it belongs, the
cleanup section becomes error because it is executed only in case
of failure.
Change the label to error, fix corresponding goto-s, and drop
@ret variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 18 Jun 2026 07:14:15 +0000 (09:14 +0200)]
lxc: Don't leak @veth in lxcDomainAttachDeviceNetLive()
During hotplug of an <interface/> into an LXC domain
(lxcDomainAttachDeviceNetLive()), the host side name of the
interface is stored in @veth variable. Well, all possible paths
that set the variable (virLXCProcessSetupInterfaceTap(),
virLXCProcessSetupInterfaceDirect()) document it is caller's
responsibility to free the memory. But it never does so.
==49848== 12 bytes in 2 blocks are definitely lost in loss record 68 of 1,763
==49848== at 0x4913888: malloc (vg_replace_malloc.c:447)
==49848== by 0x546F0BC: __vasprintf_internal (in /usr/lib64/libc.so.6)
==49848== by 0x5077A70: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x50404DB: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x50405A4: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x4A8591E: virNetDevGenerateName (virnetdev.c:3573)
==49848== by 0x4A93C38: virNetDevVethCreate (virnetdevveth.c:124)
==49848== by 0xED6C505: virLXCProcessSetupInterfaceTap (lxc_process.c:279)
==49848== by 0xED5F7A7: lxcDomainAttachDeviceNetLive (lxc_driver.c:3517)
==49848== by 0xED60D24: lxcDomainAttachDeviceLive (lxc_driver.c:3925)
==49848== by 0xED6262D: lxcDomainAttachDeviceFlags (lxc_driver.c:4453)
==49848== by 0xED62819: lxcDomainAttachDevice (lxc_driver.c:4485)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 17 Jun 2026 15:20:20 +0000 (17:20 +0200)]
lxc: Drop pointless g_free() from virLXCProcessStart()
When staring an LXC domain (well, container) its consoles are
opened and each one is assigned an alias (for later use with
virDomainOpenConsole()). Now, before generating new alias the old
one is freed. But the old one can never be anything other than
NULL. The domain is inactive at this point (we are in process of
starting it, after all). And LXC driver does not support user
aliases, yet.
Just drop the pointless g_free().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Wed, 10 Jun 2026 10:38:00 +0000 (12:38 +0200)]
qemuDeviceVideoGetModel: Simplify by relying on checks from 'qemuValidateDomainDeviceDefVideo'
'qemuValidateDomainDeviceDefVideo' ensures that only the correct video
device models are selected as well as that only QXL and VIRTIO video
devices can be selected as secondary.
Remove unnecessary checks and simplify the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 9 Jun 2026 20:02:21 +0000 (22:02 +0200)]
qemuDeviceVideoGetModel: Remove logic for selecting 'virtio' devices
The virtio video device frontend type is either selected by the
post-parse code based on capabilities or provided by the user/existing
XML explicitly. No need to try to come up with a model when generating
commandline based on broken logic.
The difference in test output shows:
- honours user's config in case of the new 'device' attribute
- shows how incorrect fallback would be used for 'virtio-vga-gl'
(picked virtio-vga (non-gl) instead of 'virtio-gpu-gl')
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 10 Jun 2026 12:45:24 +0000 (14:45 +0200)]
qemuValidateDomainDeviceDefVideo: Fix checks of virtio video devices
The currently existing checks are broken:
- only QEMU_CAPS_DEVICE_VHOST_USER_GPU is checked for vhostuser
backends (vhost-user-vga is actually separately packaged)
- the check for the 3d accelerated (-gl) versions checks only if one
of them exists (the commandline formatter picks a non-gl afterwards)
- 'virtio-vga'/'virtio-gpu' is not checked at all
The code also doesn't yet check if, when the user passes the new
'device' property manually the config actually makes sense.
To fix all of the above introduce a table of supported frontend devices
as well as properties that need to be checked for them.
This requires fixing a recently-introduced test case which shows a
nonsensical situation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 8 Jun 2026 14:54:50 +0000 (16:54 +0200)]
qemu: postparse: Fill in selected virtio video frondend device in the XML
Historically 'virtio-vga' was always picked as the first '<video>'
(virtio) device and any sub-sequent ones were 'virtio-gpu'. When support
for aarch64 VMs was being added an exception to use 'virtio-gpu' for the
primary device was added as aarch64 doesn't have anything resembling the
"legacy" 'VGA' interface. At this point this exception was only for
aarch64. The distinction between 'virtio-vga' and 'virtio-gpu' was *not*
recorded in the VM XML as it was a new feature (for aarch64) and it
didn't make sense to pick 'virtio-vga'.
qemu_command: properly detect which model to use for video device
This improves commit 706b5b6277 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not. This is not a case only for arm/aarch64.
modified the code to do this picking by checking presence of
'virtio-vga' device instead. That approach didn't consider the fact that
the modular deployment of qemu allows for the 'virtio-vga' device to be
missing in certain cases, thus introducing a latent bug as we'll pick
'virtio-gpu' in such case but don't record it anywhere.
Now this creates a problem, if the deployments differ, because you can
have two *incompatible* (at migration stream level) setups which are
based on the same identical XML without the possibility for the
destination libvirt instance during migration to pick which is the
correct one.
To prevent this and actually fix any existing such deployment (which
allows upgrade of libvirt daemons on the source) we will record the
picked device frontend at post-parse time into the XML. This luckily
properly handles running VMs even if 'virtio-vga' were already
installed since we record the actual qemuCaps we've started the VM with.
Now 'virtio-vga' vs 'virtio-gpu' is not the only broken piece of logic.
In fact 'virtio-vga-gl' could have been downgraded to 'virtio-vga' based
on some very weird logic (see comments in code for explanation).
The logic in 'qemuDomainDeviceVideoDefPostParse' re-creates the logic
used to setup virtio-vga vs. virtio-gpu, and 'vhost-user-vga' vs.
'vhost-user-gpu' as those still make sense. For the 'gl' variants two
versions exist, one meant to recover running VMs and one for new VMs
where the broken logic makes no sense.
Now this patch just records what was selected into the XML, but doesn't
yet modify the commandline to actually use that value verbatim (e.g. if
the user specified an actual non-default value already).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 8 Jun 2026 13:11:45 +0000 (15:11 +0200)]
qemuDeviceVideoGetModel: Directly return picked model
There's no point in falling through to the check reporting invalid
type since if the code picks a model that one will be valid.
Reorganize the code so that we can return final decision right away.
This means that the two flags 'virtio' and 'virtioBusSuffix' need to be
set prior to the return.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 8 Jun 2026 14:55:05 +0000 (16:55 +0200)]
conf: Add fields for recording actually-selected virtio video device
QEMU's commandline generator picks for virtio video between various
actual device models not only based on the XML definition but also
capabilities present. Since none of the devices is actually ABI
compatible we need to record the actually selected device in the XML.
which will record the actually selected model so that we can preserve
ABI across restarts on deployment changes but more importantly across
migrations where the deployment differs.
The code specifically avoids an ABI stability check for the new field
because there are already possibly broken configurations that the users
may want to fix by picking the proper model which could be forbidden.
Users are instructed to not set the field in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 8 Jun 2026 15:30:50 +0000 (17:30 +0200)]
qemustatusxml2xml: Add test case capturing virtio video device
Add example of two running configs with distinct recorded capabilities
(presence of QEMU_CAPS_DEVICE_VIRTIO_VGA at startup) which will
demonstrate the recording of the picked actual device type on the
commandline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 10 Jun 2026 14:31:44 +0000 (16:31 +0200)]
qemuxmlconftest: Add invocation of 'video-virtio-vga-gpu-gl' with missing caps and VIR_DOMAIN_DEF_PARSE_ABI_UPDATE
Similarly to previous patch add testing of 'virtio-gpu-gl' or
'virtio-vga-gl' with missing the respective capabilities, but this time
allowing VIR_DOMAIN_DEF_PARSE_ABI_UPDATE.
This will later on show that in case when the fallback can't be honoured
the code will not pick a device that doesn't support acceleration (the
non-gl variant).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 9 Jun 2026 12:33:04 +0000 (14:33 +0200)]
qemuxmlconftest: Add test cases for configs asking for 'virtio-gpu-gl' or 'virtio-vga-gl' without the capability
The capability check in 'qemuValidateDomainDeviceDefVideo' which
validates whether a <video> definition with acceleration enabled is
possible is only aggregate, thus validates that any '-gl' video backend
is available.
Since qemu compiles each backend into a separate module it's possible to
have an installation where 'virtio-gpu-pci-gl' exist but 'virtio-vga-gl'
doesn't and it will not be rejected at validation. The commandline
though will generate a device *without* the '-gl' which is ABI
incompatible with the counterpart which does have '-gl', but the VM
starts. If such a VM is then migrated to a deployment which does have
the '-gl' variant available, migration will fail because qemu will
generate the '-gl' device as we don't record this fact in the XML.
This test case captures this situation which will be fixed later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 26 May 2026 12:14:31 +0000 (14:14 +0200)]
qemuxmlconftest: Add 'video-virtio-vga' invocation with QEMU_CAPS_DEVICE_VIRTIO_VGA disabled
The test case shows that if the 'QEMU_CAPS_DEVICE_VIRTIO_VGA' capability
is not present (e.g. if the corresponding qemu module isn't installed)
libvirt will pick:
-device '{"driver":"virtio-gpu-pci", ...
instead of:
-device '{"driver":"virtio-vga", ...
but without any discernable difference in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will add additional testing for various virtio-*-gl
devices, including filling of the default model. The output file needs
to not influnece the input for this test to work properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 26 May 2026 09:39:28 +0000 (11:39 +0200)]
virQEMUCapsCacheLookupDefault: Fix error message when no emulators are installed
When querying capabilities for the default emulator with no other
arguments (e.g. 'virsh domcapabilities) fix error whithout emulator
installed an error is reported but the error would mention '(null)'
architecture:
# virsh domcapabilities
error: failed to get emulator capabilities
error: unsupported configuration: unable to find any emulator to serve '(null)' architecture
This happens as the error formatting takes 'archStr' which is NULL for
the default architecture instead of using 'arch' which is populated by
the host's architecture and converting it back.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 11 Jun 2026 10:56:17 +0000 (12:56 +0200)]
qemu: postparse: Process VM config with qemuCaps influenced by <qemu:capabilities>
The user configuration of added/removed qemu capabilities via the qemu
namespace element was applied only right before generating a
commandline, but the post parse code code didn't see these.
Apply the capability modification prior to running post parse code so
that defaults are properly picked based on the configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 11 Jun 2026 10:52:16 +0000 (12:52 +0200)]
qemu: validate: Validate VM config with qemuCaps influenced by <qemu:capabilities>
The user configuration of added/removed qemu capabilities via the qemu
namespace element was applied only right before generating a
commandline, but the validation code didn't see these.
Modify the validation entry points so that they apply this optionally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 11 Jun 2026 10:00:45 +0000 (12:00 +0200)]
qemu: Allow reuse of 'qemuProcessStartUpdateCustomCaps'
Move and rename the function to 'qemuDomainUpdateCustomCapabilities' and
modify the arguments so that it will be possible to reuse it also in the
post-parse and validation code which ought to base decisions on the same
logic as VM startup would.
Since copying of the qemu capabilities object is very expensive (I've
observed an almost 4x slowdown of qemuxmlconftest)
'qemuDomainUpdateCustomCapabilities' copies the capabilities only when
necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 11 Jun 2026 10:12:42 +0000 (12:12 +0200)]
qemu: capabilities: Export 'virQEMUCapsNewCopy' outside of 'qemu_capspriv'
Upcoming patch will add a function which will need to optionally copy
passed capabilities for modification. Export 'virQEMUCapsNewCopy'
outside of tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 11 Jun 2026 09:33:36 +0000 (11:33 +0200)]
qemu: capabilities: Apply 'capability_filters' configration option on all capabilities
The 'capability_filters' allows admins to globally disable some qemu
capabilities via the config file.
Until now it was applied only directly when starting the VM, but that is
too late as the capability is still present when e.g. the post-parse
code is picking defaults.
Rework the code so that 'capability_filters' is applied directly after
probing qemu so all existing capabilities will lack the filtered out
ones.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The bhyveConnectAgent() function calls qemuAgentOpen() to open an agent
connection. If it fails, e.g. because of insufficient permissions to
open the socket, it returns NULL. Currently, if that happens,
bhyveConnectAgent() just sets agentError to true and exits with 0.
This does not match the contract of bhyveDomainEnsureAgent(), which
should either provide an agent connection or fail.
Fix that by returning -1 when qemuAgentOpen() fails. To make intent
clearer, add a documentation for bhyveConnectAgent().
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, the bhyve driver reboot implementation
does not take into account domain's on_reboot action.
Update it so it shuts a domain down on reboot when it is
configured this way.
Additionally, introduce the bhyveDomainShutdownSignal() helper
which shares a common shutdown and reboot implementation
using a signal.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the bhyve driver shutdown implementation
does not take into account domain's on_poweroff action.
Update it so it reboots a domain on shutdown when it is
configured this way.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 25 May 2026 15:15:31 +0000 (17:15 +0200)]
testutils: Turn 'virTestDummyFDContext' into a proper type
'virTestDummyFDContext' was a copy of GHashTable to be able to register
a cleanup function. Upcoming patches will want to track more data
together with the hash table so turn virTestDummyFDContext into a proper
struct which contains the hash table.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 21 May 2026 15:06:32 +0000 (17:06 +0200)]
Avoid use of glib's G_REGEX_OPTIMIZE flag
glib's G_REGEX_OPTIMIZE invokes pcre's JIT optimizer which requires
writable executable memory. On hosts with SELinux this by default caused
AVC denials to be logged. The solution in Fedora's SELinux policy was
to allow execmem for e.g. virtqemud, but e.g. virtlogd or
libvirt_leaseshelper on the other hand got a 'dontaudit' rule.
Now the optimizer itself does have a substantial effect; I've measured
around 3x speedup when matching VIR_LOG_REGEX against a sample of a qemu
VM log file. On the other hand, only 3 out of 10 uses of 'g_regex_new'
used the flag and also none of the regexes which used 'G_REGEX_OPTIMIZE'
are on a hot path:
- virDomainQemuMonitorEventStateRegisterID
Used only when custom qemu monitor event callback is registered,
which resides in libvirt_qemu.so so noone will actually use this
in production.
- virCommandRunRegex
Used in:
- virStorageBackendFileSystemNetFindNFSPoolSources
Invoked only via API on output of 'showmount'. Unlikely to ever
see lots of data.
Both of the above are used on code paths processing log output
when failure to startup a VM process or one of the helper
processes for devices for a qemu domain. Thus they are not invoked
on success and the processed buffer is capped to 1k of data.
Since none of the above are on anything resembling a hot path and thus
likely to substantially benefit from the optimizer, and we do have
plenty of other uses without optimization, drop the optimizations
everywhere and add a note to sc_G_REGEX_OPTIMIZE that we're currently
avoiding the use of this flag.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 25 May 2026 08:14:25 +0000 (10:14 +0200)]
syntax-check: Add warning about implications of G_REGEX_OPTIMIZE
glib's G_REGEX_OPTIMIZE flag for regex operations implies the use of
pcre's JIT optimizer for regexes which requires writable executable
memory for the optimized code.
Security frameworks such as SELinux can restrict program's access to
writable executable memory to harden the code.
glib's implementation of the regex functions handles downgrade to
interpreted evaluation of regexes gracefully if writable executable
memory is unavailable, but that is non-obvious and has a performance
penalty.
Add a syntax check which requires all uses of G_REGEX_OPTIMIZE to be
annotated so that the reader of the code can be hinted to why
G_REGEX_OPTIMIZE should perhaps be avoided.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fima Shevrin [Fri, 22 May 2026 15:49:27 +0000 (15:49 +0000)]
qemu: validate: treat only real backing chains as NVRAM backingStore
qemuDomainInitializePflashStorageSource() always attaches a non-NULL
src->backingStore used as an empty virStorageSource chain terminator
(type VIR_STORAGE_TYPE_NONE). qemuValidateDomainDefNvram() incorrectly
interpreted every non-NULL backingStore as a genuine backing overlay and
reported VIR_ERR_CONFIG_UNSUPPORTED, so legitimate UEFI/NVRAM setups were
rejected.
Use 'virStorageSourceHasBacking' helper as the check.
Fixes: d57630c282ae7220d8998f74b7e4fec21841797f Signed-off-by: Fima Shevrin <efim.shevrin@virtuozzo.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Akash Kulhalli [Wed, 20 May 2026 11:19:38 +0000 (16:49 +0530)]
virsh: allow async vcpu options to reach drivers
Do not reject setvcpu --enable --async or setvcpus --guest --async in virsh.
For setvcpu, async only affects live unplug and is documented as having no
effect when enabling vCPUs. For setvcpus, guest+async is a driver-visible flag
combination; drivers should decide whether they can support it. Keep virsh
validation limited to API-level constraints and let drivers report unsupported
combinations.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Akash Kulhalli [Wed, 20 May 2026 11:19:37 +0000 (16:49 +0530)]
domain: use vcpu-specific flag aliases consistently
The vCPU APIs have API-specific flag enums that alias the generic
VIR_DOMAIN_AFFECT_* values for live and config state.
Use the vCPU-specific aliases in the public API checks, QEMU driver flag masks,
and virsh flag construction. The values are unchanged; this is only a
consistency cleanup.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
virpci: don't fail VFIO passthrough when /sys/module/*/drivers is inaccessible
On monolythic kernel /sys/modules/*/drivers may not exist (ENOENT)
On kernels with enhanced security (e.g. grsecurity), it might not be
accessible: EACCESS or EPERM.
Directly try to open if it fails with any of those errors, we fallback
on the module name.
Signed-off-by: Baptiste Daroussin <baptiste.daroussin@ovhcloud.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virpci: don't fail VFIO passthrough when modules.alias is missing
When modules.alias is not available (e.g. monolithic kernel),
virPCIDeviceFindBestVFIOVariant() would fail, causing the entire
PCI device detach to abort.
Instead, log a warning and return success with no variant found,
allowing the caller to fall back to the generic vfio-pci driver.
Signed-off-by: Baptiste Daroussin <baptiste.daroussin@ovhcloud.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
PUSHKARAJ PATIL [Fri, 1 May 2026 16:08:12 +0000 (21:38 +0530)]
virt-aa-helper: Prevent spurious denials for AoE disks
virt-aa-helper calls virStorageSourceGetMetadata before adding a disk
path to a domain's apparmor profile. This probes the device and may
trigger an AppArmor denial when the disk is an AoE device under
/dev/etherd/.
The return value of virStorageSourceGetMetadata is not checked, so the
denial has no functional impact but results in noisy dmesg logs.
Explicitly deny read access to /dev/etherd/e*.* in the virt-aa-helper profile to
avoid these spurious denials.
Co-Authored-By: Peter Krempa <pkrempa@redhat.com> Signed-off-by: PUSHKARAJ PATIL <pushkaraj.patil@in.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyveDomainQemuAgentCommand() uses
bhyveDomainAgentAvailable()
which works only if the agent was already initialized.
It should use bhyveDomainEnsureAgent() instead.
Also, remove the bhyveDomainAgentAvailable() function,
there are no cases when it should be used instead of
bhyveDomainEnsureAgent().
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyveDomainEnsureAgent() returns successfully (with 0 return
value) even in cases when the agent is not configured.
That happens because the bhyveConnectAgent() function does not fail
if it cannot find the agent configuration. This might result in
accessing the agent pointer at NULL.
Fix by making bhyveConnectAgent() failing if the agent is not
configured.
Additionally, only call bhyveFindAgentConfig() when the agent is
not configured to avoid unnecessary checks every time the agent is
needed.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Denis V. Lunev [Thu, 28 May 2026 19:36:53 +0000 (21:36 +0200)]
qemu: Inherit SCSI controller model from existing peers
virDomainDefMaybeAddHostdevSCSIcontroller() already inherits the
model of an existing SCSI controller when auto-adding peers driven
by a hostdev whose drive address overflows the highest declared
idx. virDomainDefAddDiskControllersForType(), called for the
disk-driven analogue, does not -- it passes model=-1 unconditionally.
The unspecified peers then arrive at qemuDomainDefaultSCSIControllerModel()
and pick up whichever model the capability cascade settles on
(typically lsilogic). A user-declared virtio-scsi controller at
idx 0 ends up alongside auto-added lsilogic peers at idx 1+.
Plug the same inheritance into qemuDomainDefaultSCSIControllerModel()
itself so it covers both the disk-driven path and any other caller
that arrives with an unresolved model. The function already prefers
architectural defaults (PSeries, ARM virt, RISC-V virt, LoongArch,
s390, built-in ESP) over capabilities; peer inheritance slots in
just before the capability cascade. A virtio-scsi domain keeps the
new peers as virtio-scsi; an lsisas1068 domain stays lsisas1068; a
fresh domain with no SCSI controllers still gets the cap-driven
default. controller-scsi-auto, the only existing test that flows
through this helper, is unaffected (it has no peers to inherit
from). controller-scsi-inherit-model covers the new behavior.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add virURICheckExtCommand() in a similar fashion to the existing
virURICheckUnixSocket() and use it for (1) the same host migration check
and (2) in remoteConnectOpen().
This allows to migrate VMs using the ext transport, as the external
command can act as a proxy to the remote libvirt.
Signed-off-by: Sergey Dyasli <sergey.dyasli@nutanix.com> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Allow passing arguments to the ext program via the query parameters. The
name of each argument is "argv" and it can be repeated multiple times to
pass several arguments.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Sergey Dyasli <sergey.dyasli@nutanix.com> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The aim of domaincapstest is to check domain capabilities XML
with respect to qemu capabilities. And we used to have old qemu
capabilities where only TPM-1.2 was supported. But as of
v12.4.0-rc1~130 QEMU-7.2 or newer is required which means the
code that's handling older QEMUs is required no more. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
where the optional interfacename can be either the MAC address of the
interface to announce, or the name of the tap device used to connect
the domain's interface to the real network (if the connection is with
a tap device), and [parameters] is one or more of the following options:
Laine Stump [Mon, 18 May 2026 02:42:03 +0000 (22:42 -0400)]
qemu: implement virDomainAnnounceInterface() API
using qemuMonitorAnnounceSelf(). Note that the other public domain
interface APIs expect interface to be specified by either its "target"
name (i.e. the name of the tap/macvtap device on the host) or by the
MAC address, but qemuMonitorAnnounceSelf() expects the QEMU "device
id" (which is known in libvirt as the "alias"), so we have to convert.
Resolves: https://redhat.atlassian.net/browse/RHEL-7047 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Laine Stump [Wed, 6 May 2026 20:46:24 +0000 (16:46 -0400)]
API: Introduce virDomainAnnounceInterface()
This API provides a way for a libvirt client to force a guest to
inject a "Gratuitous ARP" packet into the outgoing stream of one, or
all, network devices of the guest; this will be used to update the
forwarding tables of any network switches in the local broadcast
domain so that they will begin forwarding traffic correctly in a more
timely manner after network topology changes.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Laine Stump [Sun, 3 May 2026 04:54:08 +0000 (00:54 -0400)]
qemu: new monitor function qemuMonitorAnnounceSelf()
This new function sends the command "announce-self" to QEMU, causing
it to inject a series of gratuitous ARP (GARP) response packets into
the output stream of one or all guest interfaces, which will force any
switches in the same collision domain to update their forwarding db
for that interface's MAC address.
There are several parameters that control which interfaces the GARP
packets are sent on, as well as their number and interval, but all of
these parameters have sane defaults (even though QEMU's own
self-announce requires they all be specified in the QMP command).
Here is an example of the fully formed JSON for an announce-self:
All parameters except "interface" are unsigned integers that are
mandatory in the JSON command sent to QEMU. libvirt's
qemuMonitoAnnounceSelf() function, however, makes them optional by
replacing anything set to 0 with the same default value used
internally by QEMU when it is executing announce-self for a guest at
the end of a migration (initial=50, max=550, rounds-5, step=50).
"interfaces" (the only optional parameter from QEMU's point of view)
is (again, from QEMU's PoV) a *list* of the QEMU device-ids for the
interfaces to announce (if it's missing then announce-self injects
announcements on *all* of this guest's interfaces), but it seems much
more likely that someone will either want to announce a single
interface, or all of them, so to simplify calling in the more common
cases, our function just accepts a *single* device name (that can be
NULL) and creates a JSON array containing that one interface name (in
the rare case that someone wants to announce multiple interfaces but
not all of them, they can call our API multiple times).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add xml2argv tests verifying the standalone VNC feature:
- graphics-vnc-standalone: when both <graphics type='dbus'/> and
<graphics type='vnc'/> are present, the -vnc QEMU argument is
omitted since qemu-vnc handles VNC externally via D-Bus.
- graphics-vnc-standalone-socket: same behavior with a Unix socket
listen address.
- graphics-vnc-standalone-p2p: when dbus is p2p mode, standalone
VNC is NOT triggered and the built-in -vnc argument is preserved.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Route the OpenGraphics, OpenGraphicsFD, and GraphicsReload driver
APIs through the standalone qemu-vnc D-Bus interface when active.
Client connections are passed via D-Bus fd-passing (AddClient),
certificate reloading uses the ReloadCertificates method, and
password changes use SetPassword.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu: integrate standalone VNC in domain lifecycle
When both a D-Bus display and a VNC graphics device are configured
and the qemu-vnc binary is available, use the standalone VNC server
instead of QEMU's built-in VNC.
During domain preparation, detect whether the standalone VNC path
applies and allocate the qemuVnc context. Skip the built-in -vnc
command line argument when standalone VNC is active. Start and stop
the qemu-vnc process through the external device hooks.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add helpers to manage the standalone qemu-vnc VNC server process.
The qemu-vnc server connects to QEMU via the D-Bus display interface,
providing VNC access decoupled from the QEMU process.
The helper handles process lifecycle (start/stop), D-Bus name
watching, and provides D-Bus methods for password management,
certificate reloading, and client connections.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jonathon Jongsma [Thu, 26 Mar 2026 19:01:24 +0000 (14:01 -0500)]
hyperv: report nested virtualization setting in domain XML
When Hyper-V is configured to expose virtualization extensions to a
guest, report this in the domain XML by adding the vendor-appropriate
CPU feature flag:
This requires adding ExposeVirtualizationExtensions and several other
fields introduced in Windows 10 to the Msvm_ProcessorSettingData WMI
class definition.
Jonathon Jongsma [Thu, 26 Mar 2026 15:36:37 +0000 (10:36 -0500)]
hyperv: fix error handling of hypervGetProcessorsByName()
We were checking the output pointer for NULL rather than checking the
dereferenced value for NULL. So the case where no processors were
returned would not have returned an error as expected.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
- machine types for the 11.1.0 release added
- (auto) deprecated 8.1 machine type
- 'poll-weight' property added for 'iothread' object
- 'clipboard' property added for 'gtk' display backend
- 'vhost-user-rtc' device added
- new CPU models/versions
- Cascadelake-Server-v6-x86_64-cpu
- Cascadelake-Server-v7-x86_64-cpu
- ClearwaterForest-v4-x86_64-cpu
- DiamondRapids-v2-x86_64-cpu
- EPYC-Genoa-v3-x86_64-cpu
- EPYC-Milan-v4-x86_64-cpu
- EPYC-Turin-v2-x86_64-cpu
- GraniteRapids-v6-x86_64-cpu
- GraniteRapids-v7-x86_64-cpu
- Icelake-Server-v8-x86_64-cpu
- Icelake-Server-v9-x86_64-cpu
- SapphireRapids-v7-x86_64-cpu
- SapphireRapids-v8-x86_64-cpu
- SierraForest-v6-x86_64-cpu
- Skylake-Server-v6-x86_64-cpu
- 'query-kvm' command is now deprecated
- removed 'gluster' blockdev backend
- 'blkdebug' blockdev backend allows injecting delays
- chardev backends support 'encoding' property
- 'remaining' amount reported in 'query-migrate'
- 'target-info-x86_64' QOM type added
- 'x-rdma-chunk-size' migration parameter added
The few changed '.args' files update the machine type to the actual
version because they were frozen before we've added a newer capability
dump (latest machine type is masked to stabilize test outputs).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 2 Jun 2026 12:55:14 +0000 (14:55 +0200)]
qemublocktest: Skip schema validation on 'gluster' backend tests
qemu-11.1 will drop support for the 'gluster' block backend driver. We
want to keep the tests around to validate that nothing in the
parser/generator has changed but there's no point in wiring up QMP
schema validation against older versions.
Skip the schema validation for gluster qemublocktests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Mon, 25 May 2026 12:31:07 +0000 (14:31 +0200)]
qemu_capabilities: Fix domain capabilities on AMD CPUs
The arch-capabilities MSR is not defined on AMD CPUs, but KVM has always
been emulating them. Unfortunately, this may cause Windows to crash so
QEMU (since 10.1, commit d3a24134e37d57abd3e7445842cda2717f49e96d)
decided to mask the MSR by default with some additional compatibility
code for older machine types.
This is all mostly transparent except for probing when we run QEMU
without a machine type and expand the "host" CPU model. With QEMU 10.1
and newer none of the arch-capabilities features will be shown as
enabled, which may cause unexpected issues for users (such as KubeVirt)
that get the list of all supported features from the host-model CPU
definition in domain capabilities to select possible target nodes for
migration. As a result of the change, no AMD host with new QEMU will be
shown as available for incoming migration from older hosts.
Since the features are supported on the host (it's possible to
explicitly enable them), but they should not be enabled by default in
host-model CPU, we only add the to domain capabilities when
VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES flag is set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jiri Denemark [Fri, 29 May 2026 10:52:39 +0000 (12:52 +0200)]
Introduce VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES flag
Some CPU features may be enabled explicitly, but should not
automatically become part of a host-model CPU. Users can now request
such features to be shown in the host-model CPU in domain capabilities
by VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jiri Denemark [Tue, 26 May 2026 13:38:59 +0000 (15:38 +0200)]
Fix documentation of VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES
The flag is designed for expanding the CPU model used by host-model. But
the documentation was sometimes describing it as showing all CPU
features supported on the host, which is wrong as the host may support
features that would not be enabled in host-model.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jiri Denemark [Thu, 21 May 2026 15:55:28 +0000 (17:55 +0200)]
qemu_capabilities: Cache expanded CPU
When probing host model CPU we already expand it to get a list of all
CPU features. Let's store the expanded CPU definition in virQEMUCaps and
copy it to domain capabilities when requested by the
VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES flag instead of
expanding the CPU over and over on each request.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jiri Denemark [Fri, 29 May 2026 12:19:30 +0000 (14:19 +0200)]
qemu_capabilities: Always sort features in host-model CPU
Expanding a CPU model always produces a sorted list of features so the
features in host-model CPU capabilities were either sorted or not
depending on flags passed to virConnectGetDomainCapabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 28 May 2026 10:02:36 +0000 (12:02 +0200)]
ci: regenerate with 'lcitool manifest'
This drops Debian 12 and introduces Debian 13, since Debian 12
reached its EOL on 2026-06-10 [1]. However, Debian 13 dropped
official support for mipsel and mips64el, but introduced riscv64
support. Reflect this changes in supported arches in the manifest
file and regenerate with the latest lcitool.
1: https://www.debian.org/releases/ Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Daniel Hora [Thu, 28 May 2026 13:28:26 +0000 (15:28 +0200)]
examples: Improved shell output of showDomains
Improved formatting of the shell output of the
function showDomains based on length of the longest domain.
Signed-off-by: Daniel Hora <dhora@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virDomainFSInfoFormat() and qemuAgentFSInfoToPublic() function
implementations are not driver dependent and can be shared across
drivers, so move them to a common place to avoid code duplication.
Also, rename virDomainFSInfoFormat() to qemuAgentFSInfoFormat() to follow
the naming scheme in qemu_agent.c.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
bhyve: support getting interface addresses from agent
Extend bhyveDomainInterfaceAddresses() to support
the VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT source.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move all the helpers to the beginning for the file to
be able to use them in every API implementation.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
docs: drvbhyve: reorganize sections about resource limits
Sections about resource limits are currently placed across the file
in between various device examples. To make it easier to follow,
group them into a single section. This also allows to give
an introduction on the rctl(8) framework once instead of repeating
it for every resource type.
Also, document the memory limitation support added in libvirt 12.4.0.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 28 May 2026 12:31:56 +0000 (14:31 +0200)]
qemu_nbdkit: Fix format when printing time_t values
The time_t type can be 32bit or 64bit signed integer. There are
systems where it's defined as long, or long long (32bit systems
usually). Therefore, using just 'l' length modifier is not good
enough. Also, using 'u' conversion specifier is also wrong
(though, values stored in qemuNbdkitCaps struct reflect mtime of
some files, so there won't be a negative value).
Anyway, do what we already do for virQEMUCaps - use '%lld' printf
format and typecast to long long.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Tue, 26 May 2026 13:18:52 +0000 (15:18 +0200)]
tests: Link qemuxml2argvmock with test_utils_lib
When running qemuxmlconftest under valgrind, it fails with a
symbol lookup error:
valgrind: symbol lookup error: libvirt.git/_build/tests/libqemuxml2argvmock.so: undefined symbol: virTestMakeDummyFD
This occurs because qemuxml2argvmock uses the
virTestMakeDummyFD() function (implemented in testutils.c) but
does not explicitly link against test_utils_lib. Fix this by
linking the test utils library to the mock library, statically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
projects / thirdparty / libvirt.git / log
