November 2025 - Devel - libvirt List Archives

[PATCH v2] spec: Fix 'libvirt-daemon-driver-storage-zfs' on Fedora 43 and newer
by Peter Krempa 24 Nov '25

24 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit bd30147e740 added an 'Obsoletes' directive so that the storage driver core package will update properly but hardcoded the obsoleted version as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd packages and disabled the build. Now it is still possible to obtain ZFS support from other means and it may be useful for users to have libvirt's ZFS backend. This patch thus: - re-enables build of 'libvirt-daemon-driver-storage-zfs' on Fedora - removes 'libvirt-daemon-driver-storage-zfs' as 'Requires dependency from 'daemon-driver-storage' meta-package on Fedora 43 and newer With this the package still is built and installable but will require users to get their ZFS support installed somehow. Fixes: bd30147e740d49fdb5844160e480ca34611f75e5 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- libvirt.spec.in | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) I originally thought that the 'Requires' dependancy requiring /sbin/zpool and /sbin/zfs would need to be dropped but even without 'zfs-fuse' on F43 it builds fine. diff --git a/libvirt.spec.in b/libvirt.spec.in index 8314fbeb34..1bfe7d715b 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -76,8 +76,10 @@ %define with_storage_gluster 0 %endif -# Fedora had zfs-fuse until F43 -%if 0%{?fedora} && 0%{?fedora} < 43 +# On Fedora 43, the 'zfs-fuse' package was removed, but is obtainable via +# other means. Build the backend, but it's no longer considered to be part +# of 'daemon-driver-storage'. +%if 0%{?fedora} %define with_storage_zfs 0%{!?_without_storage_zfs:1} %else %define with_storage_zfs 0 @@ -667,9 +669,6 @@ Requires: /usr/bin/qemu-img Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0 %endif Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0 - %if !%{with_storage_zfs} -Obsoletes: libvirt-daemon-driver-storage-zfs < 11.4.0 - %endif %description daemon-driver-storage-core The storage driver plugin for the libvirtd daemon, providing @@ -796,7 +795,10 @@ Requires: libvirt-daemon-driver-storage-gluster = %{version}-%{release} %if %{with_storage_rbd} Requires: libvirt-daemon-driver-storage-rbd = %{version}-%{release} %endif - %if %{with_storage_zfs} +# Starting with Fedora 43 the 'zfs-fuse' is no longer shipped but obtainable +# externally. We do not want to install this as part of 'daemon-driver-storage' +# any more. + %if %{with_storage_zfs} && 0%{?fedora} && 0%{?fedora} < 43 Requires: libvirt-daemon-driver-storage-zfs = %{version}-%{release} %endif -- 2.51.1

2 1

[RFC PATCH v7 0/3] Fix virtio console port assignment issue
by Aaron M. Brown 24 Nov '25

24 Nov '25

Changelog: --- v7: - Removed some unnecessary definitions from test xml - Moved edge case reservation logic to virDomainVirtioSerialAddrAssign --- v6: - Fixed issue with console auto port index starting from 1 instead of 0 --- v5: - Added xml tests to tests/qemuxmlconfdata - Fixed virito -> virtio typo in commit message --- v4: - Update commit messages --- v3: - Added Reviewed-By - Included CI Results Link --- v2: - Split patch into two commits - Added fixes tag --- This libvirt patch series does the following: 1. fixes an issue with virtio console device port auto assignment on virtio-serial buses 2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity 3. Adds tests for virtio console on the vioserial bus Currently in libvirt, a virtio console device cannot be auto assigned a port number greater than zero on a virtio-serial bus. This leads to port collision errors when adding more than 1 virtio console device on a single virtio-serial bus. After applying this patch, one can add multiple console ports under a single virtio-serial bus. Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/2047914492 Aaron M. Brown (3): tests: Add console-virtio-serial-autoassign-address tests domain_addr.c: Fix virtio console port autoassign on virtio-serial bus domain_addr.c: update virtconsole port reservation comment and allowZero var src/conf/domain_addr.c | 51 +++++++++++++----- ...rial-autoassign-address.x86_64-latest.args | 42 +++++++++++++++ ...erial-autoassign-address.x86_64-latest.xml | 54 +++++++++++++++++++ ...nsole-virtio-serial-autoassign-address.xml | 40 ++++++++++++++ tests/qemuxmlconftest.c | 1 + 5 files changed, 175 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.xml -- 2.39.5 (Apple Git-154)

4 10

[PATCH v2 0/3] qemu: fix capabilities reporting for TDX
by Daniel P. Berrangé 24 Nov '25

24 Nov '25

The capabilities reporting merged for TDX was flawed because it would always report TDX as supported simply if QEMU was new enough to have 'tdx-guest'. Unfortunately the 'query-tdx-capabilities' QMP command that was in early postings: https://mail.gnu.org/archive/html/qemu-devel/2021-07/msg01689.html went missing and I'm not seeing an alternative way to query QEMU to see if TDX is actually launchable. So in these patches I open /dev/kvm and directly ask of the 'TDX' VM type is supported by KVM, which IIUC is equivalent to waht the original 'query-tdx-capabilities' patch was doing. In v2: * Unconditionally report TDX on all arches * Also unconditionally report s390 prot-virt on all arches * Use VIR_AUTOCLOSE * Sanity check ioctl return status < 0 * Remove dead error reporting paths * Add missing ioctl.h header include Daniel P. Berrangé (3): qemu: correctly detect working TDX support qemu: always report TDX feature caps on x86 qemu: always report s390 prot-virt feature in domain caps src/qemu/qemu_capabilities.c | 70 ++++++++++++++++--- src/qemu/qemu_capabilities.h | 3 + .../qemu_10.0.0-q35.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 2 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 2 + .../qemu_10.0.0-virt.aarch64.xml | 2 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 2 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 2 + .../qemu_10.1.0-q35.x86_64+inteltdx.xml | 1 + .../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 1 + .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 2 + .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 2 + .../qemu_10.1.0.x86_64+inteltdx.xml | 1 + tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 1 + .../qemu_10.2.0-q35.x86_64+mshv.xml | 1 + .../domaincapsdata/qemu_10.2.0-q35.x86_64.xml | 1 + .../qemu_10.2.0-tcg.x86_64+mshv.xml | 2 + .../domaincapsdata/qemu_10.2.0-tcg.x86_64.xml | 2 + .../qemu_10.2.0.x86_64+mshv.xml | 1 + tests/domaincapsdata/qemu_10.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 2 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 2 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 2 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 2 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 2 + .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 2 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 2 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_8.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 2 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 2 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 2 + .../qemu_8.2.0-virt.aarch64.xml | 2 + .../qemu_8.2.0-virt.loongarch64.xml | 2 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_9.0.0.sparc.xml | 2 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 2 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 2 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 2 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 2 + .../qemu_9.1.0-virt.riscv64.xml | 2 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 2 + .../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 2 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 2 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 2 + tests/domaincapsmock.c | 6 ++ 77 files changed, 205 insertions(+), 9 deletions(-) -- 2.51.1

2 7

[PATCH v1 0/4] s390x CPU Models: Fix deprecated_features='on'
by Collin Walling 24 Nov '25

24 Nov '25

Currently, when setting the deprecated_features attribute to 'on', all known deprecated features will be enabled for the CPU model, including ones that are *not* supported by the model. These patches query an additional set of deprecated features by performing a CPU model expansion on host-model with type "static". The list of deprecated features reported from this command will reflect features that may be enabled on the model without error. Now, when a user specifies deprecated_features='on' in the domain XML, only the features that are still supported by the model are requested to be turned on for the guest. This can be helpful for e.g. tests that may wish to check CPU model compatability in certain environments. Collin Walling (4): qemu: rename modelinfo's deprecated_props to full_dep_props qemu: refactor load/format of deprecated features qemu: query and cache static/host deprecated features qemu: only allow enabling deprecated features that are supported src/qemu/qemu_capabilities.c | 106 ++++++++++++------ src/qemu/qemu_monitor.c | 6 +- src/qemu/qemu_monitor.h | 3 +- src/qemu/qemu_monitor_json.c | 17 ++- .../caps_10.0.0_s390x.xml | 6 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 6 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 6 + 7 files changed, 112 insertions(+), 38 deletions(-) -- 2.51.1

3 9

[PATCH] spec: Fix 'obsoletes' for 'libvirt-daemon-driver-storage-zfs'
by Peter Krempa 24 Nov '25

24 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit bd30147e740 added an 'Obsoletes' directive so that the storage driver core package will update properly but hardcoded the obsoleted version as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd packages. Unfortunately that doesn't work if the sub-package removal happened based on an external dependancy, rather than complete removal of said module in libvirt. If users have e.g. virt-preview repos enabled they'll get libvirt-11.9 currently installed, but the obsoleted version is just 11.4, thus upgrades to Fedora 43 with virt-preview are broken. Fix this by obsoleting everything up to the current build. Fixes: bd30147e740d49fdb5844160e480ca34611f75e5 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 8314fbeb34..f1bfd5e652 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -668,7 +668,7 @@ Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0 %endif Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0 %if !%{with_storage_zfs} -Obsoletes: libvirt-daemon-driver-storage-zfs < 11.4.0 +Obsoletes: libvirt-daemon-driver-storage-zfs <= %{version}-%{release} %endif %description daemon-driver-storage-core -- 2.51.1

3 7

[PATCH] src: cap the data size in stream I/O functions
by Daniel P. Berrangé 24 Nov '25

24 Nov '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The main stream I/O functions have a design flaw in that they accept 'size_t' as the input data length, while intending to return the amount actually processed in an 'int'. Fortunately all functions explicitly document that less data may be processed than requested, and with the remote driver data cap we will never get anywhere near exceeding an 'int' even on 32-bit. For sanity, however, lets explicitly cap the data size in the public API to fix the design flaw. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/libvirt-stream.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/src/libvirt-stream.c b/src/libvirt-stream.c index ca4d90140e..61c700c19e 100644 --- a/src/libvirt-stream.c +++ b/src/libvirt-stream.c @@ -182,6 +182,15 @@ virStreamSend(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes = G_MAXINT32; + } + if (stream->driver && stream->driver->streamSend) { int ret; @@ -279,6 +288,15 @@ virStreamRecv(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes = G_MAXINT32; + } + if (stream->driver && stream->driver->streamRecv) { int ret; @@ -370,6 +388,15 @@ virStreamRecvFlags(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes = G_MAXINT32; + } + if (stream->driver && stream->driver->streamRecvFlags) { int ret; -- 2.51.1

2 1

[PATCH] include: fix version for recent block stats constants
by Daniel P. Berrangé 24 Nov '25

24 Nov '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The recent commit: commit 166be0d48cedb8def6085bd10ede4b1875eb2ceb Author: Peter Krempa <pkrempa(a)redhat.com> AuthorDate: Fri Sep 12 13:32:36 2025 +0200 Commit: Peter Krempa <pkrempa(a)redhat.com> CommitDate: Wed Nov 5 14:27:57 2025 +0100 Expose qemu timed block statistics via bulk stats API had a bit of delay between authoring and merging, such that the merged version number was outdated. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- include/libvirt/libvirt-domain.h | 60 ++++++++++++++++---------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 56bd085ef5..e16c1925cd 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -3497,7 +3497,7 @@ struct _virDomainStatsRecord { * Alignment requirement, in bytes, for offset/length of I/O requests, as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_REQUEST_ALIGNMENT ".limits.request_alignment" @@ -3509,7 +3509,7 @@ struct _virDomainStatsRecord { * * Maximum number of bytes that can be discarded at once, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_DISCARD_MAX ".limits.discard_max" @@ -3521,7 +3521,7 @@ struct _virDomainStatsRecord { * * Optimal alignment for discard requests in bytes, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_DISCARD_ALIGNMENT ".limits.discard_alignment" @@ -3533,7 +3533,7 @@ struct _virDomainStatsRecord { * * Maximum number of bytes that can be zeroed out at once, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_WRITE_ZEROES_MAX ".limits.write_zeroes_max" @@ -3545,7 +3545,7 @@ struct _virDomainStatsRecord { * * Optimal alignment for write_zeroes requests in bytes, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_WRITE_ZEROES_ALIGNMENT ".limits.write_zeroes_alignment" @@ -3557,7 +3557,7 @@ struct _virDomainStatsRecord { * * Optimal transfer length in bytes, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_TRANSFER_OPTIMAL ".limits.transfer_optimal" @@ -3569,7 +3569,7 @@ struct _virDomainStatsRecord { * * Maximal transfer length in bytes, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_TRANSFER_MAX ".limits.transfer_max" @@ -3582,7 +3582,7 @@ struct _virDomainStatsRecord { * Maximal hardware transfer length of requests bypassing kernel IO scheduler * in bytes, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_TRANSFER_HW_MAX ".limits.transfer_hw_max" @@ -3594,7 +3594,7 @@ struct _virDomainStatsRecord { * * Maximum number of scatter/gather elements, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_IOV_MAX ".limits.iov_max" @@ -3607,7 +3607,7 @@ struct _virDomainStatsRecord { * Maximal number of scatter/gather elements of requests bypassing kernel IO * scheduler, as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_IOV_HW_MAX ".limits.iov_hw_max" @@ -3620,7 +3620,7 @@ struct _virDomainStatsRecord { * memory alignment in bytes so that no bounce buffer is needed, as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_MEMORY_ALIGNMENT_MINIMAL ".limits.memory_alignment_minimal" @@ -3633,7 +3633,7 @@ struct _virDomainStatsRecord { * memory alignment in bytes that is used for bounce buffers, as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_LIMITS_MEMORY_ALIGNMENT_OPTIMAL ".limits.memory_alignment_optimal" @@ -3643,7 +3643,7 @@ struct _virDomainStatsRecord { * Number of groups of statistics accounted in a configured time intervals as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_COUNT ".timed_group.count" @@ -3654,7 +3654,7 @@ struct _virDomainStatsRecord { * prefix, the entry number formatted as an unsigned integer and one of the * timed group suffix parameters to form a complete paramter name. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_PREFIX ".timed_group." @@ -3664,7 +3664,7 @@ struct _virDomainStatsRecord { * The time interval in seconds as unsigned long long for which the statistics * in this group were collected. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_INTERVAL ".interval" @@ -3674,7 +3674,7 @@ struct _virDomainStatsRecord { * Minimum latency of read operations in the defined interval, in nanoseconds as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_LATENCY_MIN ".rd_latency_min" @@ -3684,7 +3684,7 @@ struct _virDomainStatsRecord { * Maximum latency of read operations in the defined interval, in nanoseconds as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_LATENCY_MAX ".rd_latency_max" @@ -3694,7 +3694,7 @@ struct _virDomainStatsRecord { * Average latency of read operations in the defined interval, in nanoseconds as * unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_LATENCY_AVG ".rd_latency_avg" @@ -3704,7 +3704,7 @@ struct _virDomainStatsRecord { * Minimum latency of write operations in the defined interval, in nanoseconds * as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_LATENCY_MIN ".wr_latency_min" @@ -3714,7 +3714,7 @@ struct _virDomainStatsRecord { * Maximum latency of write operations in the defined interval, in nanoseconds * as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_LATENCY_MAX ".wr_latency_max" @@ -3724,7 +3724,7 @@ struct _virDomainStatsRecord { * Average latency of write operations in the defined interval, in nanoseconds * as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_LATENCY_AVG ".wr_latency_avg" @@ -3733,7 +3733,7 @@ struct _virDomainStatsRecord { * Minimum latency of zone append operations in the defined interval, in * nanoseconds as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_LATENCY_MIN ".zone_append_latency_min" @@ -3743,7 +3743,7 @@ struct _virDomainStatsRecord { * Maximum latency of zone append operations in the defined interval, in * nanoseconds as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_LATENCY_MAX ".zone_append_latency_max" @@ -3753,7 +3753,7 @@ struct _virDomainStatsRecord { * Average latency of zone append operations in the defined interval, in * nanoseconds as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_LATENCY_AVG ".zone_append_latency_avg" @@ -3763,7 +3763,7 @@ struct _virDomainStatsRecord { * Minimum latency of flush operations in the defined interval, in nanoseconds * as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_FLUSH_LATENCY_MIN ".flush_latency_min" @@ -3773,7 +3773,7 @@ struct _virDomainStatsRecord { * Maximum latency of flush operations in the defined interval, in nanoseconds * as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_FLUSH_LATENCY_MAX ".flush_latency_max" @@ -3783,7 +3783,7 @@ struct _virDomainStatsRecord { * Average latency of flush operations in the defined interval, in nanoseconds * as unsigned long long. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_FLUSH_LATENCY_AVG ".flush_latency_avg" @@ -3792,7 +3792,7 @@ struct _virDomainStatsRecord { * * Average number of pending read operations in the defined interval as double. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_QUEUE_DEPTH_AVG ".rd_queue_depth_avg" @@ -3801,7 +3801,7 @@ struct _virDomainStatsRecord { * * Average number of pending write operations in the defined interval as double. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_QUEUE_DEPTH_AVG ".wr_queue_depth_avg" @@ -3811,7 +3811,7 @@ struct _virDomainStatsRecord { * Average number of pending zone append operations in the defined interval as * double. * - * Since: 11.9.0 + * Since: 11.10.0 */ # define VIR_DOMAIN_STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_QUEUE_DEPTH_AVG ".zone_append_queue_depth_avg" -- 2.51.1

2 1

[PATCH 0/4] Add link to security notices to main page and improve reuse of assets in sub-projects
by Peter Krempa 24 Nov '25

24 Nov '25

Build version browsable at: https://pipo.sk.gitlab.io/-/libvirt/-/jobs/12191476209/artifacts/website/in… Peter Krempa (4): docs: index: Link to security notices from home page docs: css: Split out any main-page CSS to local.css docs: site.xsl: Use separate 'asset_href_base' and 'link_href_base' docs: page.xsl: Convert repository edit URI into a parameter docs/css/local.css | 3 +++ docs/css/main.css | 4 +--- docs/css/meson.build | 1 + docs/go/meson.build | 4 +++- docs/html/meson.build | 4 +++- docs/index.rst | 4 ++-- docs/kbase/internals/meson.build | 4 +++- docs/kbase/meson.build | 4 +++- docs/logos/meson.build | 4 +++- docs/manpages/meson.build | 4 +++- docs/meson.build | 4 +++- docs/page.xsl | 5 +++-- docs/site.xsl | 5 +++-- 13 files changed, 34 insertions(+), 16 deletions(-) create mode 100644 docs/css/local.css -- 2.51.1

2 6

[RFC v2 0/5] cover: RFE libvirt secret encryption on disk
by Arun Menon 24 Nov '25

24 Nov '25

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Add functionality to store the encryption scheme (none, aes256cbc, etc.) to the disk. This will be helpful during service restarts or migrating from an older version. Depending on the scheme, the secrets will be reloaded to the daemon. If no scheme is present in the xml configuration, then the secrets will be stored/loaded in the default base64 encoded format. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object is using, we can encrypt the secrets on disk and store them in <uuid>.<encryption_scheme> format. It is important to note that if the encryption key is changed between restarts, then the respective secret will not be loaded by the driver. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 --- Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (5): util: Add support for GnuTLS decryption secret: Set up default encrypted secret key for the virtsecretd service secret: Add secrets.conf configuration file and parse it secret: Add encryptionScheme attribute to the secrets xml configuration secret: Add functionality to load and save secrets in encrypted format include/libvirt/libvirt-secret.h | 20 ++ libvirt.spec.in | 10 + po/POTFILES | 1 + src/conf/meson.build | 1 + src/conf/schemas/secret.rng | 5 + src/conf/secret_conf.c | 21 +++ src/conf/secret_conf.h | 1 + src/conf/secret_config.c | 207 +++++++++++++++++++++ src/conf/secret_config.h | 48 +++++ src/conf/virsecretobj.c | 165 ++++++++++++---- src/conf/virsecretobj.h | 10 +- src/libvirt_private.syms | 3 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 26 +++ src/secret/secret-init-encryption.in | 11 ++ src/secret/secret_driver.c | 23 ++- src/secret/secrets.conf.in | 12 ++ src/secret/test_libvirt_secrets.aug.in | 6 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 128 ++++++++++++- src/util/vircrypto.h | 8 + src/util/virsecret.c | 4 + src/util/virsecret.h | 1 + tests/secretxml2xmlin/usage-ceph-space.xml | 1 + tests/secretxml2xmlin/usage-ceph.xml | 1 + tests/secretxml2xmlin/usage-iscsi.xml | 1 + tests/secretxml2xmlin/usage-tls.xml | 1 + tests/secretxml2xmlin/usage-volume.xml | 1 + tests/secretxml2xmlin/usage-vtpm.xml | 1 + tests/vircryptotest.c | 65 +++++++ 30 files changed, 788 insertions(+), 42 deletions(-) create mode 100644 src/conf/secret_config.c create mode 100644 src/conf/secret_config.h create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret-init-encryption.in create mode 100644 src/secret/secrets.conf.in create mode 100644 src/secret/test_libvirt_secrets.aug.in -- 2.51.1

3 17

[PATCH v2 1/2] docs: bhyve: document VNC's wait attribute
by Roman Bogorodskiy 24 Nov '25

24 Nov '25

Document the new VNC's 'wait' attribute in formatdomain.rst and drvbhyve.rst. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- docs/drvbhyve.rst | 10 ++++++++++ docs/formatdomain.rst | 4 ++++ 2 files changed, 14 insertions(+) diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst index 73372ff7cf..c0f4cd8a1f 100644 --- a/docs/drvbhyve.rst +++ b/docs/drvbhyve.rst @@ -429,6 +429,16 @@ Note: VNC password authentication is known to be cryptographically weak. Additionally, the password is passed as a command line argument in clear text. Make sure you understand the risks associated with this feature before using it. +:since:`Since 11.10.0`, the guest can be configured to wait for an incoming +VNC connection before booting: + +:: + + <graphics type='vnc' port='5904' wait='yes'> + <listen type='address' address='127.0.0.1'/> + </graphics> + + Clock configuration ~~~~~~~~~~~~~~~~~~~ diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c6d0b183d0..3d3a6b5a6e 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -6902,6 +6902,10 @@ interaction with the admin. ID is specified, then the default audio backend will be used. :since:`Since 7.2.0, qemu`. + The optional ``wait`` attribute, when set to ``yes``, causes the guest + to wait for an incoming VNC connection before booting. + :since:`Since 11.10.0, bhyve`. + ``spice`` :since:`Since 0.8.6` Starts a SPICE server. The ``port`` attribute specifies the TCP port number (with -1 as legacy syntax indicating that it should be -- 2.51.2

2 3