January 2026 - Devel - libvirt List Archives

[PATCH] Standardize socket family checks with proper macro
by Julio Faracco 23 Jan '26

23 Jan '26

There is a macro called VIR_SOCKET_ADDR_IS_FAMILY that checks the socket family. There are several occurrences of raw checks in libvirt code. This commit just standardizes the socket family checks by using its macro. Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- src/rpc/virnetsocket.c | 20 ++++++++++---------- src/util/virsocketaddr.c | 4 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index e8fc2d5f7d..22b0aa6ead 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -276,8 +276,8 @@ virNetSocketNew(virSocketAddr *localAddr, sock->unlinkUNIX = unlinkUNIX; /* Disable nagle for TCP sockets */ - if (sock->localAddr.data.sa.sa_family == AF_INET || - sock->localAddr.data.sa.sa_family == AF_INET6) { + if (VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_INET) || + VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_INET6)) { if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &no_slow_start, sizeof(no_slow_start)) < 0) { @@ -405,9 +405,9 @@ int virNetSocketNewListenTCP(const char *nodename, * other IP protocol */ if (port != 0 && service == NULL) { - if (addr.data.sa.sa_family == AF_INET) { + if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET)) { addr.data.inet4.sin_port = port; - } else if (addr.data.sa.sa_family == AF_INET6) { + } else if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET6)) { addr.data.inet6.sin6_port = port; } VIR_DEBUG("Used saved port %d", port); @@ -432,9 +432,9 @@ int virNetSocketNewListenTCP(const char *nodename, } if (port == 0 && service == NULL) { - if (addr.data.sa.sa_family == AF_INET) + if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET)) port = addr.data.inet4.sin_port; - else if (addr.data.sa.sa_family == AF_INET6) + else if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET6)) port = addr.data.inet6.sin6_port; VIR_DEBUG("Saved port %d", port); } @@ -1293,7 +1293,7 @@ void virNetSocketDispose(void *obj) #ifndef WIN32 /* If a server socket, then unlink UNIX path */ if (sock->unlinkUNIX && - sock->localAddr.data.sa.sa_family == AF_UNIX && + VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX) && sock->localAddr.data.un.sun_path[0] != '\0') unlink(sock->localAddr.data.un.sun_path); #endif @@ -1370,7 +1370,7 @@ bool virNetSocketIsLocal(virNetSocket *sock) { bool isLocal = false; virObjectLock(sock); - if (sock->localAddr.data.sa.sa_family == AF_UNIX) + if (VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX)) isLocal = true; virObjectUnlock(sock); return isLocal; @@ -1381,7 +1381,7 @@ bool virNetSocketHasPassFD(virNetSocket *sock) { bool hasPassFD = false; virObjectLock(sock); - if (sock->localAddr.data.sa.sa_family == AF_UNIX) + if (VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX)) hasPassFD = true; virObjectUnlock(sock); return hasPassFD; @@ -2223,7 +2223,7 @@ void virNetSocketClose(virNetSocket *sock) #ifndef WIN32 /* If a server socket, then unlink UNIX path */ if (sock->unlinkUNIX && - sock->localAddr.data.sa.sa_family == AF_UNIX && + VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX) && sock->localAddr.data.un.sun_path[0] != '\0') { if (unlink(sock->localAddr.data.un.sun_path) == 0) sock->localAddr.data.un.sun_path[0] = '\0'; diff --git a/src/util/virsocketaddr.c b/src/util/virsocketaddr.c index 4d4a6b2a0f..e8e691ce8f 100644 --- a/src/util/virsocketaddr.c +++ b/src/util/virsocketaddr.c @@ -481,7 +481,7 @@ virSocketAddrFormatFull(const virSocketAddr *addr, /* Short-circuit since getnameinfo doesn't work * nicely for UNIX sockets */ - if (addr->data.sa.sa_family == AF_UNIX) { + if (VIR_SOCKET_ADDR_IS_FAMILY(addr, AF_UNIX)) { if (withService) { addrstr = g_strdup_printf(VIR_LOOPBACK_IPV4_ADDR "%s0", separator ? separator : ":"); @@ -636,7 +636,7 @@ virSocketAddrGetPath(virSocketAddr *addr G_GNUC_UNUSED) return NULL; } - if (addr->data.sa.sa_family != AF_UNIX) { + if (!VIR_SOCKET_ADDR_IS_FAMILY(addr, AF_UNIX)) { virReportError(VIR_ERR_INVALID_ARG, "%s", _("UNIX socket address is required")); return NULL; -- 2.52.0

2 2

[PATCH v2 0/2] Remove @masked argument from virSocketAddrFormatWithPrefix
by Julio Faracco 23 Jan '26

23 Jan '26

Since its introduction in commit 426afc00, the function virSocketAddrFormatWithPrefix has never been called with argument masked=false. So, this commit proposes to remove this unnecessary argument from the function scope. This series also proposes the respective test cases for virSocketAddrFormatWithPrefix (now, without @masked argument). Julio Faracco (2): util: Remove @masked argument from virSocketAddrFormatWithPrefix tests: Add tests for virSocketAddrFormatWithPrefix src/network/network_iptables.c | 10 +++--- src/network/network_nftables.c | 10 +++--- src/util/virsocketaddr.c | 14 ++++---- src/util/virsocketaddr.h | 3 +- tests/sockettest.c | 63 ++++++++++++++++++++++++++++++++++ 5 files changed, 80 insertions(+), 20 deletions(-) -- 2.52.0

2 5

[PATCH 0/6] virtio-iommu: Support setting aw-bits and granule
by Michal Privoznik 22 Jan '26

22 Jan '26

*** BLURB HERE *** Michal Prívozník (6): qemu_capabilities: Introduce QEMU_CAPS_VIRTIO_IOMMU_AW_BITS conf: Allow aw_bits for virtio-iommu qemu_command: Generate aw_bits prop for virtio-iommu conf: Introduce granule attribute for virtio-iommu qemu_validate: Check whether granule of virtio-iommu is supported qemu_command: Generate granule prop for virtio-iommu docs/formatdomain.rst | 9 +++++- src/conf/domain_conf.c | 30 ++++++++++++++++++- src/conf/domain_conf.h | 13 ++++++++ src/conf/domain_validate.c | 18 +++++++---- src/conf/schemas/domaincommon.rng | 11 +++++++ src/libvirt_private.syms | 2 ++ src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 7 +++++ src/qemu/qemu_validate.c | 13 ++++++-- .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_s390x.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../caps_10.1.0_s390x.xml | 1 + .../caps_10.1.0_x86_64+inteltdx.xml | 1 + .../caps_10.1.0_x86_64.xml | 1 + .../caps_10.2.0_aarch64.xml | 1 + .../caps_10.2.0_x86_64+mshv.xml | 1 + .../caps_10.2.0_x86_64.xml | 1 + .../caps_11.0.0_aarch64.xml | 1 + .../caps_11.0.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_riscv64.xml | 1 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + .../virtio-iommu-aarch64.aarch64-latest.args | 2 +- .../virtio-iommu-aarch64.aarch64-latest.xml | 1 + .../qemuxmlconfdata/virtio-iommu-aarch64.xml | 4 ++- ...io-iommu-dma-translation.x86_64-latest.err | 2 +- 35 files changed, 124 insertions(+), 12 deletions(-) -- 2.52.0

3 18

[PATCH] Fix printf style used with virDomainIOMMUDef::aw_bits
by Michal Privoznik 22 Jan '26

22 Jan '26

From: Michal Privoznik <mprivozn(a)redhat.com> The aw_bits member of the virDomainIOMMUDef is of type unsigned int. However, in a few places (virDomainIOMMUDefCheckABIStability(), virDomainIOMMUDefFormat(), qemuBuildIOMMUCommandLine()) incorrect printf modifier is used. Fix those places. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.c | 4 ++-- src/qemu/qemu_command.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 8b26de674e..9672168df9 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -22301,7 +22301,7 @@ virDomainIOMMUDefCheckABIStability(virDomainIOMMUDef *src, } if (src->aw_bits != dst->aw_bits) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("Target domain IOMMU device aw_bits value '%1$d' does not match source '%2$d'"), + _("Target domain IOMMU device aw_bits value '%1$u' does not match source '%2$u'"), dst->aw_bits, src->aw_bits); return false; } @@ -28638,7 +28638,7 @@ virDomainIOMMUDefFormat(virBuffer *buf, virTristateSwitchTypeToString(iommu->iotlb)); } if (iommu->aw_bits > 0) { - virBufferAsprintf(&driverAttrBuf, " aw_bits='%d'", + virBufferAsprintf(&driverAttrBuf, " aw_bits='%u'", iommu->aw_bits); } if (iommu->dma_translation != VIR_TRISTATE_SWITCH_ABSENT) { diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 0de0a79b46..e81efdfde7 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6295,7 +6295,7 @@ qemuBuildIOMMUCommandLine(virCommand *cmd, "T:caching-mode", iommu->caching_mode, "S:eim", qemuOnOffAuto(iommu->eim), "T:device-iotlb", iommu->iotlb, - "z:aw-bits", iommu->aw_bits, + "p:aw-bits", iommu->aw_bits, "T:dma-translation", iommu->dma_translation, NULL) < 0) return -1; -- 2.52.0

2 1

[RFC PATCH v5 0/5] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 22 Jan '26

22 Jan '26

Hi, all. This patch adds Arm CCA support to QEMU driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. We are not yet at the stage where we can merge this patch as host Linux/QEMU support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v5: - Changed the target QEMU binary (Linaro's CCA/v10 version with added QMP functionality) - Changed the following changes to the CCA QMP command definitions: - QMP command name: query-rme-guest-capabilities - CCA capabilities info - Add ARM CCA support to firmware feature. [summary] At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. capability info uses QEMU QMP to query QEMU options. The option that exists now is for selecting a hash algorithm. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [Capability example] Execution results of 'virsh domcapability" on QEMU <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] To obtain capability info, it is necessary to support the QEMU QMP command, (See "[software version]"below). The JSON file for the CCA firmware feature has not yet been provided by the distributor. For CCA support, the equivalent of the following JSON file must be placed in /usr/share/qemu: tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the virsh create command. [software version] I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… The QEMU used was enhanced with CCA QMP command and found at: https://gitlab.com/Linaro/dcap/qemu/-/commits/cca/latest RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… RFC v3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LLWA… RFC v4 https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3WAW… Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com Akio Kakuno (3): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema Kazuhiro Abe (2): src: Add ARM CCA support in firmware feature tests: Adds Arm CCA support docs/formatdomain.rst | 46 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 146 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 30 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 18 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 111 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_10.1.0-virt.aarch64+armrme.xml | 250 + .../qemu_10.1.0.aarch64+armrme.xml | 250 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_10.1.0_aarch64+armrme.replies | 37727 ++++++++++++++++ .../caps_10.1.0_aarch64+armrme.xml | 518 + .../qemu/firmware/50-edk2-aarch64-armcca.json | 24 + tests/qemufirmwaretest.c | 3 + ...ch-security-cca.aarch64-latest+armrme.args | 30 + ...nch-security-cca.aarch64-latest+armrme.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 36 files changed, 39423 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_10.1.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.xml create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.0

1 5

[PATCH v1 0/4] Adding support for client-based FD migrations.
by Tejus GK 21 Jan '26

21 Jan '26

Libvirt supports FD-based live migrations in the form of tunnelled migrations. However, this isn't as performant as of now, since it involves extra copies. This patchset proposes adding support for externally provided file descriptors for live migration. By allowing the client to supply the migration FD directly, the extra copy can be avoided, improving overall migration performance. The intent is to gather early feedback on the approach and its feasibility. Comments, concerns, and suggestions are very welcome :) regards, Tejus Tejus GK (4): qemu: fd: introduce qemuFDTuple for FD storage lib: introduce virDomainFDStore API qemu: support incoming "fd" uri qemu: add support for fd based live migrations include/libvirt/libvirt-domain.h | 9 +++ src/driver-hypervisor.h | 7 ++ src/libvirt-domain.c | 62 +++++++++++++++ src/libvirt_public.syms | 5 ++ src/qemu/qemu_conf.h | 4 + src/qemu/qemu_driver.c | 41 ++++++++++ src/qemu/qemu_fd.c | 23 ++++++ src/qemu/qemu_fd.h | 14 ++++ src/qemu/qemu_migration.c | 117 +++++++++++++++++++++++++++- src/remote/remote_daemon_dispatch.c | 36 +++++++++ src/remote/remote_driver.c | 22 ++++++ src/remote/remote_protocol.x | 12 ++- 12 files changed, 348 insertions(+), 4 deletions(-) -- 2.43.7

2 11

[PATCH 0/2] src: Use device alias when ifname is unset in virDomainInterfaceAddresses()
by Michal Privoznik 21 Jan '26

21 Jan '26

*** BLURB HERE *** Michal Prívozník (2): libvirt-domain: Fix documentation of virDomainInterfaceAddresses() src: Use device alias when ifname is unset in virDomainInterfaceAddresses() src/conf/domain_conf.c | 16 ++++++++++++++-- src/libvirt-domain.c | 4 +++- 2 files changed, 17 insertions(+), 3 deletions(-) -- 2.52.0

2 3

[RFC] Reintroducing customisable hotplug timeouts
by Akash Kulhalli 20 Jan '26

20 Jan '26

I'd like to resurface an earlier proposal [1] to make the unplug timeout user-configurable. With production guests running sustained, non-trivial workloads, we find that hot(un)plug operations regularly takes longer than the current default of 5s. However, the inability to easily configure this timeout means that in the worst case a recompilation with appropriate values set is required for each deployment, which is cumbersome to maintain and patch. The previous proposal [1] also initially made the timeout configurable, however that was specifically for the ppc64 architecture. Therefore, imposing this change for an entire architecture made sense, since it was a universal requirement for that platform. With deployment environments as diverse and varied as x86, having a single, inconfigurable value does not make as much sense now. For x86, such a change is not ideal since the desired timeout value depends very heavily on the deployment environment in use - if it is being performed by a human anything more than 10s is an undesirable user experience [2], as pointed out in the original discussion. However, more relaxed timeout values (e.g. 15-20s) can be more acceptable if the operations are background/ not directly user-facing. It is in these cases where the ability to change the timeout more easily becomes more desirable. To prevent misconfiguration, while maintaining the same out-of-box experience for existing users, I'd also like to propose the following- 1. As mentioned in the original proposal [1], the timeout cannot be set to a value lower than the default timeout of 5s; in these cases a warning will be emitted and the timeout will be reset to the default value. 2. Including an upper cap would also be desirable, in my opinion - any API consumer should not wait endlessly for an async operation to finish. 3. This configuration option will only be described in qemu.conf, not imposed - the out-of-box experience will remain unchanged at the current default (5s) for everyone who does not wish to tweak/is unaware of this value. An administrator who knowingly changes these values is therefore not blindsided by any perceived "hangs" resulting from the use of an increased timeout window. Since this would be a clearly documented and explicitly opt-in behaviour, the benefits in the form of easy modification based on evolving operational needs would be quite significant. Given the varying nature of production environments and specific operational needs at scale, it would therefore be beneficial to reconsider the merits of the original proposal. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/TXYV… [2] https://www.nngroup.com/articles/response-times-3-important-limits/

4 5

[PATCH 0/3] Add info used by AppArmor to domstatus XML
by Wesley Hershberger 20 Jan '26

20 Jan '26

This series has two independent changes following from a thread back in November (#692) [1][2]. Broadly speaking I agree that regenerating the apparmor profile from scratch feels fragile. That said, this issue has been on my back burner for a while; it's out of scope for me to take on that (much larger) effort. I'm including the first patch for completeness' sake, as all blockcommit operations fail without it when using the AppArmor driver (#806 [3]). It was rejected in 2017 but is still carried in Ubuntu [4]. Feel free not to pull it - the solution to that issue is separate and not my primary concern. I can send a new version of patch 3 that applies without it. My understanding is that the domstatus XML is only used by libvirt internally (stored in /var/run to persist runtime info over libvirtd restarts). Since this is the case, I haven't included documentation for the new items here; please let me know if I missed where they should be documented. I'm happy to consider this a first draft; feedback is welcome. I've opened a MR to libvirt-tck with test cases that demonstrate the bugs that this fixes [5]. Those tests pass with the series applied. Thanks for your consideration. ~Wesley [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QUJI… [2] https://gitlab.com/libvirt/libvirt/-/issues/692 [3] https://gitlab.com/libvirt/libvirt/-/issues/806 [4] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3WID… [5] https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/73 --- Serge Hallyn (1): virt-aa-helper: Ask for no deny rule for readonly disk elements Wesley Hershberger (2): qemu: Store tapfd path in domstatus XML qemu: Store blockcommit permissions in domstatus XML src/conf/domain_conf.c | 17 +++++++++++++++++ src/conf/domain_conf.h | 1 + src/conf/storage_source_conf.c | 2 ++ src/conf/storage_source_conf.h | 3 +++ src/qemu/qemu_block.c | 26 ++++++++++++++++++++++++++ src/qemu/qemu_blockjob.c | 8 ++++++++ src/qemu/qemu_command.c | 9 +++++++++ src/qemu/qemu_security.c | 7 +++++++ src/security/security_apparmor.c | 1 + src/security/virt-aa-helper.c | 14 ++++++++------ 10 files changed, 82 insertions(+), 6 deletions(-) --- base-commit: 16804acf14616d7357ad6a336f2ffd6d255a8d63 change-id: 20260105-apparmor-races-d03238ee4d93 Best regards, -- Wesley Hershberger <wesley.hershberger(a)canonical.com>

3 10

[PATCH] virnetdevtap: Produce more helpful error message in virNetDevTapCreate()
by Michal Privoznik 20 Jan '26

20 Jan '26

From: Michal Privoznik <mprivozn(a)redhat.com> Since v10.8.0-rc1~133 a different error is reported from virNetDevTapCreate() when the tap device already exists (and <interface/> XML specifies managed='no'). But the change covers only one scenario: if multique was requested in <inteface/> XML BUT pre-created tap device doesn't have multi_queue flag set. The opposite scenario: if the device has the multi_queue flag set BUT no multique was specified in the XML is missing. Until now. Resolves: https://issues.redhat.com/browse/RHEL-118303 Fixes: f6fb097e11a15e390d989411b2660ead0d1a7c10 Fixes: 465a38154f0cfc31d62c4105770e1f4a9599a611 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virnetdevtap.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c index b709d76cc7..e3a6209642 100644 --- a/src/util/virnetdevtap.c +++ b/src/util/virnetdevtap.c @@ -230,11 +230,16 @@ int virNetDevTapCreate(char **ifname, } if (ioctl(fd, TUNSETIFF, &ifr) < 0) { - if (flags & VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING && - tapfdSize > 1) { - virReportSystemError(errno, - _("Unable to create multiple fds for tap device %1$s (maybe existing device was created without multi_queue flag)"), - *ifname); + if (flags & VIR_NETDEV_TAP_CREATE_ALLOW_EXISTING) { + if (tapfdSize > 1) { + virReportSystemError(errno, + _("Unable to create multiple fds for tap device %1$s (maybe existing device was created without multi_queue flag)"), + *ifname); + } else { + virReportSystemError(errno, + _("Unable to set tap device %1$s (maybe existing device was created with multi_queue flag but device XML lacks 'queues' greater than one)"), + *ifname); + } } else { virReportSystemError(errno, _("Unable to create tap device %1$s"), -- 2.52.0

2 1