November 2021 - Devel - libvirt List Archives

[libvirt PATCH] conf: match by network alias only if aliases are assigned
by Ján Tomko 19 Nov '21

19 Nov '21

Commit 114e3b423210d316b3326816fd2c33335b1167fe added matching by aliases for interfaces with same MAC address. ( https://bugzilla.redhat.com/show_bug.cgi?id=1926190 ) However, unless the domain is using user aliases (prefixed ua-), there are no aliases in the persistent definition. Only match by MAC/PCI/other addresses in that case, to fix update-device with --persistent flag (AFFECT_LIVE | AFFECT_CONFIG). https://bugzilla.redhat.com/show_bug.cgi?id=2024098 Fixes: 114e3b423210d316b3326816fd2c33335b1167fe Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/conf/domain_conf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index da0c64b460..0d7489094b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -15763,8 +15763,8 @@ virDomainNetFindIdx(virDomainDef *def, virDomainNetDef *net) &net->info.addr.ccw)) continue; - if (net->info.alias && - STRNEQ_NULLABLE(def->nets[i]->info.alias, net->info.alias)) { + if (net->info.alias && def->nets[i]->info.alias && + STRNEQ(def->nets[i]->info.alias, net->info.alias)) { continue; } -- 2.31.1

2 1

[PATCH] docs: Use 'live' or 'lively' to describe the device events
by Han Han 19 Nov '21

19 Nov '21

The event of device added or removed only happens at live attachment or detachment. Make the comments more explicit. Signed-off-by: Han Han <hhan(a)redhat.com> --- include/libvirt/libvirt-domain.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 2f017c5b68..25ee06d0d6 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -4148,7 +4148,7 @@ typedef void (*virConnectDomainEventPMSuspendDiskCallback)(virConnectPtr conn, * @devAlias: device alias * @opaque: application specified data * - * This callback occurs when a device is removed from the domain. + * This callback occurs when a device is lively removed from the domain. * * The callback signature to use when registering for an event of type * VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED with virConnectDomainEventRegisterAny() @@ -4165,7 +4165,7 @@ typedef void (*virConnectDomainEventDeviceRemovedCallback)(virConnectPtr conn, * @devAlias: device alias * @opaque: application specified data * - * This callback occurs when a device is added to the domain. + * This callback occurs when a device is lively added to the domain. * * The callback signature to use when registering for an event of type * VIR_DOMAIN_EVENT_ID_DEVICE_ADDED with virConnectDomainEventRegisterAny() @@ -4183,7 +4183,7 @@ typedef void (*virConnectDomainEventDeviceAddedCallback)(virConnectPtr conn, * @devAlias: device alias * @opaque: application specified data * - * This callback occurs when it's certain that removal of a device failed. + * This callback occurs when it's certain that live removal of a device failed. * * The callback signature to use when registering for an event of type * VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED with -- 2.33.1

2 2

[libvirt PATCH v5 0/3] Ignore EPERM on implicit clearing of VF VLAN ID
by Dmitrii Shcherbakov 18 Nov '21

18 Nov '21

SmartNIC DPUs may not expose some privileged eswitch operations to the hypervisor hosts. For example, this happens with Bluefield devices running in the ECPF (default) mode [1] for security reasons. While VF MAC address programming is possible via an RTM_SETLINK operation, trying to set a VLAN ID in the same operation will fail with EPERM. In the kernel a relevant call chain may look like do_setlink -> do_setvfinfo -> dev->netdev_ops->set_vf_vlan which calls a driver-specific function like [2] eventually. The equivalent ip link commands below provide an illustration: 1. This works: sudo ip link set enp130s0f0 vf 2 mac de:ad:be:ef:ca:fe 2. Setting (or clearing) a VLAN fails with EPERM: sudo ip link set enp130s0f0 vf 2 vlan 0 RTNETLINK answers: Operation not permitted 3. This is what Libvirt attempts to do today (when trying to clear a VF VLAN at the same time as programming a VF MAC). sudo ip link set enp130s0f0 vf 2 vlan 0 mac de:ad:be:ef:ca:fe RTNETLINK answers: Operation not permitted If setting an explicit VLAN ID results in an EPERM, clearing a VLAN (setting a VLAN ID to 0) can be handled gracefully by ignoring the EPERM error with the rationale being that if we cannot set this state in the first place, we cannot clear it either. Thus, virNetDevSetVfConfig is split into two distinct functions. If clearing a VLAN ID fails with EPERM when clearing is implicit, the error is simply ignored. For explicit clearing EPERM is still a fatal error. Both new functions rely virNetDevSendVfSetLinkRequest that implements common functionality related to formatting a request, sending it and handling error conditions and returns 0 or an error since in both cases the payload is either NLMSG_DONE (no error) or NLMSG_ERROR where an error message is needed by the caller to handle known cases appropriately. This function allows the conditional code to be unit tested. An alternative to this could be providing a higher level control plane mechanism that would provide metadata about a device being remotely managed in which case Libvirt would avoid trying to set or clear a VLAN ID. This would be more complicated since other software (like Nova in the OpenStack case) would have to annotate every guest device with an attribute indicating whether a device is remotely managed or not based on operator provided configuration so that Libvirt can act on this and avoid VLAN programming. https://gitlab.com/dmitriis/libvirt/-/pipelines/411334205 v4 changes: * Split the change into several patches; * Added a missing test case; * Reworked error handling; * Added a way to pass a NULL vlan id to preserve the old behavior when needed. v5 changes: * added the news file entry; * fixed vlan handling in virNetDevSetVfVlan (for an issue introduced in v4). [1] https://docs.mellanox.com/display/BlueFieldSWv35111601/Modes+of+Operation#M… [2] https://github.com/torvalds/linux/blob/v5.15/drivers/net/ethernet/mellanox/… Dmitrii Shcherbakov (3): Set VF MAC and VLAN ID in two different operations Allow VF vlanid to be passed as a pointer Ignore EPERM on implicit clearing of VF VLAN ID NEWS.rst | 15 +++ src/hypervisor/virhostdev.c | 4 +- src/libvirt_private.syms | 7 ++ src/util/virnetdev.c | 218 ++++++++++++++++++++------------ src/util/virnetdevpriv.h | 44 +++++++ tests/virnetdevtest.c | 241 +++++++++++++++++++++++++++++++++++- 6 files changed, 451 insertions(+), 78 deletions(-) create mode 100644 src/util/virnetdevpriv.h -- 2.32.0

2 5

[libvirt PATCH v6 0/3] Ignore EPERM on implicit clearing of VF VLAN ID
by Dmitrii Shcherbakov 18 Nov '21

18 Nov '21

SmartNIC DPUs may not expose some privileged eswitch operations to the hypervisor hosts. For example, this happens with Bluefield devices running in the ECPF (default) mode [1] for security reasons. While VF MAC address programming is possible via an RTM_SETLINK operation, trying to set a VLAN ID in the same operation will fail with EPERM. In the kernel a relevant call chain may look like do_setlink -> do_setvfinfo -> dev->netdev_ops->set_vf_vlan which calls a driver-specific function like [2] eventually. The equivalent ip link commands below provide an illustration: 1. This works: sudo ip link set enp130s0f0 vf 2 mac de:ad:be:ef:ca:fe 2. Setting (or clearing) a VLAN fails with EPERM: sudo ip link set enp130s0f0 vf 2 vlan 0 RTNETLINK answers: Operation not permitted 3. This is what Libvirt attempts to do today (when trying to clear a VF VLAN at the same time as programming a VF MAC). sudo ip link set enp130s0f0 vf 2 vlan 0 mac de:ad:be:ef:ca:fe RTNETLINK answers: Operation not permitted If setting an explicit VLAN ID results in an EPERM, clearing a VLAN (setting a VLAN ID to 0) can be handled gracefully by ignoring the EPERM error with the rationale being that if we cannot set this state in the first place, we cannot clear it either. Thus, virNetDevSetVfConfig is split into two distinct functions. If clearing a VLAN ID fails with EPERM when clearing is implicit, the error is simply ignored. For explicit clearing EPERM is still a fatal error. Both new functions rely virNetDevSendVfSetLinkRequest that implements common functionality related to formatting a request, sending it and handling error conditions and returns 0 or an error since in both cases the payload is either NLMSG_DONE (no error) or NLMSG_ERROR where an error message is needed by the caller to handle known cases appropriately. This function allows the conditional code to be unit tested. An alternative to this could be providing a higher level control plane mechanism that would provide metadata about a device being remotely managed in which case Libvirt would avoid trying to set or clear a VLAN ID. This would be more complicated since other software (like Nova in the OpenStack case) would have to annotate every guest device with an attribute indicating whether a device is remotely managed or not based on operator provided configuration so that Libvirt can act on this and avoid VLAN programming. https://gitlab.com/dmitriis/libvirt/-/pipelines/411876081 v4 changes: * Split the change into several patches; * Added a missing test case; * Reworked error handling; * Added a way to pass a NULL vlan id to preserve the old behavior when needed. v5 changes: * added the news file entry; * fixed vlan handling in virNetDevSetVfVlan (for an issue introduced in v4). v6 changes: Refactoring, addressed: https://listman.redhat.com/archives/libvir-list/2021-November/msg00521.html [1] https://docs.mellanox.com/display/BlueFieldSWv35111601/Modes+of+Operation#M… [2] https://github.com/torvalds/linux/blob/v5.15/drivers/net/ethernet/mellanox/… Dmitrii Shcherbakov (3): Set VF MAC and VLAN ID in two different operations Allow VF vlanid to be passed as a pointer Ignore EPERM on implicit clearing of VF VLAN ID NEWS.rst | 15 +++ src/hypervisor/virhostdev.c | 4 +- src/libvirt_private.syms | 7 ++ src/util/virnetdev.c | 217 ++++++++++++++++++++------------ src/util/virnetdevpriv.h | 44 +++++++ tests/virnetdevtest.c | 241 +++++++++++++++++++++++++++++++++++- 6 files changed, 450 insertions(+), 78 deletions(-) create mode 100644 src/util/virnetdevpriv.h -- 2.32.0

1 3

[PATCH 0/7] some cleanups around CPU related code
by Daniel Henrique Barboza 18 Nov '21

18 Nov '21

Hi, Here are some cleanups I ended up making while investigating a test issue with ppc64 hosts recently. Daniel Henrique Barboza (7): qemu_capabilities.c: use g_autofree in virQEMUCapsLoadCache() cpu_x86.c: remove 'guest' param from x86Compute() cpu_ppc64.c: remove 'guest' param from ppc64Compute() qemu_capabilities.c: use g_autofree in virQEMUCapsLoadHostCPUModelInfo domain_conf.h: add autoptr cleanup func to virDomainXMLOptionPtr qemu_process.c: use g_autoptr() in qemuProcessQMPInitMonitor qemu_capabilities.c: use g_autoptr() in virQEMUCapsInitHostCPUModel() src/conf/domain_conf.h | 1 + src/cpu/cpu_ppc64.c | 26 +------- src/cpu/cpu_x86.c | 38 +----------- src/qemu/qemu_capabilities.c | 116 +++++++++++++++-------------------- src/qemu/qemu_process.c | 15 ++--- 5 files changed, 57 insertions(+), 139 deletions(-) -- 2.31.1

2 12

[PATCH 0/7] some cleanups around CPU related code
by Daniel Henrique Barboza 18 Nov '21

18 Nov '21

Hi, Here are some cleanups I ended up making while investigating a test issue with ppc64 hosts recently. Daniel Henrique Barboza (7): qemu_capabilities.c: use g_autofree in virQEMUCapsLoadCache() cpu_x86.c: remove 'guest' param from x86Compute() cpu_ppc64.c: remove 'guest' param from ppc64Compute() qemu_capabilities.c: use g_autofree in virQEMUCapsLoadHostCPUModelInfo domain_conf.h: add autoptr cleanup func to virDomainXMLOptionPtr qemu_process.c: use g_autoptr() in qemuProcessQMPInitMonitor qemu_capabilities.c: use g_autoptr() in virQEMUCapsInitHostCPUModel() src/conf/domain_conf.h | 1 + src/cpu/cpu_ppc64.c | 26 +------- src/cpu/cpu_x86.c | 38 +----------- src/qemu/qemu_capabilities.c | 116 +++++++++++++++-------------------- src/qemu/qemu_process.c | 15 ++--- 5 files changed, 57 insertions(+), 139 deletions(-) -- 2.31.1

2 10

[libvirt PATCH 0/5] meson: Introduce qemu_datadir option
by Andrea Bolognani 18 Nov '21

18 Nov '21

This is mostly useful to macOS users (see [1] for background). The first two commits are fixes for small issues discovered while looking into this. Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/409294109 [1] https://gitlab.com/libvirt/libvirt/-/issues/168 Andrea Bolognani (5): meson: Define qemu_moddir correctly qemu: Set QEMU data location correctly qemu: Rename interop locations meson: Introduce qemu_datadir option spec: Explicitly provide locations for QEMU data libvirt.spec.in | 6 ++++++ meson.build | 8 +++++++- meson_options.txt | 1 + src/qemu/qemu_interop_config.c | 11 +++++------ 4 files changed, 19 insertions(+), 7 deletions(-) -- 2.31.1

2 6

Plans for the next release
by Jiri Denemark 18 Nov '21

18 Nov '21

We are getting close to the next release of libvirt. To aim for the release on Dec 01 I suggest entering the freeze on Thursday Nov 25 and tagging RC2 on Monday Nov 29. I hope this works for everyone. Jirka

1 0

[PATCH] qemuDomainPrepareStorageSourceBlockdev: Set default encryption engine also when preparing virStorageSource
by Peter Krempa 18 Nov '21

18 Nov '21

Originally the default encryption engine is populated in the disk post-parse callback code. This works for disks but for any additional images introduced either via the block copy API or via the backup API we don't populate the default. In case when the backup or block copy is requested on an encrypted image this would then lead to an error: error: internal error: Unexpected enum value 0 for virStorageEncryptionEngine This patch adds another point where we populate the default which is when setting up a virStorageSource for actual usage. We keep the original setting in the post-parse callback as that's the only point that is recorded in the XML file after definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2023674 Fixes: ab1d46d6128 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_domain.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index fb203bc830..5aad321e36 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -10651,6 +10651,9 @@ qemuDomainPrepareStorageSourceBlockdev(virDomainDiskDef *disk, if (qemuBlockStorageSourceNeedsStorageSliceLayer(src)) src->sliceStorage->nodename = g_strdup_printf("libvirt-%u-slice-sto", src->id); + if (src->encryption && src->encryption->engine == VIR_STORAGE_ENCRYPTION_ENGINE_DEFAULT) + src->encryption->engine = VIR_STORAGE_ENCRYPTION_ENGINE_QEMU; + if (qemuDomainValidateStorageSource(src, priv->qemuCaps, false) < 0) return -1; -- 2.31.1

2 1

[libvirt PATCH] spec: Don't create unnecessary directory
by Andrea Bolognani 18 Nov '21

18 Nov '21

The directory is already created by the build system, so we don't need to create it explicitly in the spec file; moreover, the path was incorrect, because it used datadir instead of localstatedir. Fixes: 4e041189f85bc1b0f8d5278c0cafdd4aba55beaf 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 5f1773ef93..85e879fedb 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1192,7 +1192,6 @@ rm -f $RPM_BUILD_ROOT%{_libdir}/libvirt/storage-file/*.a rm -f $RPM_BUILD_ROOT%{wireshark_plugindir}/libvirt.la %endif -install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/lib/libvirt/dnsmasq/ # We don't want to install /etc/libvirt/qemu/networks in the main %%files list # because if the admin wants to delete the default network completely, we don't # want to end up re-incarnating it on every RPM upgrade. -- 2.31.1

2 1