There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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: 5d16bef1a6
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
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>
Document both the behaviour if requested length isn't enough to read the
file as well as the semantics of NUL-termination of the buffer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
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>
The buffer is already terminated. Luckily the last character in the
buffer was a newline so no information was mangled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The buffer returned from 'virFileReadAll' is NUL terminated no need to
do it explicitly or to shorten it since this is now also done.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
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
458c6a2810 where the returned buffer is shortened.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
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: 1c86748cf1
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: 36cf50f85b
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The documentation to virXMLPropTristateBoolAllowDefault() refers
to itself while it meant to refer to virXMLPropTristateBool().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
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>
The 'disk' argument was forgotten in the VIR_DOMAIN_DEBUG statement so
the logs don't contain which disk the caller wanted the stats for.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'virt 4.2' machine type is removed in QEMU 10.2. So pin the
existing tests to qemu-10.0 and add tests for 'virt-10.0'
machine type.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Commits 7b5566ce67 and f879d5f403 ( 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: 7b5566ce67
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add '--migrate-disks-target-zero' to pass the list of pre-zeroed disk
images.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
Allow the hypervisor to assume that the user already passed a zeroed-out
image to optimize the copy. Implement the feature for the qemu driver.
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>
Any QEMU we support requires use of NBD for disk migration which is not
supported with tunnelled migration. This is validated in
'qemuMigrationSrcBeginPhase'. Passing the list of disks to migrate is
thus pointless. Remove the argument.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The operation is not implemented so it's not really an internal error.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When parsing port ranges for the port allocator VIR_ERR_INTERNAL_ERROR
is not the right error code for errors on the user-supplied numbers. Use
VIR_ERR_CONF_SYNTAX instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>