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.
qemu: fix success return from qemuDomainGetHostnameLease
The current qemuDomainGetHostnameLease() implementation
jumps to the "endjob" label when it finds hostname.
As the label is defined after "ret = 0",
qemuDomainGetHostnameLease() returns -1 in this case.
That works because in qemuDomainGetHostname() it is used like that:
...
if (qemuDomainGetHostnameLease(vm, &hostname) < 0)
goto cleanup;
So it works, but it looks confusing. To make more consistent,
use 'break' in qemuDomainGetHostnameLease() when the hostname
is found, so it returns 0 in this case.
Fixes: a4a5827c9fc396f2b1848c1d393385535b106d1a Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
bhyve: implement domainInterfaceAddresses and domainGetHostname
Implement the domainInterfaceAddresses and domainGetHostname APIs.
These APIs could use multiple sources of information, though
for bhyve only the 'lease' source is supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Wthout this change, the tapfd path would only be appended to a domain's
profile when the device is hotplugged (either during domain start or
normal operation). Operations which regenerate the profile (blockcommit,
etc) will cause this path to be dropped from the profile.
Since the domain status XML now includes the path to the tap device,
include it in the profile.
VIR_DOMAIN_DEF_FORMAT_STATUS is used to include disk & network
privateData elements in the domain XML, which contain misc information
that should be available to the virt-aa-helper when generating rules.
For now, this will be used in a subsequent patch to pass tap paths to
the virt-aa-helper.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Introduce a read-only `tapfd` element for direct interfaces (macvtap),
which contains the path to the backing tapfd for that interface
(e.g. `/dev/tapXX`).
The element is only included when the domain is being formatted for
internal consumption (VIR_DOMAIN_DEF_FORMAT_STATUS) and is not accepted
in user-provided XML (!VIR_DOMAIN_DEF_PARSE_INACTIVE).
This will be used by the AppArmor security driver when re-generating
profiles.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Pavel Hrdina [Wed, 8 Apr 2026 13:35:29 +0000 (15:35 +0200)]
virNetworkIPDefFormat: Fix memory leaks
Use g_auto() for every virBuffer in this function to make sure none of
them will leak memory. It is not necessary to use on all of them because
for some of the buffers virXMLFormatElement() is called before any
return from the function but for consistency reasons it's better to use
g_auto() for all cases.
Fixes: d9b34ad12b2da231431a761b03ca038cdd44bd42 Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
virnetdevmacvlan: Drop udev busy loop from virNetDevMacVLanTapOpen()
Now that after previous commit the wait for udev to settle down
is done right after device creation, there's no need to have
additional wait in virNetDevMacVLanTapOpen(). It's effectively a
dead code. Remove it.
Tested-by: Johannes Segitz <jsegitz@suse.de> Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Fri, 10 Apr 2026 11:33:41 +0000 (13:33 +0200)]
virnetdevmacvlan: Wait for udev to settle after creating macvtap
When a macvtap interface is created (e.g. during domain startup
or on device hotplug) libvirt then open corresponding /dev/tapNN
in order to pass FDs to the hypervisor. These FDs are labelled
before passing, but if creating the interface and open() happen
in quick succession, i.e. when udev did not had chance to run,
then the /dev/tapNN node might have default SELinux label
(device_t) instead of correct one (tun_tap_device_t). This then
leads to AVC messages, like the following:
type=AVC msg=audit(1774535384.365:1238): avc: denied { open } for pid=6765
comm="rpc-virtqemud" path="/dev/tap33" dev="devtmpfs" ino=805
scontext=system_u:system_r:virtqemud_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
Therefore, allow udev to settle down after macvtap is created (by
calling virWaitForDevices()).
Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/866 Tested-by: Johannes Segitz <jsegitz@suse.de> Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Tue, 7 Apr 2026 00:38:32 +0000 (20:38 -0400)]
util: add info about g_get_user_*_dir directories to log banner
When running in session/unprivileged mode, nearly all paths are
prefixed with the returns from one of glib's g_get_user_*_dir()
functions, which in turn base their selected paths on the settings of
a few items in the user's environment ($XDG_*, or a subdirectory of
$HOME if the relevant $XDG_* isn't set).
This patch logs the settings of these directories in the log banner in
an attempt to help diagnose the problem when a file/socket open/create
fails.
Laine Stump [Fri, 3 Apr 2026 16:44:25 +0000 (12:44 -0400)]
util: add uid to the log banner
As libvirt is used more and more in unprivileged/session mode,
file/socket permission errors have become more common. This patch adds
the uid of the current libvirt process (whatever it may be) to the
"hostname" line in the log banner (the first thing sent to every log
target after the process starts).
This is a first step in providing more useful info for session mode
users. We can expand on this idea to include additional generally
useful stuff about the environment we're running in. (We just need to
remember that in this context we can't call anything that could lead
to recursively calling the logging system (i.e. we can't call any code
that reports an error, or a VIR_WARN, etc))
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Laine Stump [Fri, 3 Apr 2026 05:58:13 +0000 (01:58 -0400)]
util: make it easier to add lines to the log "init banner"
The same thing happens for each line of the log banner:
1) A helper function is called that a) creates a "raw" string (just
the desired info, e.g. version string) and b) calls
virLogFormatString() to create a "cooked" version of the string
(containing thread-id and log priority)
2) the outputFunc for the target is called with strings (a) and (b)
By making a helper that does (1b) & (2), we can further reduce the
amount of redundant code that needs to be written to add another line
to the banner - now all we need to do is:
1) create the raw string
2) call the helper, sending it the raw string
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Laine Stump [Wed, 1 Apr 2026 15:15:54 +0000 (11:15 -0400)]
util: eliminate duplicate code in virLogVMessage
The same several lines were repeated, once in a loop iterating through
all log targets, and again to output to stderr when there are no log
targets specified. This just moves those lines into a helper function,
making it easier and less error prone to add additional info to the
banner that is logged each time a daemon starts logging.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Laine Stump [Tue, 31 Mar 2026 21:32:30 +0000 (17:32 -0400)]
util: consistently use typedef virLogMetadata
For some reason there were some uses of this struct where "struct
_virLogMetadata" was used instead of just using the typedef
"virLogMetadata" (they are both defined in the same file -
virlog.h). Possibly at one point the struct was in virlog.c and
outsiders could only see it as an opaque object, but even if that was
the case, there are already cases of the typedef being used outside of
virlog.c, and constinuing to use "struct _virLogMetadata" in some
places both looks too much K&R 1st edition and might incorrectly imply
to someone that there *is* data abstraction/hiding going on when there
really isn't. So let's just always use plain virLogMetadata.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Laine Stump [Wed, 1 Apr 2026 16:51:19 +0000 (12:51 -0400)]
util: log the name of the log directory that couldn't be created
The message previously just said "Could not create log directory", but
didn't provide the name of the directory, which could be helpful in
determine why the failure occured.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Cole Robinson [Tue, 31 Mar 2026 15:39:58 +0000 (11:39 -0400)]
qemu: remove qemuDomainOpenFile() TODO comment
qemuDomainOpenFile() only acts on the 'dac' driver, where 'label'
and 'imagelabel' are always identical (see virSecurityDACGenLabel()).
So there's nothing TODO here
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
Laine Stump [Tue, 7 Apr 2026 02:42:43 +0000 (22:42 -0400)]
qemu: allow update-device of vhostuser network devices
When support for vhostuser devices was added, it was just
blanket-prevented from making any changes to a live device with
update-device. This is problematic because the link state of a network
device is modified with update-device. Most all of the parameters of a
vhostuser network device are individually checked within
qemuDomainChangeNet() anyway, so we don't need to just do a BRS (Big
Red Switch) forbidding of any change. We do need to check for
modifications to the socket parameters (path, type, reconnect) though,
since those are vhostuser-specific (we're not already checking for
them elsewhere) and they can't be changed on a live interface.
Resolves https://redhat.atlassian.net/browse/RHEL-152533
Resolves: https://bugs.passt.top/show_bug.cgi?id=198 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Laine Stump [Tue, 7 Apr 2026 02:51:14 +0000 (22:51 -0400)]
qemu: log error on attempts to change backend type of live network interface
Somehow we've never checked for this, and nobody has ever tested for
it or complained about it, but certainly attempting to change a user
or vhostuser network device to/from a passt backend wouldn't work. Now
we check for it and log an error.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
remote: Move secrets encryption dependency to a systemd drop-in
The monolithic libvirtd.service currently has a dependency on
virt-secret-init-encryption.service. This causes libvirtd to fail
to start on systems where the secret driver is not installed or
enabled, as systemd cannot satisfy the Requires= unit or the
LoadCredentialEncrypted= path. See below,
This patch decouples the secrets encryption logic from the main
libvirtd service file. It is moved into a new systemd drop-in
(10-secret.conf) which is only installed when libvirt is built
with secret driver support. The override snippet is added to the
daemon-driver-secret package.
Fixes: 97758bc9a0b1fccf8c0009308658f1204b113b89 Signed-off-by: Arun Menon <armenon@redhat.com> Fix-Suggested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
projects / thirdparty / libvirt.git / log
