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>
Michal Privoznik [Thu, 23 Apr 2026 10:43:53 +0000 (12:43 +0200)]
src: Introduce virCgroupFreezerState enum
So far, only vircgroupv1 implements freezer controller related
callbacks and both work with strings ("THAWED", "FROZEN",
"FREEZING"). This works well with v1 but with CGroupsV2 there are
just two states and they are represented by a number.
Therefore, introduce an enum and implement enum <-> string
conversion for each backend separately.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
The first one is that only up to 16 ports per console is supported. This
is different from the default (31), so update the code to manually add
the virtio-serial controllers with 16 ports. For the existing
controllers, make sure to set max ports to 16 or error out if ports
count greater than 16 was specified.
The second one is that bhyve does not clean up UNIX sockets for these
devices. So update virBhyveProcessStop() to remove leftover sockets.
Not adding capabilities probing as the virtio-console device is
available on all supported FreeBSD versions and on all supported arches.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, there are two (at least) issues in virBhyveProcessStop().
Before going into details, a quick overview of the bhyve shutdown
process. It is a two stage process: first, the main bhyve
process gets destroyed (either via an external command or within the
guest), then the resources need to be cleaned up using the bhyvectl(8)
tool.
The first issue is that if virCommandRun() for bhyvectl(8) fails,
virBhyveProcessStop() jumps to the 'cleanup' label and misses cleaning
of some resources.
The second issue is more serious. Currently, monitor is closed only
after running of the bhyvectl(8) command. That means that the monitor
could catch the domain destroy event and try to run
virBhyveProcessStop() on the same domain again, resulting in trying
to release already released resources, such as the monitor itself.
Address by:
* Making virCommandRun() on bhyvectl(8) non-critical. Even if it
fails, we try to clean up all resources. We consider the function
failed (return value 1) though.
* Close monitor before running bhyvectl(8)
Additionally, do not verify that virBhyveProcessBuildDestroyCmd()
returns non-NULL, there could be only allocation errors.
And with 'glib' they result in an abort() so no need
to worry about those.
Reported-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Bruno Martins [Wed, 25 Feb 2026 10:35:37 +0000 (10:35 +0000)]
util: Allow for PCI root buses not numbered "0"
virPCIDeviceReset() and virPCIDeviceIsBehindSwitchLackingACS() both
used a hardcoded check for bus != 0 to determine if a device is
attached directly to a "root bus". This breaks on systems with more
than one root bus, where at least one of the buses is necessarily
not 0! (for example Intel Arrow Lake based systems
where the CPU's root complex is bus 0x00 and the PCH root complex is
bus 0x80).
Update both functions to use virPCIDeviceIsOnRootBus(), which detects
root bus attachment via the canonicalized sysfs device link in
/sys/devices/*, making it work correctly for all root buses, not just
those numbered 0.
Signed-off-by: Bruno Martins <ehanoc@protonmail.com> Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Bruno Martins <ehanoc@protonmail.com> Tested-by: Bruno Martins <ehanoc@protonmail.com>
qemu: fix potential hang in qemuMigrationSrcCancelUnattended during reconnect
When libvirtd reconnects to a running QEMU process that had an
in-progress migration, qemuProcessReconnect first connects the
monitor and only later recovers the migration job. During this window
the async job is VIR_ASYNC_JOB_NONE, so any MIGRATION status events
from QEMU are silently dropped by qemuProcessHandleMigrationStatus.
If the migration was already cancelled or completed by QEMU during
this window, no further events will be emitted. When
qemuMigrationSrcCancelUnattended later restores the async job and
calls qemuMigrationSrcCancel with wait=true, the wait loop calls
qemuDomainObjWait (virCondWait with no timeout) and blocks forever
waiting for an event that will never arrive.
qemuProcessRecoverMigration already queries QEMU for the current
migration state via qemuMigrationAnyRefreshStatus and passes the
result to qemuProcessRecoverMigrationOut as migStatus. Plumb that
value one level further into qemuMigrationSrcCancelUnattended and,
when it indicates the migration has already reached a terminal
state (VIR_DOMAIN_JOB_STATUS_CANCELED), skip restoring the async
job and the qemuMigrationSrcCancel/virDomainObjEndAsyncJob pair
entirely.
Signed-off-by: Denis V. Lunev <den@openvz.org> Suggested-by: Jiri Denemark <jdenemar@redhat.com> CC: Peter Krempa <pkrempa@redhat.com> CC: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Peter Krempa [Fri, 17 Apr 2026 14:50:59 +0000 (16:50 +0200)]
tests: vshtable: Excercise all flag combinations in vshTableRowAppendFlags
The new test case iterates over all combinations and tries the
formatting of the table with strings of 3 distinct lengths (1 char, 8
chars and maximum widht that fits in the column (8+3 characters)).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 17 Apr 2026 12:43:39 +0000 (14:43 +0200)]
vsh-table: Add support for right-align and skipping the embedded whitespace
In certain cases the code might want to skip the forced spacing.
Introduce a concept of flags for each column and new function
'vshTableRowAppendFlags' which will do similar job as
'vshTableRowAppend' but add tuples of flags and the string itself.
This patch implements the following flags:
VSH_TABLE_CELL_SKIP_LEADING - skips the single leading whitespace
VSH_TABLE_CELL_SKIP_TRAILING - skips the trailing 2 whitespaces
VSH_TABLE_CELL_ALIGN_RIGHT - moves the alignment to the right of the
column
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 17 Apr 2026 12:26:42 +0000 (14:26 +0200)]
vshTableGetColumnsWidths: Include spacing in lenght calculation
Modify the array holding lengths of individual columns in the table to
include the spacing. This will be used later when we'll allow to modify
the spacing.
To do this we'll include the 3 extra spaces as lengths as well as fix
the two loops using the value to use it directly.
Since the spacing is not included in the string the code in
'vshTableRowPrint' is modified to explicitly add the spacing instead of
adding a constant to the calculated length.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
FreeBSD 15.x updated posix_fallocate() to return EOPNOTSUPP
instead of EINVAL when the operation is not supported.
Quoting posix_fallocate(2):
Previous versions of posix_fallocate used EINVAL to indicate that the
operation is not supported by the file system, as specified in IEEE Std
1003.1 (“POSIX.1”) Base Specifications, Issue 7. IEEE Std 1003.1
(“POSIX.1”) Base Specifications, Issue 8 switched to requiring EOPNOTSUPP
for this error case. ZFS adopted the latter convention in FreeBSD 15.0,
and the remaining filesystems in base adopted it in FreeBSD 15.1.
Update safezero_posix_fallocate() to handle this return value
along with EINVAL to fix the waterfall down to safezero_slow()
for filesystems that do not support that.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
vmx: Generate correct disk target device ID for superwide SCSI
Commit 32f7db0989e4 added support for superwide SCSI, but did not change
the disk ID calculation which resulted in a possible duplicate. Change
it to calculate based on the (already decided) maximum of SCSI units per
bus and add a (well, modify existing) test case.
Fixes: 32f7db0989e4 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
shivanayak [Sun, 8 Mar 2026 18:28:45 +0000 (23:58 +0530)]
vz: fix memory leak in prlsdkGetNetAddresses()
prlsdkGetNetAddresses allocates addr via g_new0 on each loop iteration.
If PrlStrList_GetItem fails and jumps to cleanup, addr is leaked since
prlsdkParseNetAddress (which previously freed it) is never reached.
Fix by using g_autofree for addr in prlsdkGetNetAddresses so it is freed
at scope end, and remove the VIR_FREE(addr) from prlsdkParseNetAddress
to avoid double-free, as callers should manage their own memory.
Signed-off-by: Shiva Shankar <shivanayak@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bruno Renié [Fri, 13 Mar 2026 11:26:57 +0000 (12:26 +0100)]
docs: Drop mention of aes-256-cbc
This is most likely referring to past qemu-img behavior. Defaults are
not encoded in libvirt. `qemu-img` behavior is runtime-dependent, with a
current preference towards 'aes-256-xts'.
FreeBSD supports resource limiting with the rctl(4) framework.
It supports various resource types, including I/O resources.
It allows to limit resources for users, processes, login classes,
and jails.
To apply blkiotune limits set limits for the bhyve process.
I/O related resources supported by rctl(4) are:
readbps filesystem reads, in bytes per second
writebps filesystem writes, in bytes per second
readiops filesystem reads, in operations per second
writeiops filesystem writes, in operations per second
Thus, the actual commands look like:
rctl -a process:$bhyvepid:writebps:throttle=10000000
rctl -a process:$bhyvepid:readbps:throttle=10000000
rctl -a process:$bhyvepid:writeiops:throttle=20000
rctl -a process:$bhyvepid:readiops:throttle=20000
This is different from the current blkiotune modeling in libvirt as
it requires specific device to apply limits to. To adapt this model
to per-domain I/O limits, update domain schema to specify "*" as a
device name.
The rctl(8) may be not available or not enabled, so add a capability
check for that.
Per process rules get removed when the process disappears, so no special
clean up is necessary.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
MemAvailable was introduced in kernel version 3.10 (and it was even
backported to older kernels in some distributions) and has been
a quite popular method to estimate the available method (totally fully
amount + reclaimable amount).
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jonathon Jongsma [Wed, 11 Feb 2026 22:23:30 +0000 (16:23 -0600)]
hyperv: Add a utility function for getting method output params
When invoking a method in WMI, it can either return synchronously or
asynchronously (with return value 4096). In the latter case, the output
parameters of the method are not present in the method response xml
document. We have to fetch the output parameters via associations with
the Job object that is returned in the method response.
the hypervInvokeMethod() function already partially handles the async
case by polling the job until it fails, completes successfully, or
times out. This patch adds a utility function to fetch a named output
parameter from a given method response xml document. It handles both
synchronous and asynchronous cases.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Tue, 14 Apr 2026 12:55:42 +0000 (14:55 +0200)]
qemu: Add support for 'VIR_DOMAIN_BLOCK_RESIZE_CAPACITY' with qcow2 using the 'data-file' feature
If a qcow2 image uses a 'data-file' on a local block device we can still
honour VIR_DOMAIN_BLOCK_RESIZE_CAPACITY but use the capacity of the
data-file instead.
The code is modified to first pick the virStorageSource which we'll
probe for size based on the config of the VM and uses to determine the
new size.
Resolves: https://redhat.atlassian.net/browse/RHEL-155809 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 26 Mar 2026 17:10:32 +0000 (18:10 +0100)]
API/qemu: Introduce 'VIR_DOMAIN_BLOCK_RESIZE_EXTEND' for 'virDomainBlockResize'
Introduce a new flag VIR_DOMAIN_BLOCK_RESIZE_EXTEND which will prevent
accidental shrinking of the block device.
Warn callers that they ought to use it.
While this won't prevent any old uses without the flag (which we
couldn't change due to our API guarantees) it will give the users tools
to handle the resizing of devices more safely.
Implement it in the qemu driver.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 14 Apr 2026 11:59:01 +0000 (13:59 +0200)]
conf: Reject blockio settings for "<disk device='lun'>"
Overriding the blockio settings for disk passthrough via
"<disk device='lun'>" doesn't make sense and in fact the 'scsi-block'
device in qemu doesn't even expose the appropriate properties:
qemu-system-x86_64: -device {"driver":"scsi-block","bus":"scsi0.0","channel":0,"scsi-id":0,"lun":0,"drive":"libvirt-1-format","id":"scsi0-0-0-0","logical_block_size":512,"physical_block_size":512}: Property 'scsi-block.physical_block_size' not found
Reject those at validation.
Resolves: https://redhat.atlassian.net/browse/RHEL-145937 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The definition of BIT0 in policy element comes from TDX spec, but it makes
confusion for some customers whether 0 or 1 activates debug:
1. We know that "off-TD debug mode" basically means debug from outside the
TD --> 1 activates debug.
2. But when a customer is not aware of the term "off-TD debug" it is very
easy to misinterpret this as "TD debug mode off" --> 1 deactivates debug.
Given that the policy example uses "0x10000001", the second interpretation
even becomes more likely, because a customer may assume that security by
default is applied in the example.
Thus, change the policy in example configuration to "0x10000000" and update
BIT0 definition to be more explicit.
projects / thirdparty / libvirt.git / log
