Peter Krempa [Thu, 11 Sep 2025 15:07:11 +0000 (17:07 +0200)]
qemu_monitor: Extract 'timed_stats' of block devices
The 'timed_stats' block is a set of statistics gathered in configurable
time intervals. The stats include latency timings of reads/writes as
well as the depth of the request queues.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 3 Nov 2025 12:23:48 +0000 (13:23 +0100)]
qemu: capabilities: Fix logic for formatting 'reconnect' parameter
In commit e4d058866e9 I've converted the code to use the modern
'reconnect-ms' parameter instead of 'reconnect' but messed up the logic
for the time when 'reconnect' will be removed.
We need to check QEMU_CAPS_NETDEV_STREAM_RECONNECT_MILISECONDS
individually and not based on QEMU_CAPS_NETDEV_STREAM_RECONNECT.
Fix the logic as upstream qemu now removed 'reconnect'.
Fixes: e4d058866e9563756349de6b3f451a53e64ca872 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 12:17:56 +0000 (14:17 +0200)]
qemu: Ignore "ht" CPU feature
The feature does not do anything, QEMU will always set it according to
the CPU topology completely ignoring what we asked for. Unfortunately,
the way the state of "ht" is reported changed in QEMU 10.0.0 (commit c6bd2dd634208).
QEMU older than 10.0.0 would just report whatever was specified on the
command line totally ignoring the actual state of the feature visible to
a guest. But after the change QEMU reports ht=on in case it enabled "ht"
based on the CPU topology. In all other cases QEMU still reports the
state requested on the command line.
As a result of this change a domain with multiple CPU threads started on
QEMU < 10.0.0 could not be migrated to QEMU >= 10.0.0 unless "ht" was
explicitly enabled in the domain XML because libvirt would see "ht"
enabled on the destination, but disabled on the source (the guest would
see "ht" enabled in both cases anyway). Outgoing migration of domains
started on QEMU >= 10.0.0 is not affected.
To fix this issue we can completely ignore "ht" both in the domain XML
and in the CPU properties reported by QEMU. With this fix incoming
migration to QEMU >= 10.0.0 works again.
Jiri Denemark [Fri, 24 Oct 2025 15:16:32 +0000 (17:16 +0200)]
qemu_monitor: Filter CPU features reported by QEMU
Some features may be on our ignore list because they do nothing even
though QEMU still supports them and reports their state. But as the
features do nothing, the state reported by QEMU may not correspond to
what the guest sees. To avoid possible confusion we may just pretend
QEMU did not report any of the features on our ignore list.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 13:36:18 +0000 (15:36 +0200)]
qemu_process: Always fix CPUs on reconnect
We fix CPUs (i.e., remove ignored CPU features) only when libvirt/QEMU
combo used to start the domain is very old and doesn't support
query-cpu-model-expansion, in which case the CPU definition may contain
features that are unknown to QEMU. But even if both libvirt and QEMU are
new enough, we still want to remove features that do nothing to minimize
confusion or to avoid false migration issues.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 13:27:03 +0000 (15:27 +0200)]
qemu_domain: Fix qemuDomainFixupCPUs
The function was apparently created when the list of ignored CPU
features contained just cmt and related features. The list grew quite a
bit since then and this function stopped making sense as it would remove
all ignored features from CPU definitions but only if cmt was present.
The issue with cmt is long gone and this function was not really doing
anything. Surprisingly this didn't cause any real issues as we don't
update CPU definitions with features unknown to QEMU. But we may still
want to remove ignored features even though QEMU knows about them for
compatibility reasons.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 13:07:45 +0000 (15:07 +0200)]
cpu_conf: Make virCPUDefFilterFeatures return void
The only thing that can fail inside virCPUDefFilterFeatures is
VIR_DELETE_ELEMENT_INPLACE macro. The macro just calls
virDeleteElementsN, which reports a warning when all elements to be
removed are not within the array bounds and returns -1. The function
succeeds otherwise. But since VIR_DELETE_ELEMENT_INPLACE sets the number
of elements to be removed to 1 and we call it with i < cpu->nfeatures,
the safety check in virDeleteElementsN will never fail. And even if we
theoretically called it with wrong arguments, it just wouldn't do
anything.
Thus we can safely assume VIR_DELETE_ELEMENT_INPLACE always succeeds in
virCPUDefFilterFeatures and avoid reporting any errors to simplify
callers.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 23 Oct 2025 13:33:04 +0000 (15:33 +0200)]
ch: Load ch.conf from SYSCONFDIR
Config files for system instances of our drivers (e.g.
"ch:///system", "qemu:///system", etc.) live under /etc/libvirt.
But for some reason, the CH driver was trying to load the config
file from /var/lib/libvirt/ch/ even though the file is installed
under /etc/libvirt per the following line from src/meson.build:
Michal Privoznik [Fri, 31 Oct 2025 09:43:27 +0000 (10:43 +0100)]
drvch: Demote example section to a subsection
In our drvch.rst there's a section with example XML. Demote it to
a subsection ('-') since the whole document starts with section
('=') and this paragraph is really just a child of the root.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Fri, 31 Oct 2025 09:39:05 +0000 (10:39 +0100)]
docs: Document supported URIs for CH driver
Our docs suggest that only session mode is supported for CH
drvier. Well, that's clearly not case. Document the system URI
and refer to other (remote) supported transport modes (yeah, that
works too).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Wed, 29 Oct 2025 11:43:39 +0000 (12:43 +0100)]
domain_conf: Avoid memory leak in virDomainMemoryDefFree()
In my one of my recent commits I've introduced new member to
virDomainMemoryDef struct. While allocated in
virDomainMemoryDefParseXML() its counterpart for freeing is
missing in virDomainMemoryDefFree(). Add it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 13:28:08 +0000 (14:28 +0100)]
qemu_command: Generate virtio options for memory device
Thanks to previous refactors (namely v11.1.0-rc1~142) this is
trivial. There's all the infrastructure needed to generate virtio
options onto cmd line, all that's left to do is set a pointer to
appropriate struct member.
Resolves: https://issues.redhat.com/browse/RHEL-7493 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 10:38:57 +0000 (11:38 +0100)]
conf: Introduce virtio options for virtio memory models
Both virtio-mem and virtio-pmem memory models are virtio devices
and as such support setting various virtio knobs (iommu, ats,
packed, page_per_vq) common to other virtio devices.
Introduce <driver/> element as a child to <memory/> element, just
like we do for other virtio devices, where aforementioned knobs
live.
NB, this is without docs changes, since we do not document which
virtio devices support these knobs and each one is already
documented.
Also, the virtio-options.xml test needed some additional
adjustment (apart from adding virtio-mem device) to enable memory
hotplug.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 14:05:47 +0000 (15:05 +0100)]
qemu: Use virDomainMemoryIsVirtioModel()
Instead of having these big switch()-es that enumerate all memory
models (but act only on virtio models), let's use
virDomainMemoryIsVirtioModel() helper instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 10:55:46 +0000 (11:55 +0100)]
domain_conf: Make virDomainMemoryDefFormat() return void
The only thing that's possibly making virDomainMemoryDefFormat()
fail is call to virDomainMemorySourceDefFormat() but that always
returns zero. Make both functions return void so callers are not
confused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
bhyve: do not allow more than one NVMe device per controller
As bhyve does not have explicit notion of controllers, and for NVMe
devices it allows to specify one a single source for for a given PCI
address, it effectively means that there could be only one device per
controller.
Update validation code to check this case.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 28 Oct 2025 16:13:17 +0000 (17:13 +0100)]
qemuDomainBlocksStatsGather: Fix blockstats gathering after refactor
Commit 58aa005f3e95114 which refactored how block stats are stored
intended to change the code path where stats for all devices are totaled
together by allocating new stats object and using that but the commit
forgot to actually change the pointers inside the loop.
Unfortunately this was not caught by the compiler as there were
pre-existing pointers of the same type with the same name, which
resulted into a NULL dereference.
Stefan Kober [Mon, 6 Oct 2025 15:18:11 +0000 (17:18 +0200)]
NEWS: ch: announce network hotplug feature
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 6 Oct 2025 15:18:10 +0000 (17:18 +0200)]
ch: implement network device hot detach
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 6 Oct 2025 15:18:09 +0000 (17:18 +0200)]
ch: implement network device hot attach
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 6 Oct 2025 15:18:08 +0000 (17:18 +0200)]
ch: add net device alias assignment
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Hector Cao [Tue, 14 Oct 2025 15:28:34 +0000 (17:28 +0200)]
apparmor: Allow AMD-SEV device access for AMD-SEV VM
AMD-SEV virtual machines interact with the underlying
AMD-SEV technology through the character device /dev/sev.
Currently, the AppArmor profile does not include the rule
required to allow this access.
There are two main approaches to address this limitation:
1) Add the required rule to the libvirt-qemu abstraction.
2) Dynamically add the rule only when the VM is an AMD-SEV
guest.
Since AMD-SEV guests represent a niche use case, it is more
appropriate to apply the rule dynamically rather than granting
access to all VMs through a global abstraction change.
This commit implements option (2) by modifying the virt-aa-helper
binary to insert the necessary rule into the AppArmor dynamic
profile when the VM is identified as an AMD-SEV guest.
The added entry in the generated libvirt-<uuid>.files file
will look like:
...
"/dev/sev" rw,
...
Signed-off-by: Hector Cao <hector.cao@canonical.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A domain that runs with TCG emulation does not need kvm device, so drop
it from default device ACL.
Dynamically grant access to /dev/kvm based on domain type.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update default to 0xFFFFFFFF ("never notify" in qemu) and make retries
attribute optional.
Signed-off-by: Friedrich Oslage <friedrich@oslage.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 21 Oct 2025 16:22:15 +0000 (18:22 +0200)]
qemumonitorjsontes: Properly free blockstats
In the patch converting block stats to objects in 58aa005f3e9 I forgot
to change the allocation of the hash table in qemumonitorjsontest which
doesn't use the wrapper. This problem didn't manifest itself with newer
glib versions.
Use 'g_object_unref' instead of 'g_free'.
Fixes: 58aa005f3e9 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Wed, 1 Oct 2025 14:26:01 +0000 (16:26 +0200)]
qemuMonitorJSONGetAllBlockStatsInfo: Directly probe data from 'query-named-block-nodes'
Currently the data which was probed for statistics from
'query-named-block-nodes' was updated in a separate call in
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev.
This patch moves and adapts the code so that everything is probed in
qemuMonitorJSONGetAllBlockStatsInfo.
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev is now an empty function
and will be removed later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 1 Oct 2025 14:16:58 +0000 (16:16 +0200)]
qemuMonitorJSONBlockStatsUpdateCapacityData: Merge into caller
It's called just from
qemuMonitorJSONBlockStatsUpdateCapacityBlockdevWorker. Merging it in
makes the code much simpler especially when combined with a change to
APIs that can't fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 1 Oct 2025 12:36:12 +0000 (14:36 +0200)]
qemuMigrationCookieAddNBD: Use qemuBlockGetNamedNodeData to fetch the capacities
'qemuMonitorBlockStatsUpdateCapacityBlockdev' uses the same command
internally.
Upcoming patches will want to merge qemuMonitorBlockStatsUpdateCapacityBlockdev
into qemuMonitorGetAllBlockStatsInfo and qemuMigrationCookieAddNBD is
the only place that doesn't call qemuMonitorGetAllBlockStatsInfo.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 15 Oct 2025 13:24:15 +0000 (15:24 +0200)]
qemuxmlconftest: Add example for "sgio='filtered'" disk option
The test suite validates only the error with the "sgio='unfiltered'"
setting which isn't supported by the qemu driver. Validate also the
'filtered' used explicitly (the default behaviour if unspecified is the
same as 'filtered').
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 13 Oct 2025 13:27:16 +0000 (15:27 +0200)]
docs: snapshot: Add a note that blockjobs ought to be avoided with 'manual' snapshots
Using a blockjob will reactivate the block nodes in qemu and thus e.g.
qcow2 metadata such as bitmaps may become marked as dirty. Users of
'manual' snapshots ought to avoid those.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 9 Jun 2025 13:50:42 +0000 (15:50 +0200)]
qemu: snapshot: Allow snapshot consisting only of 'manual'-y handled disks
The 'manual' snapshot mode is meant for disks where the users wants to
take a snapshot via means outside of libvirt, e.g. on a SAN network.
Allow creating a snapshot which consists entirely of 'manual' disks. For
now this effectively means that the VM will be paused but in the future
more logic can be added to ensure consistency.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 6 Jun 2025 10:33:04 +0000 (12:33 +0200)]
qemu: snapshot: Deactivate block nodes on manually snapshotted disks
If the user wants to manually preserve state of the disk we need, apart
from pausing the machine to quiesce all writes, also deactivate the
block nodes of the device. This ensures that qemu writes out metadata
(e.g. block dirty bitmaps) which are normally stored only in memory,
thus allowing a consistent snapshot including the metadata.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 25 Jul 2025 14:13:39 +0000 (16:13 +0200)]
qemu: migration: Don't reactivate block nodes after migration failure any more
The other code paths which do want to issue block jobs can reactivate
the nodes when necessary so we don't need to do that unconditionally
after failed/cancelled migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 24 Jul 2025 12:49:55 +0000 (14:49 +0200)]
qemu: monitor: Track inactive state of block nodes in 'qemuBlockNamedNodeData'
New qemus report if given block node is active. We'll be using this data
to decide if we need to reactivate them prior to blockjobs. Extract the
data as 'inactive' as it's simpler to track and we care only about
inactive nodes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 15 Oct 2025 08:49:20 +0000 (10:49 +0200)]
qemu: Drop reconnectBlockjobs from _qemuDomainObjPrivate struct
The 'reconnectBlockjobs' member of the _qemuDomainObjPrivate
struct is basically unused after v8.7.0-rc1~110. It's not even
formatted into the status XML, just parsed. This makes needless
noise. Just drop the member.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Mon, 29 Sep 2025 12:54:23 +0000 (14:54 +0200)]
qemu_process: Populate hyperv features for host-model
Pretty straightforward. The only "weird" thing here is that
'hv-time' enlightenment is exposed as a <timer/> under <clock/>
element. Since it's required by 'hv-stimer' and
'hv-stimer-direct' it needs to be enabled too.
Resolves: https://issues.redhat.com/browse/RHEL-114003 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 29 Sep 2025 08:20:41 +0000 (10:20 +0200)]
conf: Introduce hyperv host-model mode
So far we have two modes for hyperv features:
1) custom, where users have to enable features explicitly, and
2) passthrough, where hypervisor enables features automagically.
Problem with 'custom' mode is that some features are not plain
on/off switches but expect int/string value. Until very recently,
these were not reported in domcaps. And even if they were it's a
bit cumbersome.
Problem with 'passthrough' mode is that users don't get to see
the expanded list of enlightenments enabled.
Therefore, mimic what we're already doing with CPUs: have
'host-model' which gets expanded at domain startup and is fixed
throughout domain's run.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_capabilities: Format and parse new hyperv domcaps members
After previous commit the virDomainCapsFeatureHyperv struct
gained new members. Since virQEMUCaps struct holds a pointer to
such struct we must format and parse it to/from capabilities XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 30 Sep 2025 13:05:10 +0000 (15:05 +0200)]
conf: Report default hyperv values in domain capabilities
So far the set of available Hyper-V enlightenments are reported
in domain capabilities. Well, some enlightenments are more than
just simple on/off switch. For instance, the 'spinlocks'
enlightenment expects a number, or 'vendor_id' expects a string.
All of these have some default values (at least in QEMU) and are
used when the passthrough mode is set.
Allow querying these defaults in domain capabilities XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
docs: Drop remark on now unsupported version of QEMU
In formatdomaincaps.rst under section documenting hyperv features
there's a paragraph describing behaviour with QEMU older than
6.1.0. Well, as of v11.2.0-rc1~216 the minimum required version
is 6.2.0 rendering the paragraph needless. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 30 Sep 2025 08:27:27 +0000 (10:27 +0200)]
conf: More hyperv related members into a single struct
So far, we have an array of integers (hyperv_features), an uint
(hyperv_spinlocks), a string (hyperv_vendor_id) and some tristate
switches scattered across virDomainDef. Soon, new knobs will be
introduced and keeping the current state would only worsen
readability.
Introduce virDomainHypervFeatures struct to place hyperv related
features there.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 30 Sep 2025 08:47:21 +0000 (10:47 +0200)]
libxl: Simplify setting HyperV features
Inside of libxlMakeDomBuildInfo() there's a huge switch() for
each virDomainHyperv case. Instead of checking whether feature is
enabled in each 'case', let's just check it at the beginning of
each loop.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
