Michal Privoznik [Wed, 20 May 2026 10:42:34 +0000 (12:42 +0200)]
conf: Assert virDomainChrDeviceState and virConnectDomainEventAgentLifecycleState enums are in sync
When QEMU driver emits agent connected/disconnected events (inside of
processSerialChangedEvent()) it declares a variable of
virDomainChrDeviceState enum, and then passes this variable to
virDomainEventAgentLifecycleNewFromObj(). But we document the agent
lifecycle state to be of virConnectDomainEventAgentLifecycleState enum.
Therefore, make sure values from
virConnectDomainEventAgentLifecycleState enum are of the same value as
those in virDomainChrDeviceState enum.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
virnetdevbandwidth: Only clear qdisc for defined directions
When virNetDevBandwidthSet is called for a macvtap device in
qemu_command and qemu_hotplug, qemuDomainInterfaceSetDefaultQDisc has
been called already, setting the iface qdisc to 'noqueue'. If the
interface has an inbound-only bandwidth limit, the outgoing qdisc
on the device will be reset to the system default.
Peter Krempa [Sat, 16 May 2026 07:52:30 +0000 (09:52 +0200)]
virTypedParamsValidateTemplate: Fix counting of templates
There are 2 bugs in virTypedParamsValidateTemplate's counting of the
passed amount of templates:
- the condition looked for empty strings rather than non-empty ones
- the count was 1 more than the amount of templates due to use of
post-increment directly in the condition
Peter Krempa [Thu, 30 Apr 2026 05:32:30 +0000 (07:32 +0200)]
util: virobject: Add debug refcounting output
virObject internally uses g_object which doesn't expose the internal
reference count. When debug logging we log ref/unref operations but when
reading logs it's hard to follow if a precise reference count is needed
at some points.
Add a private reference counter variable and use it in debug messages of
virObject operations.
The code is designed so that it can be disabled if ever needed since
it's just for debugging. For now let's keep it enabled.
With all the informaton added the logs look like (timestamps trimmed):
Peter Krempa [Thu, 30 Apr 2026 05:56:54 +0000 (07:56 +0200)]
util: object: Add class name to the Ref/Unref/Dispose debug messages
Since the object stores the pointer to the parent class object
internally we can add the name of the class of the object to the debug
messages. Since the debug messages are based on probe points propagate
it into the probe point rather than adding separate debug message.
For virObjectUnref, this also fixes the ordering of the messages to be
'unref->dispose' by invoking the PROBE before unref rather than the
other way around which didn't make sense in the logs and wouldn't allow
accessing the class pointer from the already disposed-of object.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Apr 2026 05:39:00 +0000 (07:39 +0200)]
util: probe: Add 'PROBE_DEBUG'
The standard 'PROBE' macro uses the 'info' priority for the log entry
corresponding to the probe point. While in some cases it makes sense to
log above debug priority in others it does not. Add the possibility to
pick a lower priority level.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 14 May 2026 15:19:55 +0000 (17:19 +0200)]
remote_driver: Don't leak opaque pointer passed to 'virStreamEventAddCallback'
In the implementation of the virStream events in the remote driver, the
freeing of the passed opaque data for the callback was guarded by:
if (!cbdata->cb && cbdata->ff)
(cbdata->ff)(cbdata->opaque);
thus if the 'cb' is passed to 'virStreamEventAddCallback' the private
data would never be freed once 'virStreamEventRemoveCallback' is called.
The issue can be reproduced both in client applications which would
register the stream callback and also in the libvirt daemons, when
modular daemons are used. The virStream remote driver client code is in
such deployments also used to tunnel requests from the hypervisor daemon
(virtqemud) to sub-daemons (virstoraged).
In those cases the leak is amplified as the stream event callback is
internally used to do the tunnelling and the daemon dispatch code stores
a reference to the 'virNetClient' object associated with the connection.
As this causes the last reference on the virNetClient object to be still
active, the corresponding connection to the storage daemon isn't closed
either, leaking a FD both in virtqemud and virtstoraged.
Internally the data is stored in 'struct remoteStreamCallbackData' which
is defined only in 'remote_driver.c' and there's no code which would
update the 'cb' field, thus the leak can't be avoided.
Remove the check for 'cb'. My assumption is that this was supposed to
mimic the 'dispatching' field in 'util/fdstream.c' or similar logic in
other dispatch functions.
The patch also adds debug statements which I've used to trace this.
The leak of a connection in 'virtqemud' has the following backtrace
under valgrind (note that the pointer is considered reachable and thus
this isn't visible in default config):
==3678343== 136 bytes in 1 blocks are still reachable in loss record 2,680 of 2,964
==3678343== at 0x48FC6CD: calloc (vg_replace_malloc.c:1616)
==3678343== by 0x4ED8A91: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8600.5)
==3678343== by 0x5019CA2: g_type_class_get (in /usr/lib64/libgobject-2.0.so.0.8600.5)
==3678343== by 0x5001011: g_object_new_with_properties (in /usr/lib64/libgobject-2.0.so.0.8600.5)
==3678343== by 0x5001EA0: g_object_new (in /usr/lib64/libgobject-2.0.so.0.8600.5)
==3678343== by 0x499E653: virObjectNew (virobject.c:252)
==3678343== by 0x499EA0F: virObjectLockableNew (virobject.c:274)
==3678343== by 0x4A84651: virNetClientStreamNew (virnetclientstream.c:144)
==3678343== by 0x4AE82AE: remoteStorageVolUpload (remote_client_bodies.h:8242)
==3678343== by 0x4BED13D: virStorageVolUpload (libvirt-storage.c:1809)
==3678343== by 0x4043539: remoteDispatchStorageVolUpload (remote_daemon_dispatch_stubs.h:20248)
==3678343== by 0x4043539: remoteDispatchStorageVolUploadHelper (remote_daemon_dispatch_stubs.h:20218)
==3678343== by 0x4A89A2C: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
==3678343== by 0x4A89A2C: virNetServerProgramDispatch (virnetserverprogram.c:299)
Resolves: https://redhat.atlassian.net/browse/RHEL-170773 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Fri, 15 May 2026 12:51:15 +0000 (14:51 +0200)]
virauth: Verify virConnectAuth::cb is set in virAuthGetPasswordPath()
Simirarly to virAuthGetUsernamePath() check whether callback used
to collect credentials is actually set before calling it. This
bug is easily reproducible, for instance as:
The difference is that the usual UUID is supposed to be unique per host
and instanceUuid should be unique across the whole cluster. One could
think of them as HUID and CUID (as the first "U" does apparently mean
something else in the Broadcom world). That _would_ be fine for our
scenario. However, that piece of information turns out to be false as
well and the UUID we were using (`config.uuid`, or in VMX the
`uuid.bios`) can be the same in two machines on the same host.
Fortunately the `FindByUuid()` function can also search for VMs based on
their `instanceUuid`, dictated by the so far omitted third parameter.
Unfortunately that parameter is not parsed (or at least properly) before
vSphere API 4.0 (the documentation says 2.0, but we are not using that
namespace and 4.0 is the lowest we can target), which we are not
specifying in the server returns a 500 HTTP error if we use the
`instanceUuid` parameter.
So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL
requests which makes that `FindByUuid()` function work even with the
`instanceUuid` set, but without any extra labor.
After that this patch also changes all UUIDs to be parsed from the
`config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback
to the old `uuid.bios`) and adjusts tests accordingly.
To give users (and management applications) the possibility to revert
back to the previous (legacy) behaviour a new URI query parameter is
introduced, called `legacy_uuid` which, if set to `1`, still keeps the
code working as it did before this patch.
Last, but not least it changes the parameter to aforementioned function
to be true (unless the legacy behaviour is requested, of course) and
henceforth all searching ought to be done with the more unique ID.
Resolves: https://redhat.atlassian.net/browse/RHEL-174300 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 14 May 2026 14:32:30 +0000 (16:32 +0200)]
virsh: Provide no auth callbacks for bash completer
Our bash completion script parses (partially incomplete) command
line and looks for two arguments: --readonly and --connect
because in the next step it executes virsh with those two
arguments like this:
virsh --readonly --connect $URI complete -- "text to complete"
Now, whenever virsh sees connection URI specified on its cmd line
it connects to it right away (before executing any command). This
happens inside virshConnect(). Here, virConnectOpenAuth() is
called with the default auth callback (virConnectAuthPtrDefault).
In majority of the cases this is desirable, as it might ask user
for credentials (password for example). But in case of bash
completion this is not desired because bash completion script
must not expect users to input anything (that's why we even
close stdin in cmdComplete()).
Therefore, when connecting from virsh that's executed by the bash
completion script provide no auth callbacks to prevent virsh from
asking for credentials.
Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/879 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Tested-by: Richrad W.M. Jones <rjones@redhat.com>
Michal Privoznik [Fri, 15 May 2026 07:53:10 +0000 (09:53 +0200)]
virnetlibsshsession: Check later for auth callback in virNetLibsshAuthenticatePassword()
The first thing that virNetLibsshAuthenticatePassword() does is
read password from config file. For this it does not need auth
callback. If that password fails to authenticate then
corresponding callback from the auth callback is called. This is
actual place where auth callback should be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Tested-by: Richrad W.M. Jones <rjones@redhat.com>
Michal Privoznik [Thu, 14 May 2026 18:22:04 +0000 (20:22 +0200)]
virnetsshsession: Don't check for auth callbacks in virNetSSHAuthenticatePassword()
For the VIR_NET_SSH_AUTH_PASSWORD authentication mechanism the
virNetSSHAuthenticatePassword() is called. Inside it,
virAuthGetPasswordPath() is called to obtain password. Firstly
reading from our auth.conf file is attempted and if that fails
then corresponding callback from virConnectAuthCallbackPtr is
called. But virAuthGetPasswordPath() checks whether the callback
is NULL or not. There is no need for
virNetSSHAuthenticatePassword() to check it too. Drop the
duplicate check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Tested-by: Richrad W.M. Jones <rjones@redhat.com>
To prepare for the qemu agent support for the bhyve driver,
move the implementation from qemu/ to hypervisor. This way
this implementation can be shared across multiple drivers.
The move is mostly mechanical except qemuAgentOpen()
which now accepts the "timeout" argument for the agent timeout.
As the original code used QEMU_DOMAIN_PRIVATE() to access
the agent timeout value, this change allows to make the code
driver-independent.
qemuAgentOpenUnix() is wrapped with #ifndef WIN32 so it does not fail on
mingw.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com> Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Added energy reporting from resctrl PERF_PK_MON through domstats:
cpu.energy.monitor.count=1
cpu.energy.monitor.0.name=vcpus_0
cpu.energy.monitor.0.vcpus=0
cpu.energy.monitor.0.pkg.count=2
cpu.energy.monitor.0.pkg.0.id=0
cpu.energy.monitor.0.pkg.0.core_energy=0.000000
cpu.energy.monitor.0.pkg.0.activity=0.000000
cpu.energy.monitor.0.pkg.1.id=1
cpu.energy.monitor.0.pkg.1.core_energy=2.888203
cpu.energy.monitor.0.pkg.1.activity=1.718601
Changes:
- Added VIR_DOMAIN_STATS_CPU_ENERGY_MONITOR_* macros to libvirt-domain.h
- Added qemuDomainGetStatsEnergy() to qemu_driver.c
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com> Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The new XML element is <energytune> under <cputune> following earlier pattern for
resctrl features (cachetune, memorytune). Energytune doesn't currently support
the "tuning" part, only monitoring. I added it as energytune for consistency with
cache and memory features, keeping all resctrl handling under cputune. This also makes
sense with current resctrl architecture - all monitoring groups are part of an
allocation group.
Changes:
- Added <energytune> parsing to domain_conf.c
- Added schema definition in domaincommon.rng
- Documented the element in formatdomain.rst
- Added energytune test
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com> Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
conf: report energy monitoring in host capabilities
Expose PERF_PKG_MON energy monitoring capabilities in the host
capabilities XML.
<energy>
<monitor maxMonitors='576'>
<feature name='core_energy'/>
<feature name='activity'/>
</monitor>
</energy>
Changes:
- Add virCapabilitiesFormatEnergy() to emit <energy> XML block
- Add virCapabilitiesInitEnergy() to init from PERF_PKG_MON info
- Add <energy> element and energyMonitorFeature to capability.rng
- Update qemu_driver to support VIR_RESCTRL_MONITOR_TYPE_ENERGY
- Add virCapsHostEnergy struct
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com> Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
util: add PERF_PKG_MON energy monitoring support in virresctrl
Linux 7.0 introduced in resctrl PERF_PKG_MON interface that exposes per-package
energy and performance counters. This patch extends virresctrl implementation
to discover and read energy counters from this new resource type.
(core_energy - Joules, activity - Farads)
Changes:
- Add Energy features allow-list virResctrlEnergyFeatures
since PERF_PKG_MON is not prefix-based.
- Added perf_monitor_info to _virResctrlInfo to contain _virResctrlInfo capabilities
- New virResctrlGetPerfMonitorInfo following earlier virResctrlGetMonitorInfo
to check new resource capabilities
- Added VIR_RESCTRL_MONITOR_TYPE_ENERGY and mapped it to energy allow-list
- Added dvals/ndvals pair to _virResctrlMonitorStats to support floating-point
counters and integer counters in single monitor (to support integer perf counters
in the future).
- Added floating-point read + parse in virResctrlMonitorGetStats for energy counters
- Stubbed VIR_RESCTRL_MONITOR_TYPE_ENERGY in qemu_driver
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com> Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Ján Tomko [Tue, 12 May 2026 11:10:43 +0000 (13:10 +0200)]
util: virGetSubIDs: do not limit file size
On systems with many users, this file can be larger than BUFSIZ.
Since the file should only be editable by root and virFileReadAll
reallocates the buffer in increments as needed as opposed to
allocating for 'maxlen' upfront, set the maximum to INT_MAX.
Change from VIR_FREE() to g_free meant there is a possible double free
when there is an error during parsing because the parsing it done
directly into the parsedUri member of the esxPrivate, free'd when it
fails and then the caller calls free on it again. Changing back to
VIR_FREE() means there is no double free and no crash.
Reproducible easily with `virsh -c esx://l?no_verify=2`.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Use newly introduced testutils APIs to detect unused files.
This is pretty much straightforward, except for one small thing:
some test cases depend on QEMU (and are NOP if built without it).
Hence the condition in testCaseEnumerate().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are couple of files under tests/cputestdata/ that are not
used by any test case:
1) ppc64-guest-host-model.xml - unused since its introduction in
v1.2.19-rc1~31
2) ppc64-host+guest-host-model.xml - Same
3) x86_64-bogus-vendor.xml - Introduced in v0.8.7~195 under
slightly different name, then renamed to the current name (in
v3.1.0-rc1~3) but never used actually.
Just drop these three files.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use newly introduced testutils APIs to detect unused files.
This is pretty much straightforward except for one test case:
hostdev. This test case queries sysfs under the hood and thus is
expected to succeed on Linux and fail everywhere else. Though,
hostdev.expect.xml is thus used on Linux only. Therefore, do not
collect it on non-Linux platforms.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuxmlconftest: Switch to virTestEnumerateTestCases()
The qemuxmlconftest detects unused files in qemuxmlconfdata/
directory. But it uses its own implementation for that. But now
that there's a generic implementation available, switch to that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is basically a generalized version of what we have in
qemuxmlconftest (functions testConfXMLEnumerate(),
testQemuConfMarkUsed() and testConfXMLCheck()). The idea is to
reuse the code in other tests.
There's one slight difference to the original - while
qemuxmlconftest always allocated the hash table, in this
generalized version NULL table is okay.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 23 Apr 2026 11:13:52 +0000 (13:13 +0200)]
util: hostmem: Make parameters for 'virHostMemSetParameters' introspectable
Refactor the validation using 'virTypedParamsValidateTemplate' and
export the template so that 'qemuNodeSetMemoryParameters' can expose
them via introspection.
In addition since 'virHostMemSetParameters' is conditionally compiled,
platforms which don't support it will not expose given params.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
While 'virTypedParamsValidate', which uses varargs to pass the template
to validate parameters against, is convenient for single uses we have
multiple occasions where we want to validate the same list of parameters
in muliple places. We use either a macro which expands to the parameter
list in place or a function which encapsulates the validation.
For introspection of input typed parameters we'll need to have the list
of supported typed parameters in each function which uses them as input
and either of the approaches is inconvenient for generating the
introspection parts.
Refactor 'virTypedParamsValidate', to split the actual validation
internals into ''virTypedParamsValidateInternal' and create two
wrappers:
- 'virTypedParamsValidate' which uses varargs
- 'virTypedParamsValidateTemplate' which uses an array of structs
containing the template.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 14:46:46 +0000 (16:46 +0200)]
qemuDomainGetMetadata: Add top-level flag validation
The implementation uses 'virDomainObjGetMetadata'
internally. To have a top level flag validation for the upcoming flag
introspection export the supported flags as a macro and add a
'virCheckFlags'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 14:46:46 +0000 (16:46 +0200)]
qemuConnectDomainQemuMonitorEventRegister: Add top-level flag validation
The implementation uses 'virDomainQemuMonitorEventStateRegisterID'
internally. To have a top level flag validation for the upcoming flag
introspection export the supported flags as a macro and add a
'virCheckFlags'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 14:46:46 +0000 (16:46 +0200)]
qemuDomainQemuMonitorCommand: Add top-level flag validation
The implementation uses 'qemuDomainQemuMonitorCommandWithFiles'
internally. To have a top level flag validation for the upcoming flag
introspection export the supported flags as a macro and add a
'virCheckFlags'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 14:46:46 +0000 (16:46 +0200)]
qemuDomainManagedSaveDefineXML: Add top-level flag validation
The implementation for managed save uses 'qemuDomainSaveImageDefineXML'
internally which validates the flags. To have a top level flag
validation for the upcoming flag introspection export the supported
flags as a macro and add a 'virCheckFlags' to
'qemuDomainManagedSaveDefineXML'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 14:19:21 +0000 (16:19 +0200)]
qemuDomainRestore(Flags|Params): Refactor flag checking
Create QEMU_DOMAIN_RESTORE_FLAGS define which collects all the flags
used by either of the implementations of the 'Restore' API and move the
flag checking into the implementation function so that it's available
later for introspection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 14:44:25 +0000 (16:44 +0200)]
virHostCPUGet(Map|Stats): Remove unused 'flags'
The utility functions which get CPU map and stats don't actually use the
flags. Remove the argument and move the 'virCheckFlags' to driver
implementation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 22 Apr 2026 12:48:46 +0000 (14:48 +0200)]
util: typedparam: Refactor and fix typed param validation
'virTypedParamsValidate' has special logic to handle the internal
VIR_TYPED_PARAM_UNSIGNED type, but unfortunately the implementation of
the error which is reported is flawed as it only updated the
'expecttype' string when the type actually matched. In cases when it
didn't we'd report the following error:
error: invalid argument: invalid type 'string' for parameter 'poll_shrink', expected '(null)'
To fix it we can re-implement the validation part by using
virTypedParamValidateType simply by adding the VIR_TYPED_PARAM_UNSIGNED
to 'virTypedParameterTypeToString' handling which is now private and
adding logic to allow either one of the unsigned types, which allows us
to use the same function in both cases, simplifying the code.
Fixes: 07652410a7af98ca03281c4bfe20415ced26a44a Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 22 Apr 2026 12:36:22 +0000 (14:36 +0200)]
util: Replace open-coded internals of VIR_TYPED_PARAMS_DEBUG with 'virTypedParamDebugstr'
Replace the internals of the macro by a function so that
'virTypedParameterToString' doesn't need to be exported as it also
adds mappings for values which don't exist in the public API.
This change also prevents a NULL to be passed to string formatters in
case when the caller sends an unknown typed parameter type as we now
also make sure that the type is in range.
Fixes: 54dd75fd97339dd49a54554e9327e5680c72132b Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 22 Apr 2026 09:58:07 +0000 (11:58 +0200)]
util: virTypedParamValidateType: Don't report unknown typed parameter type as '(null)'
If the actual type of the typed parameter is an invalid number the type
checker would still attempt to convert it to a string resulting in an
attempt to print a NULL string. libc saves us from the crash but the
error message is still wrong. Fix it.
Fixes: 54dd75fd97339dd49a54554e9327e5680c72132b Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 22 Apr 2026 09:54:35 +0000 (11:54 +0200)]
util: typedparam: Convert VIR_TYPED_PARAM_CHECK_TYPE into a function
Create 'virTypedParamValidateType' which will use the same logic
encapsulated in a function. Use the error message wording from
'virTypedParamsValidate' as it contains less fluff.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 2 Apr 2026 13:22:41 +0000 (15:22 +0200)]
qemu: driver: Unify coding style
Reformat qemu_driver.c to use the contemporary coding style. It will
help also for the upcoming script for generating list of supported flags
for APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Denis V. Lunev [Mon, 11 May 2026 21:55:24 +0000 (23:55 +0200)]
virStorageSource: note that capacity/allocation/physical are stale caches
These three fields are cached values that do not reflect reality unless
the caller refreshes them. 'allocation' is in addition ultra-unreliable:
any guest write into a previously unallocated part of a sparse image
invalidates it, even right after a refresh.
Document this on the struct so new callers do not trust the values.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
API/qemu: add async unplug flag to virDomainSetVcpu
Add VIR_DOMAIN_SETVCPU_ASYNC_UNPLUG for virDomainSetVcpu().
Define a dedicated virDomainSetVcpuBehaviour flag type and wire the
new flag through the QEMU driver. As with setvcpus async unplug,
success indicates request acceptance while final completion is
reported by the vcpu-removed event.
Update the API documentation and add virsh support for the async path to
the setvcpu subcommand.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
API/qemu: add async unplug flag to virDomainSetVcpusFlags
Add VIR_DOMAIN_VCPU_ASYNC_UNPLUG for virDomainSetVcpusFlags().
With this flag, success indicates that QEMU accepted the unplug
request, while final completion is reported by the vcpu-removed
event. Rejected requests continue to be reported by the
device-removal-failed event.
Wire the flag through the QEMU driver, document its semantics, and
add virsh support for the async path in the setvcpus subcommand.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemu: thread async vcpu unplug through internal helpers
Thread an async_unplug flag through the internal QEMU vCPU unplug
helpers.
When set, the unplug path returns after QEMU accepts the device
deletion request and leaves final completion to the existing
DEVICE_DELETED handling routines.
All callers still pass false, so this does not change behaviour yet.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemu: emit vcpu-removed event on unplug completion
Emit the vcpu-removed event when QEMU vCPU unplug completes.
Hook this into qemuDomainRemoveVcpu(), which covers both the
synchronous completion path and the DEVICE_DELETED-driven alias
removal path.
Some architectures may have multiple vcpus grouped under a single qemu
vcpu object; on those platforms a `vcpu-removed` event will be emitted
for each vcpu that is removed from this group.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add a new domain event for completed vCPU removal.
Wire the event through the internal event framework and extend the
remote protocol so remote clients can receive it. Update virsh and
the event-test example accordingly.
The event is not emitted anywhere yet.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Thu, 7 May 2026 10:37:17 +0000 (12:37 +0200)]
test: qemu: Fix error message when populating fd groups
The 'new->fds' array is not yet initialized at the point where the check
if the FD is occupied happens so the error would always report that FD
'0' is in use. Use 'new->testfds' instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 11 May 2026 12:40:24 +0000 (14:40 +0200)]
Don't break up strings for VIR_WARN messages
The 'warn' level messages are logged in the default settings so may end
up in something which the user looks for. Random line breaks prevent
grepping for the message.
Similarly to 'error' level messages remove the arbitrary line breaks in
the source to make the messages greppable in the source.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
The sgx-epc test case is currently pinned to capabilities of that
QEMU-7.0. Well, soon the minimal version of QEMU is going to be
bumped. But thanks to previous commit the capabilities of 11.0.0
version support SGX too. Switch the test case to the newer
capabilities.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemucapabilitiesdata: Add SGX support to caps_11.0.0_x86_64
Detecting SGX support is done in two ways and both have to
succeed in order for caps to have the capability:
1) the sgx-epc device needs to be present,
2) the query-sgx-capabilities command needs to return data
instead of an error.
So far, the only caps file that meets both requirements is
caps_7.0.0_x86_64. Soon the minimal version is going to be bumped
to QEMU-7.2. But caps_11.0.0_x86_64 has the device and the only
thing missing is the proper reply to the monitor command.
Therefore, create new qemu_11.0.0_x86_64+sgx capabilities with
reply to query-sgx-capabilities command copied from caps_7.0.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemuxmlconftest: Drop ppc64-default-cpu-kvm-pseries-2.7 test cases
Both ppc64-default-cpu-kvm-pseries-2.7 and
ppc64-default-cpu-tcg-pseries-2.7 test cases rely on pseries-2.7
machine type. It was removed in QEMU-7.2. Soon the minimal
version is going to be bumped to QEMU-7.2 rendering those tests
obsolete. Drop them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemuxmlconftest: Add new cpu host model expansions tests
In qemuxmlconftest there's a section which aim on testing
'host-model' cpu mode expansion. Since this depends on what QEMU
reports (and thus can change with its version) we have a test
case for each QEMU version supported. Unfortunately, when adding
capabilities for new QEMUs this section was forgotten. Add
missing test cases (10.2.0 and 11.0.0).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Tue, 28 Apr 2026 06:47:20 +0000 (08:47 +0200)]
virNetDevOpenvswitchInterfaceStats: Add 'ifname' to error messages
Report the interface name which caused the error.
Resolves: https://redhat.atlassian.net/browse/RHEL-170993 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Peter Krempa [Wed, 29 Apr 2026 10:15:34 +0000 (12:15 +0200)]
vsh: Suppress attempts to write to stderr when it was closed in 'cmdComplete'
The completer closes stderr to suppress anything polluting the shell
when completion would cause any errors.
Since 'virshReconnect' would call 'vshError' on connection failure this
causes vshError to be killed by SIGPIPE and not provide any completions
if the connection is not possible.
To avoid this add a flag called 'stderr_closed' to vshControl and use it
to suppress output in 'vshPrintStderr'. Keep only the log.
Prior to this patch, attempt to run completion on a host with all
daemons shut down would result in:
Peter Krempa [Wed, 29 Apr 2026 09:27:17 +0000 (11:27 +0200)]
qemuDomainGetStatsCpuProc: Don't fetch stats for inactive VMs
CPU stats for inactive VM make no sense. In this case it's especially
misleading because 'vm->pid' of an inactive VM is '0' so
virProcessGetStat returns stats for virtqemud itself.
Fixes: 044b8744d65f8571038f85685b3c4b241162977b Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Install the secrets unit only when the init script is systemd.
Fixes: 2db552dc6ac17596720071fa91181055db7b82ee Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Some VMware guests specify NVRAM storage using the 'nvram' parameter.
If found, parse it and store it in the domain's os.loader.nvram field,
which gets formatted as:
The NVRAM path uses the same transformation functions as disk paths
(ctx->parseFileName and ctx->formatFileName) to ensure consistent
handling of datastore-qualified paths.
The NVRAM is stored as a virStorageSource with type VIR_STORAGE_TYPE_FILE
to ensure compatibility with libvirt's existing firmware handling
infrastructure.
Signed-off-by: Surya Gupta <surygupt@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Parses vtpm.present from VMX files and converts to libvirt TPM
device with CRB model and emulator backend. VMware vTPM uses
TPM 2.0 as specified in the document below
Michal Privoznik [Thu, 23 Apr 2026 13:49:43 +0000 (15:49 +0200)]
virt-host-validate: Suggest different resolution for 'devices' and non-root user
Here's the deal: the 'devices' controller as such does not exist
in CGroupsV2. The alternative is to load eBPF program that mimics
the controller's behavior from CGroupsV1. But, only privileged
user can load such program. This means that virt-host-validate
(when ran as a regular user) claims 'devices' controller missing
(rightfully so), and suggests enabling it in Kconfig. This last
bit might be misleading to users [1].
Now, to fix this ideally, all three conditions should be checked
(CGroupsV2, 'devices' controller and regular user), but our
virCgroup module deliberately hides the version of CGroups. So
check for the other two conditions.
1: https://lists.libvirt.org/archives/list/users@lists.libvirt.org/thread/USDFFRJK74GYHRGMXOE2FSAA4PQD23RE/ Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
Michal Privoznik [Thu, 23 Apr 2026 10:05:59 +0000 (12:05 +0200)]
vircgroupv2: Implement freezer controller
With CGroupsV2 the freezer controller is split into two files:
1) cgroup.freeze where an integer is written to thaw(0)/freeze(1)
processes within the cgroup, and
2) cgroup.events where the frozen status can be read.
Now, freezing/thawing a cgroup is as simple as writing
corresponding integer into cgroup.freeze. But similarly to
CGroupsV1, it may take some time to actually freeze all processes
inside the cgroup. So read both file and map combination of their
values according to this table:
Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/870 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
Michal Privoznik [Thu, 23 Apr 2026 10:05:44 +0000 (12:05 +0200)]
vircgroupv2: Freezer controller is implicit
The freezer controller in CGroupsV2 is always present (under
cgroup.freeze file). Make our vircgroupv2 backend aware of it.
NB, because of the way our backends are ordered (v2 is prefered)
the v1 freezer is never going to be used when CGroupsV2 are
detected. Hence the change to tests.
NB2, this also fixes output of virt-host-validate which complains
that the 'freezer' controller is not present for LXC driver.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
projects / thirdparty / libvirt.git / log
