- Devel - libvirt List Archives

vDPA devices and random MAC address assignment
by Beñat Gartzia Arruabarrena 12 Sep '25

12 Sep '25

Hello, I am trying to find a solution to an issue related to vhost-vdpa devices and random mac addresses being assigned to them, if not set by the user. vDPA devices are assigned a MAC address the time they are created. That happens before creating the VM with qemu or libvirt. If the mac address of the vdpa device in the qemu command line does not match the mac address that was assigned to the vdpa device at creation time, the network traffic will not work. If the user does not explicitly configure a mac address for the vdpa device in the domain xml, libvirt will generate a random one and use it instead in the qemu command line. This leads to an interface that does not work. If I understood correctly, qemu is not able to update the mac address of the vdpa device based on the command line configuration, so setting the mac address generated by libvirt is not an option. Currently, a patch that introduces a set of checks comparing cmdline and device mac addresses is under review: https://lore.kernel.org/qemu-devel/20250417102522.4125379-1-lulu@redhat.com/ The implementation also adds the logic to configure the vdpa device mac address in the virtio net device if a mac address was not provided in the command line. I was trying to write a patch such that it would allow vdpa devices to have an empty mac address in the domain xml as an exception. The draft allowed such case in virDomainNetDefParseXML and virDomainNetDefFormat and avoided writing an empty mac address in the qemu command line by modifying the logic in qemuBuildNicDevProps. However, there are plenty of other functions and places that would expect the mac address to be there. Guarding against the empty mac addr case in all those places, is not desirable, I think. I'm not sure if libvirt could read the mac address of the device being assigned to the VM instead of generating a random mac address in the case of vdpa devices. It could probably require some code from qemu being duplicated. Could that be an acceptable alternative? I am also looking for any other recommendation on how I could look into this issue. Thanks a lot. Regards, Beñat

2 1

[PATCH v3 0/2] Introduce virDomainBlockRebaseParams API
by Nikolai Barybin 11 Sep '25

11 Sep '25

Changes since last revision: - Renamed API function name Nikolai Barybin (2): api: remote: introduce virDomainBlockRebaseParams API qemu: implement driver support for domainBlockRebaseParams API include/libvirt/libvirt-domain.h | 43 +++++++++++++++++++++ src/driver-hypervisor.h | 8 ++++ src/libvirt-domain.c | 65 ++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 5 +++ src/qemu/qemu_driver.c | 48 +++++++++++++++++++++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 17 ++++++++- src/remote_protocol-structs | 10 +++++ 8 files changed, 196 insertions(+), 1 deletion(-) -- 2.43.5

2 4

[PATCH 0/2] ch: Two simple fixes
by Michal Privoznik 11 Sep '25

11 Sep '25

While working on emitting more events from the CH driver and playing with cloud-hypervisor itself, I've noticed one memleak and one forgotten call to unlock. Michal Prívozník (2): ch: Avoid memory leak in virCHProcessEvents() ch: Unlock domain in virCHEventStopProcess() on all exit paths src/ch/ch_events.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.49.1

2 3

[PATCH 0/6] qemu: refactor disk migration safety check and add corner case exemption for Kubevirt's usage
by Peter Krempa 10 Sep '25

10 Sep '25

Patches 1-3 are refactors that simplify the code and prepare it. Patch 4 fixed bug where 'data_file' is not checked Patches 5 and 6 add a workaround for Kubevirt's corner case migration approach. Peter Krempa (6): qemuMigrationSrcIsSafe: Drop 'DEBUG' message about qemu supporting cache dropping qemuMigrationSrcIsSafe: Extract code for checking safe migrability of one disk qemuMigrationSrcIsSafeDisk: Extract safe migration checks for one storage source qemuMigrationSrcIsSafeDisk: Check also data file propertiues for migrability qemuBlockGetNamedNodeData: Extract 'data_file_raw' flag qemuMigrationSrcIsSafeDisk: Allow non-shared qcow2's with raw data file src/qemu/qemu_migration.c | 188 ++++++++++++------ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 3 + tests/qemublocktest.c | 2 + tests/qemublocktestdata/bitmap/synthetic.json | 1 + tests/qemublocktestdata/bitmap/synthetic.out | 1 + 6 files changed, 133 insertions(+), 65 deletions(-) -- 2.51.0

2 8

[PATCH v2 00/10] qemu: Fixes to firmware selection
by Andrea Bolognani 10 Sep '25

10 Sep '25

Changes from [v1]: * pick up Jim's test suite improvements; * squash in fixes for issues found during review; * add a few commits intented to spark further discussion around what the firmware descriptors should look like in the edk2 package. [v1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/RKQ3… Andrea Bolognani (9): tests: Tweak descriptor for combined firmware tests: Minimize SEV tests tests: Add tests for SEV firmware selection qemu: Fix matching for stateless/combined firmware qemu: Fix matching for read/write firmware news: Update for firmware selection fixes DONOTMERGE update firmware data DONOTMERGE remove SEV features from non-SEV descriptors DONOTMERGE don't explicitly request stateless firmware for SEV Jim Fehlig (1): tests: Improve AMD SEV-related tests NEWS.rst | 5 ++ src/qemu/qemu_firmware.c | 47 ++++++++++++++----- .../firmware/60-edk2-ovmf-x64-amdsev.json | 1 - .../50-edk2-ovmf-4m-qcow2-x64-nosb.json | 2 - .../51-edk2-ovmf-2m-raw-x64-nosb.json | 2 - .../firmware/60-edk2-ovmf-x64-amdsev.json | 3 +- .../firmware/60-edk2-ovmf-x64-amdsevsnp.json} | 14 +++--- .../usr/share/qemu/firmware/90-combined.json | 5 +- tests/qemufirmwaretest.c | 4 +- ...ware-auto-efi-rw-pflash.x86_64-latest.args | 36 ++++++++++++++ ...mware-auto-efi-rw-pflash.x86_64-latest.err | 1 - ...mware-auto-efi-rw-pflash.x86_64-latest.xml | 6 ++- .../firmware-auto-efi-rw.x86_64-latest.args | 36 ++++++++++++++ .../firmware-auto-efi-rw.x86_64-latest.err | 1 - .../firmware-auto-efi-rw.x86_64-latest.xml | 6 ++- ...auto-efi-sev-snp.x86_64-latest+amdsev.args | 35 ++++++++++++++ ...auto-efi-sev-snp.x86_64-latest+amdsev.xml} | 9 +++- .../firmware-auto-efi-sev-snp.xml | 20 ++++++++ ...are-auto-efi-sev.x86_64-latest+amdsev.args | 36 ++++++++++++++ ...are-auto-efi-sev.x86_64-latest+amdsev.xml} | 9 +++- .../qemuxmlconfdata/firmware-auto-efi-sev.xml | 20 ++++++++ ...urity-sev-direct.x86_64-latest+amdsev.args | 7 ++- ...curity-sev-direct.x86_64-latest+amdsev.xml | 19 +++----- ...nch-security-sev-direct.x86_64-latest.args | 7 ++- ...unch-security-sev-direct.x86_64-latest.xml | 19 +++----- .../launch-security-sev-direct.xml | 19 +------- ...ng-platform-info.x86_64-latest+amdsev.args | 9 ++-- ...ing-platform-info.x86_64-latest+amdsev.xml | 29 ++++++------ ...nch-security-sev-missing-platform-info.xml | 25 +++------- ...security-sev-snp.x86_64-latest+amdsev.args | 11 +---- ...-security-sev-snp.x86_64-latest+amdsev.xml | 29 +----------- ...launch-security-sev-snp.x86_64-latest.args | 11 +---- .../launch-security-sev-snp.x86_64-latest.xml | 29 +----------- .../launch-security-sev-snp.xml | 45 +----------------- ...nch-security-sev.x86_64-latest+amdsev.args | 9 ++-- ...unch-security-sev.x86_64-latest+amdsev.xml | 29 ++++++------ tests/qemuxmlconfdata/launch-security-sev.xml | 25 +++------- tests/qemuxmlconftest.c | 11 ++++- 38 files changed, 352 insertions(+), 279 deletions(-) copy tests/qemufirmwaredata/{out/usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json => usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsevsnp.json} (57%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml} (78%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.args copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev.x86_64-latest+amdsev.xml} (77%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.xml -- 2.51.0

2 24

[libvirt-python PATCH] build: Adapt to PEP 625 distribution file naming
by Jiri Denemark 10 Sep '25

10 Sep '25

The version of setuptools shipped by Fedora 42 is PEP 625 compliant, which requires distribution files to contain a normalized package name. Thus the generated tarball is called libvirt_python-$VER.tar.gz rather than libvirt-python-$VER.tar.gz created by older setuptools. The source directory inside the tarball follows the same naming. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- .gitlab-ci.yml | 4 ++-- Makefile | 2 +- libvirt-python.spec.in | 10 ++++++++-- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index bc4ff48..1267c47 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -34,7 +34,7 @@ stages: - if test -x /usr/bin/rpmbuild && test "$RPM" != "skip" ; then unset CFLAGS ; - rpmbuild --clean --nodeps --define "_topdir $PWD/rpmbuild" -ta dist/libvirt-python*tar.gz ; + rpmbuild --clean --nodeps --define "_topdir $PWD/rpmbuild" -ta dist/libvirt[-_]python*tar.gz ; mv rpmbuild/RPMS/x86_64/ libvirt-python-rpms ; fi @@ -51,7 +51,7 @@ stages: - if test -x /usr/bin/rpmbuild && test "$RPM" != "skip" ; then unset CFLAGS ; - rpmbuild --clean --nodeps --define "_topdir $PWD/rpmbuild" -ta dist/libvirt-python*tar.gz ; + rpmbuild --clean --nodeps --define "_topdir $PWD/rpmbuild" -ta dist/libvirt[-_]python*tar.gz ; mv rpmbuild/RPMS/x86_64/ libvirt-python-rpms ; fi diff --git a/Makefile b/Makefile index 925af40..0b2af28 100644 --- a/Makefile +++ b/Makefile @@ -19,4 +19,4 @@ test: all tox rpm: all - rpmbuild -ta dist/libvirt-python-$(shell tr -d '\n' < VERSION).tar.gz + rpmbuild -ta dist/libvirt[-_]python-$(shell tr -d '\n' < VERSION).tar.gz diff --git a/libvirt-python.spec.in b/libvirt-python.spec.in index e260eaf..dd0c71b 100644 --- a/libvirt-python.spec.in +++ b/libvirt-python.spec.in @@ -12,11 +12,17 @@ %define supported_platform 0 %endif +%if 0%{?rhel} || 0%{?fedora} < 42 + %define dist_name %{name} +%else + %define dist_name libvirt_python +%endif + Summary: The libvirt virtualization API python3 binding Name: libvirt-python Version: @VERSION@ Release: 1%{?dist} -Source0: https://libvirt.org/sources/python/%{name}-%{version}.tar.gz +Source0: https://libvirt.org/sources/python/%{dist_name}-%{version}.tar.gz Url: https://libvirt.org License: LGPL-2.1-or-later BuildRequires: libvirt-devel == %{version} @@ -51,7 +57,7 @@ supplied by the libvirt library to use the virtualization capabilities of recent versions of Linux (and other OSes). %prep -%setup -q +%setup -q -n %{dist_name}-%{version} # Unset execute bit for example scripts; it can introduce spurious # RPM dependencies, like /usr/bin/python3 -- 2.51.0

5 4

[PATCH 0/4] ch: Disk attach/detach fixes
by Michal Privoznik 10 Sep '25

10 Sep '25

While reviewing Stefan patches [1] I've changed some of them before merging and oopsie, I've introduced a bug (patch 1/4) but fortunately forgot to remove the code I intended to move so it actually works :-D. 1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HAZR… Michal Prívozník (4): ch: Actually remove device in chDomainDetachDeviceLive() ch: Drop deadcode from chDomainDetachDeviceLive() ch: Drop useless variable in chDomainFindDisk() ch: Avoid memleak on disk detach in chDomainRemoveDevice() src/ch/ch_hotplug.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) -- 2.49.1

2 5

[PATCH] ch: Avoid memleak in virCHDriverConfigDispose()
by Michal Privoznik 10 Sep '25

10 Sep '25

From: Michal Privoznik <mprivozn(a)redhat.com> When virCHDriverConfig struct is initialized in virCHDriverConfigNew() the 'configDir' member is allocated but corresponding free is missing in virCHDriverConfigDispose(). While at it, reorder the free calls to match the order in which they are declared in the struct so it's easier to spot missing free call. 20 bytes in 1 blocks are definitely lost in loss record 667 of 2,033 at 0x4912888: malloc (vg_replace_malloc.c:446) by 0x5436747: __vasprintf_internal (in /usr/lib64/libc.so.6) by 0x503EC81: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.8400.3) by 0x500805B: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.8400.3) by 0x5008124: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.8400.3) by 0xB8C2B70: virCHDriverConfigNew (ch_conf.c:181) by 0xB8C9DDA: chStateInitialize (ch_driver.c:1456) by 0x4D9E316: virStateInitialize (libvirt.c:667) by 0x40539DB: daemonRunStateInit (remote_daemon.c:581) by 0x4AC1EB4: virThreadHelper (virthread.c:256) by 0x5441DE3: start_thread (in /usr/lib64/libc.so.6) by 0x54C25F3: clone (in /usr/lib64/libc.so.6) Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/ch/ch_conf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/ch/ch_conf.c b/src/ch/ch_conf.c index b9432e2a42..8a542eef19 100644 --- a/src/ch/ch_conf.c +++ b/src/ch/ch_conf.c @@ -211,9 +211,10 @@ virCHDriverConfigDispose(void *obj) { virCHDriverConfig *cfg = obj; - g_free(cfg->saveDir); g_free(cfg->stateDir); + g_free(cfg->configDir); g_free(cfg->logDir); + g_free(cfg->saveDir); } #define MIN_VERSION ((15 * 1000000) + (0 * 1000) + (0)) -- 2.49.1

2 1

[PATCH 0/4] ch: Improve domain destroy
by Michal Privoznik 10 Sep '25

10 Sep '25

*** BLURB HERE *** Michal Prívozník (4): virprocess: Report errno if virProcessAbort() fails ch: Make sure the cloud-hypervisor process is killed in virCHProcessStop() ch: Introduce flags to virCHProcessStop() ch: Implement VIR_DOMAIN_DESTROY_GRACEFUL flag support src/ch/ch_driver.c | 13 ++++++++++--- src/ch/ch_events.c | 2 +- src/ch/ch_process.c | 22 ++++++++++++++++------ src/ch/ch_process.h | 8 +++++++- src/util/virprocess.c | 3 ++- 5 files changed, 36 insertions(+), 12 deletions(-) -- 2.49.1

2 5

[PATCH v3 00/13] CH: Add disk hotplug support to Cloud Hypervisor domains
by Stefan Kober 09 Sep '25

09 Sep '25

This patchset adds the necessary functionality to support disk hotplugging in the CH driver. Some alias handling that can be extended to other device types is added, in order to allow detaching the devices via the Cloud Hypervisor API. Stefan Kober (13): ch: add ch_hotplug.{h,c} files to CH build ch: pass disk alias to CHV ch: add ch_alias.{c,h} for device alias handling ch: refactor virCHMonitorBuildDiskJson ch: add/use virCHMonitorPut function ch: add monitor disk attach logic ch: add disk attach helper functions ch: implement disk attach in public API ch: assign aliases in ProcessPrepareDomain ch: add virCHMonitorBuildKeyValueJson ch: add virCHMonitorRemoveDevice function ch: implement disk device detach in public API NEWS: announce disk hotplug support for ch NEWS.rst | 5 + po/POTFILES | 2 + src/ch/ch_alias.c | 62 +++++++++ src/ch/ch_alias.h | 27 ++++ src/ch/ch_driver.c | 86 ++++++++++++ src/ch/ch_hotplug.c | 333 ++++++++++++++++++++++++++++++++++++++++++++ src/ch/ch_hotplug.h | 33 +++++ src/ch/ch_monitor.c | 131 ++++++++++++++--- src/ch/ch_monitor.h | 7 + src/ch/ch_process.c | 4 + src/ch/meson.build | 4 + 11 files changed, 671 insertions(+), 23 deletions(-) create mode 100644 src/ch/ch_alias.c create mode 100644 src/ch/ch_alias.h create mode 100644 src/ch/ch_hotplug.c create mode 100644 src/ch/ch_hotplug.h -- 2.50.1

3 24