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>
Michal Privoznik [Fri, 27 Mar 2026 11:17:44 +0000 (12:17 +0100)]
hyperv: Implement virDomainGetGuestInfo()
The hyperv hypervisor also has guest agent, in fact multiple ones
[1][2]. The first one, KVP, is for storing Key-Value Pairs and in
fact it's already used by our hyperv driver when querying
domifaddr (see v12.1.0-rc1~148 for more info). Anyhow, the KVP
service is capable of more, it can provide guest OS info, guest
FQDN and others. These informations are exposed via
GuestIntrinsicExchangeItems member of the
Msvm_KvpExchangeComponent struct [3]. You may have noticed the
member is an array of strings, well those strings are in fact XML
documents. For instance:
This is a bit messy to work with, because it's not like in QEMU's
world where each type of guest info (virDomainGuestInfoTypes)
corresponds 1:1 to a guest agent command. Hence the lookupTable
in hypervGetServicesProcessOne().
NB, the original jira issue asks for exposing plain fact whether
KVP daemon is running inside the guest and this commit implements
seemingly different feature. Well, thing is, in case of QEMU
there's a domain XML part where guest agent is configured and
where we expose whether there's somebody listening inside the
guest. But in case of hyperv there's no <channel/> to be
configured as communication with KVP daemon happens through
vmbus [4]. Users are advised to call the virDomainGetGuestInfo()
API with non-zero 'types' argument and if they get an error with
VIR_ERR_AGENT_UNRESPONSIVE code then the KVP daemon is not
running.
Michal Privoznik [Tue, 24 Mar 2026 14:58:19 +0000 (15:58 +0100)]
security: Don't error out on seclabels of type='none'
Ever since of commit v1.2.13-rc1~66 the model attribute of a
<seclabel/> is validated against secdriver names enabled. In
nearly all cases this is something users want so that domain XML
does not claim to set seclabels of a model that's not enabled.
However, consider the following seclabel:
<seclabel type='none' model='selinux'/>
It tells us to not bother setting selinux labels on given domain.
A mgmt app might format this into domain XML if it sees selinux
is disabled on the host. But if that's the case, selinux driver
is not loaded and this virSecurityManagerCheckModel() doesn't
find it and reports an error.
Well, the error doesn't need to be reported as we will just
ignore selinux as each driver callback checks if relabel is false
(which it is for type='none'). This is true for other secdrivers
too.
Resolves: https://redhat.atlassian.net/browse/RHEL-156689 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 25 Mar 2026 15:52:55 +0000 (16:52 +0100)]
security: Rewrite virSecurityManagerCheckModel() to use g_autofree
Let's use automatic memory freeing inside of
virSecurityManagerCheckModel() as it will simplify future
commits.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Wed, 25 Mar 2026 13:45:00 +0000 (14:45 +0100)]
conf: Fix seclabel type parsing wrt default value
Prior to v7.10.0-rc1~26 seclabels defaulted to
VIR_DOMAIN_SECLABEL_DYNAMIC (type='dynamic'). But after switching
the parser to virXMLPropEnum() the type is overwritten to
VIR_DOMAIN_SECLABEL_DEFAULT because the first thing that the
helper function does is to set variable that holds the result to
zero. Switch to virXMLPropEnumDefault() to restore the previous
behavior.
Fixes: f7ff8556ad9ba8d81408e31649071941a6a849a3 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Felix Huettner [Thu, 24 Apr 2025 14:26:32 +0000 (16:26 +0200)]
virhostcpu: Fix potential use of unallocated memory
In case of a host that has a large number of cpus offline the count of
host cpus and the last bit set in the virHostCPUGetOnlineBitmap might
diverge significantly. This can e.g. be the case when disabling smt via
/sys/devices/system/cpu/smt/control.
On the host this looks like:
```
$ cat /sys/devices/system/cpu/present
0-255
$ cat /sys/devices/system/cpu/online
0-127
```
However in this case virBitmapToData previously only allocated 16 bytes
for the output bitmap. This is becase the last set bit is on the 15th
byte.
Users of virHostCPUGetMap however rely on the "cpumap" containing enough
space for all existing cpus (so they would expect 32 bytes in this case).
E.g. cmdNodeCpuMap relies on this for its output. It will then actually
read 32 bytes from the start of the "cpumap" address where in this case
the last 16 of these bytes are uninitialized.
This manifests itself in flapping outputs of "virsh nodecpumap --pretty" like:
```
$ virsh nodecpumap --pretty
CPUs present: 256
CPUs online: 128
CPU map: 0-127,192,194,202
This in turn potentially causes users of this data to report wrong cpu
counts.
Note that this only seems to happen with at least 256 physical cpus
where at least 128 are offline.
We fix this by preallocating the expected bitmap size.
Signed-off-by: Felix Huettner <felix.huettner@stackit.cloud> Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pavel Hrdina [Tue, 31 Mar 2026 11:24:28 +0000 (13:24 +0200)]
qemu_hotplug: Set correct iommufdState on error path
If hotplugging host device that needs to add iommufd object fails we
need to remove the iommufd object as well. We also need to update the
iommufdState otherwise hotplugging any host device with iommufd will
fail for the same VM.
Fixes: 5d16bef1a69500791be454239e3b9ac68ec53ace Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Thu, 26 Mar 2026 13:32:36 +0000 (14:32 +0100)]
hypervisor: Call virWaitForDevices() after detaching host devices
On systems with selinux enabled starting a VM with managed host device
using IOMMUFD backend can run into race-condition where both libvirt and
udev are setting selinux label on /dev/vfio/devices/vfioX device. If
udev is the last one to set selinux label starting VM fails with:
error: internal error: QEMU unexpectedly closed the monitor (vm='test'): 2026-03-26T15:47:36.620422Z qemu-kvm: -device {"driver":"vfio-pci","id":"hostdev0","iommufd":"iommufd0","fd":"20","bus":"pci.7","addr":"0x0"}: vfio hostdev0: Failed to add fd 20 to KVM VFIO device: Invalid argument
We need to wait for udev to finish processing all events.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 27 Mar 2026 08:37:42 +0000 (09:37 +0100)]
virPCIDeviceReadID: Fix use of 'virFileReadAll'
Use 'virFileReadAllQuiet' since the function doesn't want to report
errors on other code paths.
The function also assumed that the file which it reads always 7 bytes
isn't true at least in the test suite. This didn't cause a problem
because the test data had strings 6 bytes long so it didn't cause a
write beyond the end of the buffer.
Clear the newline by using strchrnul instead to find it rather than
assuming where it is.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Fri, 27 Mar 2026 08:32:07 +0000 (09:32 +0100)]
virPCIDeviceReadClass: Don't write beyond end of buffer from virFileReadAll
The returned class string from the kernel isn't guaranteed to be always
9 bytes, thus the write to the buffer could happen beyond the guaranteed
length.
Since 'virFileReadAll' already NUL-terminates the buffer just delete
the redundant overwrite.
This fixes an invalid write beyond the end of the buffer happening since 458c6a281001d51fd9796 where the returned buffer is shortened.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Thu, 26 Mar 2026 17:39:17 +0000 (18:39 +0100)]
util: file: Shrink buffer returned from 'saferead_lim' to actual size
The bufer resizing algorithm resizes the buffer in increments of the
value of the 'BUFSIZ' macro. On linux it's currently 8k. In case when
the caller wants to retain the buffer for long time with little data
read this creates massive overhead.
Realloc the buffer to actual size before returning it to the user.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
==2413993== 8,193 bytes in 1 blocks are definitely lost in loss record 4,201 of 4,225
==2413993== at 0x48FC897: realloc (vg_replace_malloc.c:1804)
==2413993== by 0x4ED0B0A: g_realloc (in /usr/lib64/libglib-2.0.so.0.8600.4)
==2413993== by 0x494112B: virReallocN (viralloc.c:52)
==2413993== by 0x49684F6: saferead_lim (virfile.c:1511)
==2413993== by 0x4968C8B: virFileReadLimFD (virfile.c:1587)
==2413993== by 0x4968D2C: virFileReadAll (virfile.c:1613)
==2413993== by 0xC2CC488: virGetSecretsEncryptionKey (secret_config.c:93)
==2413993== by 0xC2CC488: virSecretDaemonConfigNew (secret_config.c:162)
==2413993== by 0xC2CADFD: secretStateInitialize (secret_driver.c:533)
==2413993== by 0x4BABC76: virStateInitialize (libvirt.c:667)
==2413993== by 0x40148D4: daemonRunStateInit (remote_daemon.c:583)
==2413993== by 0x49BB8A5: virThreadHelper (virthread.c:256)
==2413993== by 0x52DD463: start_thread (in /usr/lib64/libc.so.6)
Fixes: 1c86748cf140a8710d6d8ec3ab3a2bd10ceeac67 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
==2413993== 23 (16 direct, 7 indirect) bytes in 1 blocks are definitely lost in loss record 1,238 of 4,225
==2413993== at 0x48FC683: calloc (vg_replace_malloc.c:1678)
==2413993== by 0x4ED0A51: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8600.4)
==2413993== by 0x49A62CF: virPortAllocatorRangeNew (virportallocator.c:104)
==2413993== by 0xEA35F27: qemuStateInitialize (qemu_driver.c:723)
==2413993== by 0x4BABC76: virStateInitialize (libvirt.c:667)
==2413993== by 0x40148D4: daemonRunStateInit (remote_daemon.c:583)
==2413993== by 0x49BB8A5: virThreadHelper (virthread.c:256)
==2413993== by 0x52DD463: start_thread (in /usr/lib64/libc.so.6)
==2413993== by 0x5360413: clone (in /usr/lib64/libc.so.6)
Fixes: 36cf50f85b9c8f3351332dc5302401e4b06176e1 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 23 Mar 2026 21:33:49 +0000 (22:33 +0100)]
qemuDomainGetBlockInfo: Add debug statement when updating disk physical size
Update of the physical size fetches it from stat()-ing the file on disk,
which is not visible in the logs so the information can't be pieced back
together as it's the case with the data fetched from the qemu monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 23 Mar 2026 16:23:48 +0000 (17:23 +0100)]
qemuDomainGetStatsBlockExportDisk: Export stats also for 'dataStore'
For qcow2 disk images backed by another storage for storing the actual
blocks (the 'data-file' feature) we forgot to export stats in the bulk
stats API.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 18 Mar 2026 07:54:16 +0000 (08:54 +0100)]
qemuMigrationSrcBeginPhase: Don't call 'qemuBlockNodesEnsureActive' with offline VM
Commits 7b5566ce67b18a and f879d5f40385358 ( v11.8.0-92-gf879d5f403 )
moved around code for re-activating block backends after migration.
While previously it was done when migration failed now we do it when we
need qemu to do some block operations.
'qemuBlockNodesEnsureActive' is thus called also when 'VIR_MIGRATE_OFFLINE'
is used. This doesn't cause failure similar to previous patch only due
to a conincidence as 'qemuCaps' wasn't initialized yet and thus we
assume that QEMU doesn't support 'blockdev-set-active' and skip all
monitor code.
Make the code more robust and explicit by calling
'qemuBlockNodesEnsureActive' only on active VMs during migration.
Fixes: 7b5566ce67b18a2bebe68fdb07e046f25185f8d3 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Peter Krempa [Mon, 23 Mar 2026 21:39:58 +0000 (22:39 +0100)]
qemuMigrationSrcBeginXML: Don't call 'qemuMigrationSrcBeginPhaseBlockDirtyBitmaps' with offline VM
Commit a4f610ff3fe190058f1 made the call to
'qemuMigrationSrcBeginPhaseBlockDirtyBitmaps' inside
'qemuMigrationSrcBeginXML' unconditional. This unfortunately means that
it was called also with 'VIR_MIGRATE_OFFLINE'.
Attempting to enter the monitor in such case results in an error:
error: operation failed: domain is no longer running
The migration parameter allows enumerating disks selected for migration
where the hypervisor may assume that the user pre-cleared the
destination images of the block copy so that all offsets read 0x00 and
thus optimize clearing of such targets.
This patch adds the 'VIR_MIGRATE_PARAM_MIGRATE_DISKS_TARGET_ZERO'
parameter and also plumbs it for the qemu driver (mirrors plumbing for
'migrate_disks_detect_zeroes').
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'target-is-zero' option of 'blockdev-mirror' allows telling qemu to
skip zeroing the mirror target if the user certifies that it's empty. It
was introduced in qemu-10.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
