- Devel - libvirt List Archives

[libvirt PATCH 0/2] docs: Switch to DuckDuckGo for search
by Andrea Bolognani 05 Dec '23

05 Dec '23

Andrea Bolognani (2): docs: Use DuckDuckGo for website/wiki search docs: Mention use of DuckDuckGo docs/css/libvirt.css | 2 +- docs/js/main.js | 16 +++++++++++----- docs/page.xsl | 8 ++++---- 3 files changed, 16 insertions(+), 10 deletions(-) -- 2.43.0

2 3

[libvirt PATCH 0/9] rpm: Tweak dependencies
by Andrea Bolognani 05 Dec '23

05 Dec '23

Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1092535621 lcitool changes: https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/447 Andrea Bolognani (9): rpm: Drop MinGW BuildRequires on libgcrypt/libgpg-error meson: Stop looking for udevadm at build time meson: Stop looking for scrub at build time meson: Stop looking for passt at build time rpm: Add Requires on scrub rpm: Drop BuildDepends on scrub rpm: Drop BuildDepends on passt ci: Refresh generated files ci: Stop passing --nodeps to rpmbuild ci/buildenv/almalinux-8.sh | 5 ++++- ci/buildenv/alpine-317.sh | 1 + ci/buildenv/alpine-edge.sh | 1 + ci/buildenv/centos-stream-8.sh | 5 ++++- ci/buildenv/centos-stream-9.sh | 5 ++++- ci/buildenv/debian-11-cross-aarch64.sh | 2 +- ci/buildenv/debian-11-cross-armv6l.sh | 2 +- ci/buildenv/debian-11-cross-armv7l.sh | 2 +- ci/buildenv/debian-11-cross-i686.sh | 2 +- ci/buildenv/debian-11-cross-mips64el.sh | 2 +- ci/buildenv/debian-11-cross-mipsel.sh | 2 +- ci/buildenv/debian-11-cross-ppc64le.sh | 2 +- ci/buildenv/debian-11-cross-s390x.sh | 2 +- ci/buildenv/debian-11.sh | 2 +- ci/buildenv/debian-12-cross-aarch64.sh | 2 +- ci/buildenv/debian-12-cross-armv6l.sh | 2 +- ci/buildenv/debian-12-cross-armv7l.sh | 2 +- ci/buildenv/debian-12-cross-i686.sh | 2 +- ci/buildenv/debian-12-cross-mips64el.sh | 2 +- ci/buildenv/debian-12-cross-mipsel.sh | 2 +- ci/buildenv/debian-12-cross-ppc64le.sh | 2 +- ci/buildenv/debian-12-cross-s390x.sh | 2 +- ci/buildenv/debian-12.sh | 2 +- ci/buildenv/debian-sid-cross-aarch64.sh | 2 +- ci/buildenv/debian-sid-cross-armv6l.sh | 2 +- ci/buildenv/debian-sid-cross-armv7l.sh | 2 +- ci/buildenv/debian-sid-cross-i686.sh | 2 +- ci/buildenv/debian-sid-cross-mips64el.sh | 2 +- ci/buildenv/debian-sid-cross-ppc64le.sh | 2 +- ci/buildenv/debian-sid-cross-s390x.sh | 2 +- ci/buildenv/debian-sid.sh | 2 +- ci/buildenv/fedora-37.sh | 2 +- ci/buildenv/fedora-38-cross-mingw32.sh | 2 +- ci/buildenv/fedora-38-cross-mingw64.sh | 2 +- ci/buildenv/fedora-38.sh | 2 +- ci/buildenv/fedora-rawhide-cross-mingw32.sh | 2 +- ci/buildenv/fedora-rawhide-cross-mingw64.sh | 2 +- ci/buildenv/fedora-rawhide.sh | 2 +- ci/buildenv/opensuse-leap-15.sh | 5 ++++- ci/buildenv/opensuse-tumbleweed.sh | 4 ++-- ci/buildenv/ubuntu-2004.sh | 2 +- ci/buildenv/ubuntu-2204.sh | 2 +- ci/cirrus/freebsd-12.vars | 2 +- ci/cirrus/freebsd-13.vars | 2 +- ci/cirrus/macos-13.vars | 2 +- ci/cirrus/macos-14.vars | 2 +- ci/containers/almalinux-8.Dockerfile | 6 +++++- ci/containers/alpine-317.Dockerfile | 1 + ci/containers/alpine-edge.Dockerfile | 1 + ci/containers/centos-stream-8.Dockerfile | 6 +++++- ci/containers/centos-stream-9.Dockerfile | 6 +++++- ci/containers/debian-11-cross-aarch64.Dockerfile | 2 +- ci/containers/debian-11-cross-armv6l.Dockerfile | 2 +- ci/containers/debian-11-cross-armv7l.Dockerfile | 2 +- ci/containers/debian-11-cross-i686.Dockerfile | 2 +- ci/containers/debian-11-cross-mips64el.Dockerfile | 2 +- ci/containers/debian-11-cross-mipsel.Dockerfile | 2 +- ci/containers/debian-11-cross-ppc64le.Dockerfile | 2 +- ci/containers/debian-11-cross-s390x.Dockerfile | 2 +- ci/containers/debian-11.Dockerfile | 2 +- ci/containers/debian-12-cross-aarch64.Dockerfile | 2 +- ci/containers/debian-12-cross-armv6l.Dockerfile | 2 +- ci/containers/debian-12-cross-armv7l.Dockerfile | 2 +- ci/containers/debian-12-cross-i686.Dockerfile | 2 +- ci/containers/debian-12-cross-mips64el.Dockerfile | 2 +- ci/containers/debian-12-cross-mipsel.Dockerfile | 2 +- ci/containers/debian-12-cross-ppc64le.Dockerfile | 2 +- ci/containers/debian-12-cross-s390x.Dockerfile | 2 +- ci/containers/debian-12.Dockerfile | 2 +- ci/containers/debian-sid-cross-aarch64.Dockerfile | 2 +- ci/containers/debian-sid-cross-armv6l.Dockerfile | 2 +- ci/containers/debian-sid-cross-armv7l.Dockerfile | 2 +- ci/containers/debian-sid-cross-i686.Dockerfile | 2 +- ci/containers/debian-sid-cross-mips64el.Dockerfile | 2 +- ci/containers/debian-sid-cross-ppc64le.Dockerfile | 2 +- ci/containers/debian-sid-cross-s390x.Dockerfile | 2 +- ci/containers/debian-sid.Dockerfile | 2 +- ci/containers/fedora-37.Dockerfile | 2 +- ci/containers/fedora-38-cross-mingw32.Dockerfile | 2 +- ci/containers/fedora-38-cross-mingw64.Dockerfile | 2 +- ci/containers/fedora-38.Dockerfile | 2 +- ci/containers/fedora-rawhide-cross-mingw32.Dockerfile | 2 +- ci/containers/fedora-rawhide-cross-mingw64.Dockerfile | 2 +- ci/containers/fedora-rawhide.Dockerfile | 2 +- ci/containers/opensuse-leap-15.Dockerfile | 6 +++++- ci/containers/opensuse-tumbleweed.Dockerfile | 4 ++-- ci/containers/ubuntu-2004.Dockerfile | 2 +- ci/containers/ubuntu-2204.Dockerfile | 2 +- ci/jobs.sh | 1 - libvirt.spec.in | 11 ++--------- meson.build | 3 --- src/qemu/qemu_passt.c | 3 +++ src/storage/storage_util.c | 1 + src/util/virutil.c | 2 ++ 94 files changed, 126 insertions(+), 99 deletions(-) -- 2.43.0

2 10

[PATCH] NEWS: Fix indentation
by Andrea Bolognani 01 Dec '23

01 Dec '23

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. NEWS.rst | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index c0a6d180a2..dc40602c72 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -176,10 +176,10 @@ v9.6.0 (2023-08-01) * ``CVE-2023-3750``: Fix race condition in storage driver leading to a crash - In **libvirt-8.3** a bug was introduced which in rare cases could cause - ``libvirtd`` or ``virtstoraged`` to crash if multiple clients attempted to - look up a storage volume by key, path or target path, while other clients - attempted to access something from the same storage pool. + In **libvirt-8.3** a bug was introduced which in rare cases could cause + ``libvirtd`` or ``virtstoraged`` to crash if multiple clients attempted to + look up a storage volume by key, path or target path, while other clients + attempted to access something from the same storage pool. * **Improvements** @@ -1983,17 +1983,17 @@ v7.1.0 (2021-03-01) * qemu: Fix disk quiescing rollback when creating external snapshots - If the qemu guest agent call to freeze filesystems failed when creating - an external snapshot with ``VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE`` flag the - filesystems would be unconditionally thawed. This could cause problems when - the filesystems were frozen by an explicit call to ``virDomainFSFreeze`` - since the guest agent then rejects any further freeze attempts once are - filesystems frozen, an explicit freeze followed by a quiesced snapshot - would fail and thaw filesystems. + If the qemu guest agent call to freeze filesystems failed when creating + an external snapshot with ``VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE`` flag the + filesystems would be unconditionally thawed. This could cause problems when + the filesystems were frozen by an explicit call to ``virDomainFSFreeze`` + since the guest agent then rejects any further freeze attempts once are + filesystems frozen, an explicit freeze followed by a quiesced snapshot + would fail and thaw filesystems. - Users are also encouraged to use ``virDomainFSFreeze/Thaw`` manually instead - of relying on ``VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE`` if they need finer - grained control. + Users are also encouraged to use ``virDomainFSFreeze/Thaw`` manually instead + of relying on ``VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE`` if they need finer + grained control. * cgroups: Fix how we setup and configure cgroups on hosts with systemd @@ -2155,11 +2155,12 @@ v6.10.0 (2020-12-01) * qemu: Enable client TLS certificate validation by default for ``chardev``, ``migration``, and ``backup`` servers. - The default value if qemu.conf options ``chardev_tls_x509_verify``, - ``migrate_tls_x509_verify``, or ``backup_tls_x509_verify`` are not specified - explicitly in the config file and also the ``default_tls_x509_verify`` config - option is missing are now '1'. This ensures that only legitimate clients - access servers, which don't have any additional form of authentication. + The default value if qemu.conf options ``chardev_tls_x509_verify``, + ``migrate_tls_x509_verify``, or ``backup_tls_x509_verify`` are not + specified explicitly in the config file and also the + ``default_tls_x509_verify`` config option is missing are now '1'. This + ensures that only legitimate clients access servers, which don't have any + additional form of authentication. * qemu: Introduce "migrate_tls_force" qemu.conf option -- 2.43.0

1 0

[PATCH] NEWS: Fix vertical spacing
by Andrea Bolognani 01 Dec '23

01 Dec '23

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. NEWS.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index 29b977565b..c0a6d180a2 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -89,6 +89,7 @@ v9.9.0 (2023-11-01) The ``virsh create --console`` now tries to connect to the guest console before starting the vCPUs. + v9.8.0 (2023-10-02) =================== @@ -131,6 +132,7 @@ v9.8.0 (2023-10-02) Now libvirt validates more values of virtio-mem and virtio-pmem devices, e.g. overlapping memory addresses or alignment. + v9.7.0 (2023-09-01) =================== @@ -2549,7 +2551,6 @@ v6.6.0 (2020-08-02) management applications may wish to override this behaviour. This is now possible via new ``cow`` element. - * **Improvements** * esx: Change the NIC limit for recent virtualHW versions @@ -2574,7 +2575,6 @@ v6.6.0 (2020-08-02) instead of all possible CPUs are returned making these APIs consistent with the behavior of ``vcpuinfo``. - * **Bug fixes** * virdevmapper: Don't use libdevmapper to obtain dependencies -- 2.43.0

1 0

Release of libvirt-9.10.0
by Jiri Denemark 01 Dec '23

01 Dec '23

The 9.10.0 release of both libvirt and libvirt-python is tagged and signed tarballs and source RPMs are available at https://download.libvirt.org/ https://download.libvirt.org/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * New features * Introduce pipewire audio backend The QEMU hypervisor driver now allows setting ``pipewire`` backend for ``<audio/>`` device. * Improvements * Adapt to qemu's use of protocol drivers in QCOW2 'backing file format' field QEMU allows creating images where the 'backing file format' is actually a protocol name such as 'file'/'host_device'/'nbd'/etc.. Adapt libvirt to properly handle such images and don't assume automatic format probing is necessary, which is in many cases forbidden due to security implications. * Bug fixes * qemu: Fix setup of images on hotplug of disk Internal image metadata was not setup correctly which could cause some disk hotplug configurations (namely those including backing images) to fail. * qemu: Fix qemu crash when reverting an internal snapshot Libvirt attempted to start qemu with wrong arguments when attempting to revert to an internal snapshot causing qemu to crash. * qemu: Fix hotplug of empty cdrom Empty cdrom drive couldn't be hotplugged as libvirt wanted to setup the storage backing it unconditionally. Enjoy. Jirka

1 0

[libvirt PATCH 0/1] rpcgen: Skip generator tests on macOS
by Andrea Bolognani 01 Dec '23

01 Dec '23

Based on: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/GLJL… Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1091405064 Since we're supposed to tag 9.10.0 tomorrow, go for the quick and dirty workaround. Andrea Bolognani (1): rpcgen: Skip generator tests on macOS scripts/rpcgen/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.43.0

2 3

[PATCH 0/2] Report better error message with no socket to connect to
by Martin Kletzander 01 Dec '23

01 Dec '23

When opening a libvirt connection with no URI set and no daemon running the error message might be confusing at times, so these patches are trying to mitigate such confusion. Martin Kletzander (2): Report first tried socket from remoteProbeSystemDriverFromSocket Report better error message in remoteGetUNIXSocket src/remote/remote_daemon_dispatch.c | 2 +- src/remote/remote_sockets.c | 22 ++++++++++++++++++---- src/remote/remote_sockets.h | 2 +- 3 files changed, 20 insertions(+), 6 deletions(-) -- 2.43.0

5 25

[PATCH] NEWS: Mention image probing, snaphsot and hotplug fixes
by Peter Krempa 01 Dec '23

01 Dec '23

Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index f12734c2a1..9739bcdc36 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -24,8 +24,30 @@ v9.10.0 (unreleased) * **Improvements** + * Adapt to qemu's use of protocol drivers in QCOW2 'backing file format' field + + QEMU allows creating images where the 'backing file format' is actually a + protocol name such as 'file'/'host_device'/'nbd'/etc.. Adapt libvirt to + properly handle such images and don't assume automatic format probing is + necessary, which is in many cases forbidden due to security implications. + * **Bug fixes** + * qemu: Fix setup of images on hotplug of disk + + Internal image metadata was not setup correctly which could cause some disk + hotplug configurations (namely those including backing images) to fail. + + * qemu: Fix qemu crash when reverting an internal snapshot + + Libvirt attempted to start qemu with wrong arguments when attempting to + revert to an internal snapshot causing qemu to crash. + + * qemu: Fix hotplug of empty cdrom + + Empty cdrom drive couldn't be hotplugged as libvirt wanted to setup the + storage backing it unconditionally. + v9.9.0 (2023-11-01) =================== -- 2.43.0

2 1

[PATCH for 9.9.0] qemuProcessStartWithMemoryState: Don't start qemu with '-loadvm SNAP' and '-incoming defer' together
by Peter Krempa 01 Dec '23

01 Dec '23

A bug in qemuProcessStartWithMemoryState caused that we would start qemu with '-loadvm SNAP' and '-incoming defer' together. qemu doesn't expect that and crashes on an assertion failure [1]. [1]: https://issues.redhat.com/browse/RHEL-16782 Fixes: 8a88d3e5860881f430e528d3e5e8d6455ded4d1d Resolves: https://issues.redhat.com/browse/RHEL-17841 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_process.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index f32e82bbd1..fc05b4b24f 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8196,6 +8196,7 @@ qemuProcessStartWithMemoryState(virConnectPtr conn, VIR_AUTOCLOSE intermediatefd = -1; g_autoptr(virCommand) cmd = NULL; g_autofree char *errbuf = NULL; + const char *migrateFrom = NULL; int rc = 0; if (data) { @@ -8207,6 +8208,8 @@ qemuProcessStartWithMemoryState(virConnectPtr conn, &errbuf, &cmd) < 0) { return -1; } + + migrateFrom = "stdio"; } /* No cookie means libvirt which saved the domain was too old to mess up @@ -8220,7 +8223,7 @@ qemuProcessStartWithMemoryState(virConnectPtr conn, priv->disableSlirp = true; if (qemuProcessStart(conn, driver, vm, cookie ? cookie->cpu : NULL, - asyncJob, "stdio", *fd, path, snapshot, + asyncJob, migrateFrom, *fd, path, snapshot, VIR_NETDEV_VPORT_PROFILE_OP_RESTORE, start_flags) == 0) *started = true; -- 2.43.0

2 1

[libvirt PATCH v2] scripts/rpcgen: fix 64 unsigned int test on macOS
by Daniel P. Berrangé 30 Nov '23

30 Nov '23

macOS XDR library is an oddball using xdr_u_int64_t instead of xdr_uint64_t which everyone else has. The code generator already does the right thing, but the test program previously generated with the Linux rpcgen program does not compile on macOS due to this. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Changed in v2: - Put compat logic in test_demo.c instead of demo.c, since the latter is liable to be re-generated scripts/rpcgen/tests/test_demo.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/rpcgen/tests/test_demo.c b/scripts/rpcgen/tests/test_demo.c index d6be9e236d..94f1002ac8 100644 --- a/scripts/rpcgen/tests/test_demo.c +++ b/scripts/rpcgen/tests/test_demo.c @@ -3,6 +3,10 @@ #include <rpc/xdr.h> #include <stdbool.h> +#ifdef __APPLE__ +# define xdr_uint64_t xdr_u_int64_t +#endif + #include "demo.h" #include "demo.c" -- 2.41.0

3 9

[libvirt PATCH] scripts/rpcgen: fix 64 unsigned int test on macOS
by Daniel P. Berrangé 30 Nov '23

30 Nov '23

macOS XDR library is an oddball using xdr_u_int64_t instead of xdr_uint64_t which everyone else has. The code generator already does the right thing, but the test program previously generated with the Linux rpcgen program does not compile on macOS due to this. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- scripts/rpcgen/tests/demo.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/rpcgen/tests/demo.c b/scripts/rpcgen/tests/demo.c index 182ed448f0..56a50239dc 100644 --- a/scripts/rpcgen/tests/demo.c +++ b/scripts/rpcgen/tests/demo.c @@ -1,4 +1,8 @@ +#ifdef __APPLE__ +# define xdr_uint64_t xdr_u_int64_t +#endif + void xdr_TestStruct_clear(TestStruct *objp) { xdr_free((xdrproc_t)xdr_TestStruct, (char *)objp); -- 2.41.0

2 4

[libvirt PATCH] rpcgen: Pass 3 arguments to xdrproc_t calls
by Andrea Bolognani 30 Nov '23

30 Nov '23

The test_demo program currently fails to compile on macOS with too few arguments to function call, expected 3, have 2 ret = !!proc(&xdr, vorig); ~~~~ ^ Way back in 2013, commit 9fa3a8ab6fd8 handled this situation for the main library code. Apply the same fix here. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- scripts/rpcgen/tests/test_demo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/rpcgen/tests/test_demo.c b/scripts/rpcgen/tests/test_demo.c index a48ceccd58..931f25f982 100644 --- a/scripts/rpcgen/tests/test_demo.c +++ b/scripts/rpcgen/tests/test_demo.c @@ -22,7 +22,7 @@ static void test_xdr(xdrproc_t proc, void *vorig, void *vnew, const char *testna /* Step 1: serialize the vorig and compare to the data in test .bin files */ xdrmem_create(&xdr, buf, buflen, XDR_ENCODE); - ret = !!proc(&xdr, vorig); + ret = !!proc(&xdr, vorig, 0); g_assert_cmpint(ret, ==, !fail); if (fail) @@ -49,7 +49,7 @@ static void test_xdr(xdrproc_t proc, void *vorig, void *vnew, const char *testna /* Step 2: de-serialize the state to create a new object */ xdrmem_create(&xdr, buf, buflen, XDR_DECODE); - ret = !!proc(&xdr, vnew); + ret = !!proc(&xdr, vnew, 0); g_assert_cmpint(ret, ==, true); actlen = xdr_getpos(&xdr); @@ -63,7 +63,7 @@ static void test_xdr(xdrproc_t proc, void *vorig, void *vnew, const char *testna xdrmem_create(&xdr, buf, buflen, XDR_ENCODE); - ret = !!proc(&xdr, vnew); + ret = !!proc(&xdr, vnew, 0); g_assert_cmpint(ret, ==, true); actlen = xdr_getpos(&xdr); -- 2.43.0

2 1

[libvirt PATCH 0/5] rpcgen: Fix test coverage
by Andrea Bolognani 30 Nov '23

30 Nov '23

Right now we don't have pytest installed in any of the CI build environments, and tests are only executed when pytest is present, so the test coverage is exactly zero. This series changes things so that we actually run the test suite as part of the CI pipeline, which immediately triggers a build failure on macOS: In file included from ../scripts/rpcgen/tests/test_demo.c:7: ../scripts/rpcgen/tests/demo.c:402:10: error: call to undeclared function 'xdr_uint64_t'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] if (!xdr_uint64_t(xdrs, &objp->suh)) ^ ../scripts/rpcgen/tests/test_demo.c:25:29: error: too few arguments to function call, expected 3, have 2 ret = !!proc(&xdr, vorig); ~~~~ ^ ../scripts/rpcgen/tests/test_demo.c:52:28: error: too few arguments to function call, expected 3, have 2 ret = !!proc(&xdr, vnew); ~~~~ ^ ../scripts/rpcgen/tests/test_demo.c:66:28: error: too few arguments to function call, expected 3, have 2 ret = !!proc(&xdr, vnew); ~~~~ ^ 4 errors generated. I haven't looked into that failure at all, but it looks like something that we might want to fix before 9.10.0 is released? libvirt itself seems to build fine, so perhaps it's just the test suite that needs fixing. I leave the call to people who are more familiar with the rpcgen situation. Andrea Bolognani (5): rpcgen: Don't skip all tests when pytest is missing rpcgen: Organize meson tests into suites rpcgen: Skip tests if tests are disabled rpcgen: Reformat meson files ci: Refresh generated files ci/buildenv/almalinux-8.sh | 1 + ci/buildenv/alpine-317.sh | 1 + ci/buildenv/alpine-edge.sh | 1 + ci/buildenv/centos-stream-8.sh | 1 + ci/buildenv/centos-stream-9.sh | 1 + ci/buildenv/debian-11-cross-aarch64.sh | 1 + ci/buildenv/debian-11-cross-armv6l.sh | 1 + ci/buildenv/debian-11-cross-armv7l.sh | 1 + ci/buildenv/debian-11-cross-i686.sh | 1 + ci/buildenv/debian-11-cross-mips64el.sh | 1 + ci/buildenv/debian-11-cross-mipsel.sh | 1 + ci/buildenv/debian-11-cross-ppc64le.sh | 1 + ci/buildenv/debian-11-cross-s390x.sh | 1 + ci/buildenv/debian-11.sh | 1 + ci/buildenv/debian-12-cross-aarch64.sh | 1 + ci/buildenv/debian-12-cross-armv6l.sh | 1 + ci/buildenv/debian-12-cross-armv7l.sh | 1 + ci/buildenv/debian-12-cross-i686.sh | 1 + ci/buildenv/debian-12-cross-mips64el.sh | 1 + ci/buildenv/debian-12-cross-mipsel.sh | 1 + ci/buildenv/debian-12-cross-ppc64le.sh | 1 + ci/buildenv/debian-12-cross-s390x.sh | 1 + ci/buildenv/debian-12.sh | 1 + ci/buildenv/debian-sid-cross-aarch64.sh | 1 + ci/buildenv/debian-sid-cross-armv6l.sh | 1 + ci/buildenv/debian-sid-cross-armv7l.sh | 1 + ci/buildenv/debian-sid-cross-i686.sh | 1 + ci/buildenv/debian-sid-cross-mips64el.sh | 1 + ci/buildenv/debian-sid-cross-ppc64le.sh | 1 + ci/buildenv/debian-sid-cross-s390x.sh | 1 + ci/buildenv/debian-sid.sh | 1 + ci/buildenv/fedora-37.sh | 1 + ci/buildenv/fedora-38-cross-mingw32.sh | 1 + ci/buildenv/fedora-38-cross-mingw64.sh | 1 + ci/buildenv/fedora-38.sh | 1 + ci/buildenv/fedora-rawhide-cross-mingw32.sh | 1 + ci/buildenv/fedora-rawhide-cross-mingw64.sh | 1 + ci/buildenv/fedora-rawhide.sh | 1 + ci/buildenv/opensuse-leap-15.sh | 1 + ci/buildenv/opensuse-tumbleweed.sh | 1 + ci/buildenv/ubuntu-2004.sh | 1 + ci/buildenv/ubuntu-2204.sh | 1 + ci/cirrus/freebsd-12.vars | 2 +- ci/cirrus/freebsd-13.vars | 2 +- ci/cirrus/macos-13.vars | 2 +- ci/cirrus/macos-14.vars | 2 +- ci/containers/almalinux-8.Dockerfile | 1 + ci/containers/alpine-317.Dockerfile | 1 + ci/containers/alpine-edge.Dockerfile | 1 + ci/containers/centos-stream-8.Dockerfile | 1 + ci/containers/centos-stream-9.Dockerfile | 1 + .../debian-11-cross-aarch64.Dockerfile | 1 + .../debian-11-cross-armv6l.Dockerfile | 1 + .../debian-11-cross-armv7l.Dockerfile | 1 + ci/containers/debian-11-cross-i686.Dockerfile | 1 + .../debian-11-cross-mips64el.Dockerfile | 1 + .../debian-11-cross-mipsel.Dockerfile | 1 + .../debian-11-cross-ppc64le.Dockerfile | 1 + .../debian-11-cross-s390x.Dockerfile | 1 + ci/containers/debian-11.Dockerfile | 1 + .../debian-12-cross-aarch64.Dockerfile | 1 + .../debian-12-cross-armv6l.Dockerfile | 1 + .../debian-12-cross-armv7l.Dockerfile | 1 + ci/containers/debian-12-cross-i686.Dockerfile | 1 + .../debian-12-cross-mips64el.Dockerfile | 1 + .../debian-12-cross-mipsel.Dockerfile | 1 + .../debian-12-cross-ppc64le.Dockerfile | 1 + .../debian-12-cross-s390x.Dockerfile | 1 + ci/containers/debian-12.Dockerfile | 1 + .../debian-sid-cross-aarch64.Dockerfile | 1 + .../debian-sid-cross-armv6l.Dockerfile | 1 + .../debian-sid-cross-armv7l.Dockerfile | 1 + .../debian-sid-cross-i686.Dockerfile | 1 + .../debian-sid-cross-mips64el.Dockerfile | 1 + .../debian-sid-cross-ppc64le.Dockerfile | 1 + .../debian-sid-cross-s390x.Dockerfile | 1 + ci/containers/debian-sid.Dockerfile | 1 + ci/containers/fedora-37.Dockerfile | 1 + .../fedora-38-cross-mingw32.Dockerfile | 1 + .../fedora-38-cross-mingw64.Dockerfile | 1 + ci/containers/fedora-38.Dockerfile | 1 + .../fedora-rawhide-cross-mingw32.Dockerfile | 1 + .../fedora-rawhide-cross-mingw64.Dockerfile | 1 + ci/containers/fedora-rawhide.Dockerfile | 1 + ci/containers/opensuse-leap-15.Dockerfile | 1 + ci/containers/opensuse-tumbleweed.Dockerfile | 1 + ci/containers/ubuntu-2004.Dockerfile | 1 + ci/containers/ubuntu-2204.Dockerfile | 1 + scripts/rpcgen/meson.build | 17 ++++++----- scripts/rpcgen/rpcgen/meson.build | 10 +++---- scripts/rpcgen/tests/meson.build | 29 ++++++++++--------- 91 files changed, 118 insertions(+), 30 deletions(-) -- 2.43.0

3 9

[RFC v2: vf-token 0/7] Introduce vf-token when using userspace PF
by Vivek Kashyap 30 Nov '23

30 Nov '23

vf token is set by a vfio-pci based PF driver and it must be known to the vfio-pci based VF driver. This vf-token is set by the PF driver before VF drivers can access the device. vfio-pci driver and qemu support vf-token. This RFC patch series adds support to provide the vf-token (uuid format) in the domain XML and to generate the qemu commandline including the vf-token. To support vf-token the new element will be used as follows: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'> <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/> </address> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </hostdev> The generated commandline will include the following: -device {"driver":"vfio-pci","host":"0000:00:0.1", "vf-token":"00112233-4455-6677-8899-aabbccddeeff", "id":"hostdev0","bus":"pci.0","addr":"0x1"} Changes since initial RFC: 1. Added documentation 2. Added test cases and ran test suite - virtsocketest fails when run with 'ninja test' 3. fixed spaces and uuid string format 4. Used S:vftoken in virJSONValueObjectAdd instead of introducing a conditional Vivek Kashyap (7): virpci: Define vf-token qemu: vf-token capability conf: vf-token flag conf: vf-token parsing and formatting conf: test cases qemu: validate & generate command line doc: doc and news NEWS.rst | 8 +++++ docs/formatdomain.rst | 4 +++ src/conf/device_conf.c | 32 +++++++++++++++-- src/conf/device_conf.h | 3 ++ src/conf/domain_addr.h | 1 + src/conf/domain_conf.c | 8 +++++ src/conf/schemas/basictypes.rng | 7 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 +++++++ src/qemu/qemu_domain_address.c | 3 ++ src/qemu/qemu_validate.c | 20 +++++++++++ src/util/virpci.c | 7 ++++ src/util/virpci.h | 12 +++++++ .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../hostdev-vfio-vf-token.x86_64-latest.args | 34 +++++++++++++++++++ .../hostdev-vfio-vf-token.xml | 22 ++++++++++++ tests/qemuxml2argvtest.c | 1 + 21 files changed, 181 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml -- 2.25.1

2 14

[PATCH 0/4] Support for dirty-limit live migration
by Hyman Huang 30 Nov '23

30 Nov '23

The dirty-limit functionality for live migration was introduced since qemu>=8.1. In the live migration scenario, it implements the force convergence using the dirty-limit approach, which results in better reliable read performance. A straightforward dirty-limit capability for live migration is added by this patchset. Users might not care about other dirty-limit arguments like "x-vcpu-dirty-limit-period" or "vcpu-dirty-limit," thus do not expose them to Libvirt and Keep the default configurations and values in place. For more details about dirty-limit, please see the following reference: https://lore.kernel.org/qemu- devel/169024923116.19090.10825599068950039132-0(a)git.sr.ht/ Hyman Huang (4): Add VIR_MIGRATE_DIRTY_LIMIT flag qemu_migration: Implement VIR_MIGRATE_DIRTY_LIMIT flag virsh: Add support for VIR_MIGRATE_DIRTY_LIMIT flag NEWS: document support for dirty-limit live migration NEWS.rst | 8 ++++++++ docs/manpages/virsh.rst | 10 +++++++++- include/libvirt/libvirt-domain.h | 5 +++++ src/libvirt-domain.c | 8 ++++++++ src/qemu/qemu_migration.c | 8 ++++++++ src/qemu/qemu_migration.h | 1 + src/qemu/qemu_migration_params.c | 6 ++++++ src/qemu/qemu_migration_params.h | 1 + tools/virsh-domain.c | 10 ++++++++++ 9 files changed, 56 insertions(+), 1 deletion(-) -- 2.39.1

1 4

Entering freeze for libvirt-9.10.0
by Jiri Denemark 29 Nov '23

29 Nov '23

I have just tagged v9.10.0-rc1 in the repository and pushed signed tarballs and source RPMs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 1

[PATCH 0/2] rpcgen: tests: Improve on funky platforms
by Michal Privoznik 29 Nov '23

29 Nov '23

At least the second patch should be merged before the release so that Jirka can do the release cleanly. Michal Prívozník (2): rpcgen: tests: Allow running test_demo from anywhere rpcgen: tests: Run cleanly on platforms where char is unsigned scripts/rpcgen/tests/meson.build | 4 +++- scripts/rpcgen/tests/test_demo.c | 4 ++-- .../tests/test_demo_struct_fixed_array.bin | Bin 136 -> 136 bytes .../tests/test_demo_struct_pointer_set.bin | Bin 12 -> 12 bytes .../rpcgen/tests/test_demo_struct_scalar.bin | Bin 8 -> 8 bytes .../test_demo_struct_variable_array_set.bin | Bin 28 -> 28 bytes .../tests/test_demo_test_struct_all_types.bin | Bin 1752 -> 1752 bytes 7 files changed, 5 insertions(+), 3 deletions(-) -- 2.41.0

3 5

[PATCH V5] support for hotplug/hotunplug in test hypervisor
by Thanos Makatos 29 Nov '23

29 Nov '23

Signed-off-by: Thanos Makatos <thanos.makatos(a)nutanix.com> --- Changed since v4: * removed inadvertent calls to functions virNWFilterReadLockFilterUpdates/virNWFilterUnlockFilterUpdates (original patch was based on v8.0.0) --- src/test/test_driver.c | 382 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 380 insertions(+), 2 deletions(-) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index e87d7cfd44..effb7f9880 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -26,8 +26,6 @@ #include <unistd.h> #include <sys/stat.h> #include <libxml/xmlsave.h> - - #include "virerror.h" #include "datatypes.h" #include "test_driver.h" @@ -38,9 +36,12 @@ #include "virnetworkobj.h" #include "interface_conf.h" #include "checkpoint_conf.h" +#include "domain_addr.h" +#include "domain_audit.h" #include "domain_conf.h" #include "domain_driver.h" #include "domain_event.h" +#include "domain_validate.h" #include "network_event.h" #include "snapshot_conf.h" #include "virfdstream.h" @@ -50,6 +51,7 @@ #include "node_device_conf.h" #include "virnodedeviceobj.h" #include "node_device_event.h" +#include "vircgroup.h" #include "virxml.h" #include "virthread.h" #include "virlog.h" @@ -10035,6 +10037,379 @@ testConnectGetDomainCapabilities(virConnectPtr conn G_GNUC_UNUSED, return virDomainCapsFormat(domCaps); } +static int +testDomainAttachHostPCIDevice(testDriver *driver G_GNUC_UNUSED, + virDomainObj *vm, + virDomainHostdevDef *hostdev) +{ + int backend = hostdev->source.subsys.u.pci.backend; + + switch ((virDomainHostdevSubsysPCIBackendType)backend) { + case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO: + case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT: + case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM: + break; + + case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN: + case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST: + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("test hypervisor does not support device assignment mode '%s'"), + virDomainHostdevSubsysPCIBackendTypeToString(backend)); + return -1; + } + + if (!virDomainObjIsActive(vm)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("guest unexpectedly quit during hotplug")); + return -1; + } + + VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1); + + virDomainAuditHostdev(vm, hostdev, "attach", true); + + vm->def->hostdevs[vm->def->nhostdevs++] = hostdev; + + return 0; +} + +static int +testDomainAttachHostDevice(testDriver *driver, + virDomainObj *vm, + virDomainHostdevDef *hostdev) +{ + if (hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("hotplug is not supported for hostdev mode '%s'"), + virDomainHostdevModeTypeToString(hostdev->mode)); + return -1; + } + + if (hostdev->source.subsys.type != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("hotplug is not supported for hostdev subsys type '%s'"), + virDomainHostdevSubsysTypeToString(hostdev->source.subsys.type)); + return -1; + } + + return testDomainAttachHostPCIDevice(driver, vm, hostdev); +} + +static int +testDomainAttachDeviceLive(virDomainObj *vm, + virDomainDeviceDef *dev, + testDriver *driver) +{ + int ret = -1; + const char *alias = NULL; + + if ((virDomainDeviceType)dev->type != VIR_DOMAIN_DEVICE_HOSTDEV) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("live attach of device '%s' is not supported"), + virDomainDeviceTypeToString(dev->type)); + return -1; + } + + testDomainObjCheckHostdevTaint(vm, dev->data.hostdev); + if ((ret = testDomainAttachHostDevice(driver, vm, dev->data.hostdev)) != 0) + return ret; + + alias = dev->data.hostdev->info->alias; + dev->data.hostdev = NULL; + + if (alias) { + virObjectEvent *event; + event = virDomainEventDeviceAddedNewFromObj(vm, alias); + virObjectEventStateQueue(driver->eventState, event); + } + + return 0; +} + +static int +testDomainAttachDeviceLiveAndConfig(virDomainObj *vm, + testDriver *driver, + const char *xml, + unsigned int flags) +{ + g_autoptr(virDomainDeviceDef) devConf = NULL; + g_autoptr(virDomainDeviceDef) devLive = NULL; + unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE | + VIR_DOMAIN_DEF_PARSE_ABI_UPDATE; + + virCheckFlags(VIR_DOMAIN_AFFECT_LIVE, -1); + + if (flags & VIR_DOMAIN_AFFECT_LIVE) { + if (!(devLive = virDomainDeviceDefParse(xml, vm->def, + driver->xmlopt, NULL, + parse_flags))) + return -1; + + if (virDomainDeviceValidateAliasForHotplug(vm, devLive, + VIR_DOMAIN_AFFECT_LIVE) < 0) + return -1; + + if (virDomainDefCompatibleDevice(vm->def, devLive, NULL, + VIR_DOMAIN_DEVICE_ACTION_ATTACH, + true) < 0) + return -1; + + if (testDomainAttachDeviceLive(vm, devLive, driver) < 0) + return -1; + } + + return 0; +} + +static int +testDomainAttachDeviceFlags(virDomainPtr domain, + const char *xml, + unsigned int flags) { + + testDriver *driver = domain->conn->privateData; + virDomainObj *vm = NULL; + int ret = -1; + + if (!(vm = testDomObjFromDomain(domain))) + return -1; + + if (virDomainObjUpdateModificationImpact(vm, &flags) < 0) + goto cleanup; + + if (testDomainAttachDeviceLiveAndConfig(vm, driver, xml, flags) < 0) + goto cleanup; + + ret = 0; + + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + +static int +testDomainAttachDevice(virDomainPtr domain, const char *xml) +{ + return testDomainAttachDeviceFlags(domain, xml, 0); +} + +/* search for a hostdev matching dev and detach it */ +static int +testDomainDetachPrepHostdev(virDomainObj *vm, + virDomainHostdevDef *match, + virDomainHostdevDef **detach) +{ + virDomainHostdevSubsys *subsys = &match->source.subsys; + virDomainHostdevSubsysPCI *pcisrc = &subsys->u.pci; + virDomainHostdevDef *hostdev = NULL; + + if (match->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("hot unplug is not supported for hostdev mode '%s'"), + virDomainHostdevModeTypeToString(match->mode)); + return -1; + } + + if (virDomainHostdevFind(vm->def, match, &hostdev) < 0) { + if (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI) { + virReportError(VIR_ERR_DEVICE_MISSING, + _("host pci device " VIR_PCI_DEVICE_ADDRESS_FMT + " not found"), + pcisrc->addr.domain, pcisrc->addr.bus, + pcisrc->addr.slot, pcisrc->addr.function); + } else { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("unexpected hostdev type %d"), subsys->type); + } + return -1; + } + + *detach = hostdev; + + return 0; +} + +static int +testDomainRemoveHostDevice(testDriver *driver G_GNUC_UNUSED, + virDomainObj *vm, + virDomainHostdevDef *hostdev) +{ + virDomainNetDef *net = NULL; + size_t i; + + VIR_DEBUG("Removing host device %s from domain %p %s", + hostdev->info->alias, vm, vm->def->name); + + if (hostdev->parentnet) { + net = hostdev->parentnet; + for (i = 0; i < vm->def->nnets; i++) { + if (vm->def->nets[i] == hostdev->parentnet) { + virDomainNetRemove(vm->def, i); + break; + } + } + } + + for (i = 0; i < vm->def->nhostdevs; i++) { + if (vm->def->hostdevs[i] == hostdev) { + virDomainHostdevRemove(vm->def, i); + break; + } + } + + virDomainAuditHostdev(vm, hostdev, "detach", true); + + virDomainHostdevDefFree(hostdev); + + if (net) { + if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) { + g_autoptr(virConnect) conn = virGetConnectNetwork(); + if (conn) + virDomainNetReleaseActualDevice(conn, vm->def, net); + else + VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname)); + } + virDomainNetDefFree(net); + } + + return 0; +} + +static int +testDomainRemoveDevice(testDriver *driver, + virDomainObj *vm, + virDomainDeviceDef *dev) +{ + virDomainDeviceInfo *info; + virObjectEvent *event; + g_autofree char *alias = NULL; + + /* + * save the alias to use when sending a DEVICE_REMOVED event after + * all other teardown is complete + */ + if ((info = virDomainDeviceGetInfo(dev))) + alias = g_strdup(info->alias); + info = NULL; + + if ((virDomainDeviceType)dev->type != VIR_DOMAIN_DEVICE_HOSTDEV) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("don't know how to remove a %s device"), + virDomainDeviceTypeToString(dev->type)); + goto out; + } + + if (testDomainRemoveHostDevice(driver, vm, dev->data.hostdev) < 0) + return -1; + +out: + event = virDomainEventDeviceRemovedNewFromObj(vm, alias); + virObjectEventStateQueue(driver->eventState, event); + + return 0; +} + +static int +testDomainDetachDeviceLive(virDomainObj *vm, + virDomainDeviceDef *match, + testDriver *driver) +{ + virDomainDeviceDef detach = { .type = match->type }; + virDomainDeviceInfo *info = NULL; + + if ((virDomainDeviceType)match->type != VIR_DOMAIN_DEVICE_HOSTDEV) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("live detach of device '%s' is not supported"), + virDomainDeviceTypeToString(match->type)); + return -1; + } + + if (testDomainDetachPrepHostdev(vm, match->data.hostdev, + &detach.data.hostdev) < 0) + return -1; + + /* "detach" now points to the actual device we want to detach */ + + if (!(info = virDomainDeviceGetInfo(&detach))) { + /* + * This should never happen, since all of the device types in + * the switch cases that end with a "break" instead of a + * return have a virDeviceInfo in them. + */ + virReportError(VIR_ERR_INTERNAL_ERROR, + _("device of type '%s' has no device info"), + virDomainDeviceTypeToString(detach.type)); + return -1; + } + + /* Make generic validation checks common to all device types */ + + if (!info->alias) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Cannot detach %s device with no alias"), + virDomainDeviceTypeToString(detach.type)); + return -1; + } + + return testDomainRemoveDevice(driver, vm, &detach); +} + +static int +testDomainDetachDeviceAliasLiveAndConfig(testDriver *driver, + virDomainObj *vm, + const char *alias, + unsigned int flags) +{ + virDomainDef *def = NULL; + g_autoptr(virDomainDef) vmdef = NULL; + + virCheckFlags(VIR_DOMAIN_AFFECT_LIVE, -1); + + if (virDomainObjGetDefs(vm, flags, &def, NULL) < 0) + return -1; + + if (def) { + virDomainDeviceDef dev; + + if (virDomainDefFindDevice(def, alias, &dev, true) < 0) + return -1; + + if (testDomainDetachDeviceLive(vm, &dev, driver) < 0) + return -1; + } + + if (vmdef) { + if (virDomainDefSave(vmdef, driver->xmlopt, NULL) < 0) + return -1; + virDomainObjAssignDef(vm, &vmdef, false, NULL); + } + + return 0; +} + +static int +testDomainDetachDeviceAlias(virDomainPtr dom, + const char *alias, + unsigned int flags) +{ + testDriver *driver = dom->conn->privateData; + virDomainObj *vm = NULL; + int ret = -1; + + if (!(vm = testDomObjFromDomain(dom))) + return -1; + + if (virDomainObjUpdateModificationImpact(vm, &flags) < 0) + goto cleanup; + + if (testDomainDetachDeviceAliasLiveAndConfig(driver, vm, alias, flags) < 0) + goto cleanup; + + ret = 0; + + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} /* * Test driver @@ -10058,6 +10433,9 @@ static virHypervisorDriver testHypervisorDriver = { .connectListDomains = testConnectListDomains, /* 0.1.1 */ .connectNumOfDomains = testConnectNumOfDomains, /* 0.1.1 */ .connectListAllDomains = testConnectListAllDomains, /* 0.9.13 */ + .domainAttachDevice = testDomainAttachDevice, /* 9.10.0 */ + .domainAttachDeviceFlags = testDomainAttachDeviceFlags, /* 9.10.0 */ + .domainDetachDeviceAlias = testDomainDetachDeviceAlias, /* 9.10.0 */ .domainCreateXML = testDomainCreateXML, /* 0.1.4 */ .domainCreateXMLWithFiles = testDomainCreateXMLWithFiles, /* 5.7.0 */ .domainLookupByID = testDomainLookupByID, /* 0.1.1 */ -- 2.27.0

2 3

[PATCH] qemu_driver: Don't handle the EOF event if monitor changed
by Guoyi Tu 29 Nov '23

29 Nov '23

Currently, libvirt creates a thread pool with only on thread to handle all qemu monitor events for virtual machines, In the cases that if the thread gets stuck while handling a monitor EOF event, such as unable to kill the virtual machine process or release resources, the events of other virtual machine will be also blocked, which will lead to the abnormal behavior of other virtual machines. For instance, when another virtual machine completes a shutdown operation and the monitor EOF event has been queued but remains unprocessed, we immediately destroy and start the virtual machine again, at a later time when EOF event get processed, the processMonitorEOFEvent() will kill the virtual machine that just started. To address this issue, in the processMonitorEOFEvent(), we check whether the current virtual machine's monitor object matches the one at the time the event was generated. If they do not match, we immediately return. Signed-off-by: Guoyi Tu <tugy(a)chinatelecom.cn> Signed-off-by: dengpengcheng <dengpc12(a)chinatelecom.cn> --- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 11 +++++++++-- src/qemu/qemu_process.c | 2 +- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index ae19ce884b..bc80afdfac 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11500,7 +11500,6 @@ qemuProcessEventFree(struct qemuProcessEvent *event) case QEMU_PROCESS_EVENT_NETDEV_STREAM_DISCONNECTED: case QEMU_PROCESS_EVENT_NIC_RX_FILTER_CHANGED: case QEMU_PROCESS_EVENT_SERIAL_CHANGED: - case QEMU_PROCESS_EVENT_MONITOR_EOF: case QEMU_PROCESS_EVENT_GUEST_CRASHLOADED: g_free(event->data); break; @@ -11514,6 +11513,7 @@ qemuProcessEventFree(struct qemuProcessEvent *event) case QEMU_PROCESS_EVENT_UNATTENDED_MIGRATION: case QEMU_PROCESS_EVENT_RESET: case QEMU_PROCESS_EVENT_NBDKIT_EXITED: + case QEMU_PROCESS_EVENT_MONITOR_EOF: case QEMU_PROCESS_EVENT_LAST: break; } diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d00d2a27c6..57acafb48b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3854,7 +3854,8 @@ processJobStatusChangeEvent(virDomainObj *vm, static void processMonitorEOFEvent(virQEMUDriver *driver, - virDomainObj *vm) + virDomainObj *vm, + qemuMonitor *mon) { qemuDomainObjPrivate *priv = vm->privateData; int eventReason = VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN; @@ -3863,6 +3864,12 @@ processMonitorEOFEvent(virQEMUDriver *driver, unsigned int stopFlags = 0; virObjectEvent *event = NULL; + if (priv->mon != mon) { + VIR_DEBUG("Domain %p '%s' has been shutdown, ignoring EOF", + vm, vm->def->name); + return; + } + if (qemuProcessBeginStopJob(vm, VIR_JOB_DESTROY, true) < 0) return; @@ -4082,7 +4089,7 @@ static void qemuProcessEventHandler(void *data, void *opaque) processJobStatusChangeEvent(vm, processEvent->data); break; case QEMU_PROCESS_EVENT_MONITOR_EOF: - processMonitorEOFEvent(driver, vm); + processMonitorEOFEvent(driver, vm, processEvent->data); break; case QEMU_PROCESS_EVENT_PR_DISCONNECT: processPRDisconnectEvent(vm); diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index b9267d8699..4de6e5c234 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -316,7 +316,7 @@ qemuProcessHandleMonitorEOF(qemuMonitor *mon, } qemuProcessEventSubmit(vm, QEMU_PROCESS_EVENT_MONITOR_EOF, - 0, 0, NULL); + 0, 0, priv->mon); /* We don't want this EOF handler to be called over and over while the * thread is waiting for a job. -- 2.17.1

2 2

[libvirt PATCH] rpm: Drop rpcgen Build-Requires once again
by Andrea Bolognani 28 Nov '23

28 Nov '23

We no longer use it, so commit a62486b95fee correctly dropped the Build-Requires; shortly afterwards, however, I accidentally re-introduced it by mistake. Fixes: 3df8cc658ed0ac2f84089ad0db61ba20eb8b8aa7 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- libvirt.spec.in | 1 - 1 file changed, 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 361a34675b..f3fdedfde4 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -313,7 +313,6 @@ BuildRequires: libxml2 BuildRequires: libxslt BuildRequires: gettext BuildRequires: systemd-rpm-macros -BuildRequires: rpcgen # Fedora build root suckage BuildRequires: gawk %if %{with_native} -- 2.43.0

2 1

[PATCH 0/4] A bunch of trivial fixes
by Michal Privoznik 28 Nov '23

28 Nov '23

*** BLURB HERE *** Michal Prívozník (4): virpci: Decrease scope of VIR_PF_PHYS_PORT_NAME_REGEX macro qemu_command: Don't open code virPCIDeviceAddressAsString() vircpi: Decrease scope of VIR_PCI_DEVICE_ADDRESS_FMT macro ch: Don't leak ch_driver->chCaps src/ch/ch_driver.c | 5 +++-- src/qemu/qemu_command.c | 6 +----- src/util/virpci.c | 9 +++++++++ src/util/virpci.h | 7 ------- 4 files changed, 13 insertions(+), 14 deletions(-) -- 2.41.0

5 10

[Call for Presentations] FOSDEM 2024: Virt & IaaS Devroom
by Kashyap Chamarthy 28 Nov '23

28 Nov '23

[Cross-posted to KVM, Rust-VMM, QEMU, and libvirt lists) Hi, the CFP for the "Virt & IaaS" DevRoom is out[+]. Something new this year is a new talk-submission system: so you need to create a new account, even if you've had an account with the older talk-submission system. Details in the "Submit Your Proposal" section below. ======================================================================== We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2024, to be hosted on February 3rd 2024. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 8th, 2023. Important Dates --------------- Submission deadline: 8th December 2023 Acceptance notifications: 10th December 2023 Final schedule announcement: 15th December 2023 Devroom: 3rd February 2024 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pretalx event planning site[1]. It is a new submission system so you will need to create an account. If you submitted proposals for FOSDEM in previous years, you won’t be able to use your existing account. During submission please make sure to select Virtualization and Cloud infrastructure from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list[2]. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://pretalx.fosdem.org/fosdem-2024/cfp [2] virtualization-devroom-manager at fosdem.org ======================================================================= [+] This email is a slightly formatted version of the official announce: https://lists.fosdem.org/pipermail/fosdem/2023q4/003481.html -- /kashyap

1 0

Re: [libvirt RFCv11 00/33] multifd save restore prototype
by Claudio Fontana 27 Nov '23

27 Nov '23

On 11/27/23 11:18, Daniel P. Berrangé wrote: > On Mon, Nov 27, 2023 at 10:43:58AM +0100, Claudio Fontana wrote: >> Hi all, >> >> I understand there has been some movement in this topic as the fixed-offset ram and multifd code evolves. >> >> I think I understood that now the idea is to pass from libvirt to QEMU two file descriptors, >> one for writing metadata, >> and a separate one for the actual memory pages, which is the one that can potentially be O_DIRECT. > > We determined that O_DIRECT changes propagate across dup'd file > descriptors, so we have only two choices > > * 1 FD, and QEMU has to take care to toggle O_DIRECT on/off > repeatedly depending on what phase it is in > * 2 FDs, one with and one without O_DIRECT > > Either is viable for libvirt. I have a mild preference for having > 1 FD, but not enough to call it a design blocker. So at the > discretion of whomever implements the QEMU part. > >> 1) I would assume that libvirt would then need to check if the user requested --parallel / --parallel-connections to enable QEMU multifd. > > Yes > >> 2) I would also assume that libvirt would check the presence of --bypass-cache as the condition to set O_DIRECT on the second (memory pages fd), and to enable QEMU "io-direct" feature. > > Yes > >> 3) I would tentatively suggest that when it comes to fixed-ram-offset, the condition to enable that one is a check like the one currently in libvirt: >> >> src/util/virfile.c::virFileDiskCopy() >> >> ie checking that we are writing to a seekable file that is not S_ISBLK . >> >> Does this match your understanding/reasoning? > > Both the io-direct and fixed-ram-offset features are dependent on > new QEMU impls, so there is a mild backwards compatibility concern. > > ie, lets say if we are running QEMU 9.0.0, but with old machine > type pc-i440fx-8.0.0, and we save the state, but want to then > restore with QEMU 8.2.0. > > Essentially we must NOT use io-direct/fixed-ram-offset if we > want the ability to migrate to older QEMU. At the same time I > would like us to be able to take advantage of this new QEMU > support to the greatest extent possible, even if not doing the > --parallel stuff which was the original motivator. > > Thus, we need some way to decide whether to use the new or the > old on disk format. > > I wonder if having a setting in '/etc/libvirt/qemu.conf' is > sufficient, or whether we must expose a flag via the API. > > With regards, > Daniel Thanks Daniel, that's an interesting point. The new fixed-ram-offset format is a QEMU format, and as such I presume that in theory there is a qemu_saveimage.h:#define QEMU_SAVE_VERSION 2 that could be bumped to 3 if this new format is used? But then again, libvirt would need to decide whether to save in "old QEMU compatibility mode" or in the new QEMU_SAVE_VERSION 3 mode that allows for fixed-ram-offset. Maybe a new libvirt option for controlling which QEMU_SAVE_VERSION format to use for the save, with the default being v2 for backward compatibility reasons? Thanks, Claudio

2 2

Re: [kubevirt-dev] ANNOUNCE: Virtualization linting library
by Michal Prívozník 27 Nov '23

27 Nov '23

[Following move of libvir-list to new location] On 11/15/23 09:26, Dan Kenigsberg wrote: > Thanks, Michal, for this overture. I think libvirt and its people have a > lot of knowledge about working-yet-not-recommended configurations that > can be beneficial to higher-level management systems such as KubeVirt. Indeed. But writing checks for such configurations should be trivial enough, now that they can be written in Lua. But individual checks are technicality, those can and will be extended once we know current (API) design works for KubeVirt. > > How do you envisage it to be used by KubeVirt? > > Do you think virt-launcher can call it before it is calling > virCreateXML()? If so, would it make sense to bubble up its warnings as > VM.status conditions? Yes, that's my idea. Once KubeVirt constructed domain XML, it can feed it to virt-lint tool. From that it'll receive bunch of warnings (or none if domain XML is okay) which could be then forwarded to the UI for users to resolve. Or ignore and continue starting up the guest (for instance, one of currently implemented checks is for enough of free PCIe root ports for future hotplug - it's up to user to tell if they will ever want hotplug). > > BTW, I think it may be valuable to add a machine-accessible code for > each warning, on top of the English language text. Good point. That way we can save user's preference on ignoring some warnings. Or have KubeVirt fix some of the warnings automagically. Anyway, my knowledge of KubeVirt internals is not intimate enough to even attempt to integrate this. If anybody from KubeVirt developers is willing to offer a helping hand, I'd appreciate it. Michal

1 0

[PATCH v2 0/3] Introduce pipewire audio backend
by Michal Privoznik 24 Nov '23

24 Nov '23

v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4M7O… diff to v1: - Introduced 'runtimeDir' attribute to <audio/> so that users do not have use <qemu:env/> hack to set PIPEWIRE_RUNTIME_DIR. - Worked in the rest of Peter's review suggestions. Michal Prívozník (3): conf: Introduce pipewire audio backend qemu: Generate cmd line for pipewire audio backend NEWS: Document pipewire audio backend NEWS.rst | 5 ++ docs/formatdomain.rst | 46 +++++++++++- src/conf/domain_conf.c | 73 +++++++++++++++++++ src/conf/domain_conf.h | 13 ++++ src/conf/schemas/domaincommon.rng | 42 +++++++++++ src/qemu/qemu_command.c | 71 ++++++++++++++++++ src/qemu/qemu_validate.c | 1 + .../audio-many-backends.x86_64-latest.args | 2 + .../qemuxml2argvdata/audio-many-backends.xml | 1 + .../audio-pipewire-best.x86_64-latest.args | 36 +++++++++ .../qemuxml2argvdata/audio-pipewire-best.xml | 43 +++++++++++ .../audio-pipewire-full.x86_64-latest.args | 36 +++++++++ .../qemuxml2argvdata/audio-pipewire-full.xml | 43 +++++++++++ .../audio-pipewire-minimal.x86_64-latest.args | 36 +++++++++ .../audio-pipewire-minimal.xml | 36 +++++++++ tests/qemuxml2argvtest.c | 10 +++ .../audio-many-backends.x86_64-latest.xml | 1 + .../audio-pipewire-best.x86_64-latest.xml | 46 ++++++++++++ .../audio-pipewire-full.x86_64-latest.xml | 46 ++++++++++++ .../audio-pipewire-minimal.x86_64-latest.xml | 39 ++++++++++ tests/qemuxml2xmltest.c | 3 + 21 files changed, 627 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/audio-pipewire-best.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/audio-pipewire-best.xml create mode 100644 tests/qemuxml2argvdata/audio-pipewire-full.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/audio-pipewire-full.xml create mode 100644 tests/qemuxml2argvdata/audio-pipewire-minimal.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/audio-pipewire-minimal.xml create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-best.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-full.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-minimal.x86_64-latest.xml -- 2.41.0

2 5