- Devel - libvirt List Archives

[libvirt PATCH] NEWS: document fix for starting transient domains
by Ján Tomko 14 Jan '25

14 Jan '25

Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- NEWS.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 08d1d24d48..eedb6008bd 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -21,6 +21,11 @@ v11.0.0 (unreleased) * **Bug fixes** + * qemu: tpm: do not update profile name for transient domains + + Fix a possible crash when starting a transient domain which was + introduced in the previous release. + v10.10.0 (2024-12-02) ===================== -- 2.47.0

2 1

Entering freeze for libvirt-11.0.0
by Jiri Denemark 13 Jan '25

13 Jan '25

I have just tagged v11.0.0-rc1 in the repository and pushed signed tarballs 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] storage_file: Refuse qcow2 images with empty string as 'data_file'
by Peter Krempa 13 Jan '25

13 Jan '25

See patch 1/2 for justification. Patch 2 is a test case. Peter Krempa (2): storage_file: Refuse qcow2 images with empty string as 'data_file' virstoragetest: Add case for qcow2 image with empty string as 'data_file' src/storage_file/storage_source.c | 10 ++++++++++ tests/virstoragetest.c | 5 +++++ .../images/datafile-emptystr.qcow2 | Bin 0 -> 327680 bytes 3 files changed, 15 insertions(+) create mode 100644 tests/virstoragetestdata/images/datafile-emptystr.qcow2 -- 2.47.1

2 3

[PATCH] meson: Replace meson.source_root() with meson.project_source_root()
by Michal Privoznik 13 Jan '25

13 Jan '25

The source_root() method is deprecated in 0.56.0 and we're recommended to use project_source_root() instead. This is similar to commit v8.9.0-rc1~70 but somehow, the old method sneaked in. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build index c1a2e6eadb..f8eff99e2c 100644 --- a/meson.build +++ b/meson.build @@ -17,7 +17,7 @@ endif i18n = import('i18n') -po_dir = meson.source_root() / 'po' +po_dir = meson.project_source_root() / 'po' # figure out if we are building from git -- 2.45.2

2 1

[PATCH] access: fix po_check when polkit is disabled
by Daniel P. Berrangé 13 Jan '25

13 Jan '25

The generated org.libvirt.api.policy.in file was recently added to the POTFILES list as it contains translatable messages. It is only generated when WITH_POLKIT && WITH_LIBVIRTD is satisfied though, resulting in the 'po_check' syntax rule failing if either of those conditions are not met. It is harmless to unconditionally generate this file, as a separate rule takes care of of installing it, and the latter remains under the build conditions. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/access/meson.build | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/src/access/meson.build b/src/access/meson.build index 0cc9cf2b79..d1336c0093 100644 --- a/src/access/meson.build +++ b/src/access/meson.build @@ -63,19 +63,22 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] ) endforeach +# Generated outside the WITH_POLKIT / WITH_LIBVIRTD condition +# because syntax-check/po_check requires this to exist +polgen = custom_target( + 'org.libvirt.api.policy.in', + input: access_perm_h, + output: 'org.libvirt.api.policy.in', + command: [ meson_python_prog, python3_prog, genpolkit_prog, '@INPUT@' ], + capture: true, + build_by_default: true, +) +access_generated += polgen + if conf.has('WITH_POLKIT') access_sources += access_polkit_sources if conf.has('WITH_LIBVIRTD') - polgen = custom_target( - 'org.libvirt.api.policy.in', - input: access_perm_h, - output: 'org.libvirt.api.policy.in', - command: [ meson_python_prog, python3_prog, genpolkit_prog, '@INPUT@' ], - capture: true, - build_by_default: true, - ) - access_generated += polgen i18n.merge_file( input: polgen, -- 2.47.1

2 1

[PATCH] qemu: support vlan change for linux host bridge during update-device
by Laine Stump 13 Jan '25

13 Jan '25

Since we previously only supported vlan tagging for interfaces connected to an OVS bridge [*], the code in qemuChangeNet() (used by the update-device API) assumed an interface with modified vlan config was on an OVS bridge, and would call the OVS-specific virNetDevOpenvswitchUpdateVlan(). Now that we support vlan tagging for interfaces connected to a standard Linux host bridge, we must check the type of connection and only call the OVS function when connected to an OVS bridge *both before and after the update*. Otherwise we just set the flag to re-connect to the bridge, which has the side effect of redoing the vlan setup. ([*] or an SRIOV VF assigned using VFIO, but we don't support *any runtime changes to that type of netdev so it's irrelevant here.) Signed-off-by: Laine Stump <laine(a)redhat.com> --- I'm fine with this going in either before or after the 11.0.0 release (would prefer before since it is a bugfix), but if it's going into the release I'd rather it be included with RC2 rather than only in the final release. For that reason, if someone ACKs the patch and agrees that it's safe to go in, please push it for me (since Jiri will almost certainly tag RC2 before I'm conscious on Monday morning) src/qemu/qemu_hotplug.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index de0777d330..5a7e6c3b12 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -4144,8 +4144,13 @@ qemuDomainChangeNet(virQEMUDriver *driver, * they don't apply to a particular type. */ - if (!virNetDevVlanEqual(virDomainNetGetActualVlan(olddev), - virDomainNetGetActualVlan(newdev))) { + /* since attaching to a new bridge will re-do the vlan setup, + * we don't need to separately do that in the case that we're + * already switching to a different bridge + */ + if (!(needBridgeChange || + virNetDevVlanEqual(virDomainNetGetActualVlan(olddev), + virDomainNetGetActualVlan(newdev)))) { needVlanUpdate = true; } @@ -4215,6 +4220,23 @@ qemuDomainChangeNet(virQEMUDriver *driver, needReplaceDevDef = true; } + if (needVlanUpdate) { + if (virDomainNetDefIsOvsport(olddev) && virDomainNetDefIsOvsport(newdev)) { + /* optimization if we're attached to an OVS bridge. This + * will redo vlan setup without needing to re-attach the + * tap device to the bridge + */ + if (virNetDevOpenvswitchUpdateVlan(newdev->ifname, &newdev->vlan) < 0) + goto cleanup; + } else { + /* vlan setup is done as a part of reconnecting the tap + * device to a new bridge (either OVS or Linux host bridge). + */ + needBridgeChange = true; + } + needReplaceDevDef = true; + } + if (needBridgeChange) { if (qemuDomainChangeNetBridge(vm, olddev, newdev) < 0) goto cleanup; @@ -4266,12 +4288,6 @@ qemuDomainChangeNet(virQEMUDriver *driver, goto cleanup; } - if (needVlanUpdate) { - if (virNetDevOpenvswitchUpdateVlan(newdev->ifname, &newdev->vlan) < 0) - goto cleanup; - needReplaceDevDef = true; - } - if (needReplaceDevDef) { /* the changes above warrant replacing olddev with newdev in * the domain's nets list. -- 2.47.1

2 1

[PATCH 0/2] news: add a couple items before release
by Laine Stump 13 Jan '25

13 Jan '25

This adds a "new feature" for the VLAN tagging support on Linux host bridges added by Leigh Brown, and an "improvement" (migration between mdev<->SRIOV vGPUs) by me. Feel free to push this for me so it can be included in RC2. *** BLURB HERE *** Laine Stump (2): news: note addition of vlan tagging support for Linux host bridges news: document support for mdev <-> SRIOV VF vGPU live migration NEWS.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) -- 2.47.1

2 3

[PATCH] qemu_migration: Do not consider post-copy active in postcopy-recover
by Jiri Denemark 13 Jan '25

13 Jan '25

The postcopy-recover migration state in QEMU means a connection for the migration stream was established. Depending on the schedulers on both hosts a relative timing of the corresponding MIGRATION event on the source host and the destination host may differ. Specifically it's possible that the source sees postcopy-recover while the destination is still in postcopy-paused. Currently the Perform phase on the source host ends when we get postcopy-recover event and the Finish phase on the destination host is called. If this is fast enough we can still see postcopy-paused state when the Finish phase starts waiting for migration to complete. This is interpreted as a failure and reported back to the caller. Even though the recovery may actually start just a few moments later. To avoid this race we now don't consider post-copy migration active in postcopy-recover state and keep waiting for postcopy-active event (in the success path). Thus the Finish phase is entered only after the migration switches to postcopy-active. In this state QEMU guarantees the destination already switched at least to postcopy-recover and we won't be confused be seeing an old postcopy-failed state. https://issues.redhat.com/browse/RHEL-73085 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_migration.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 50e350b0c4..1582a738a3 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1872,11 +1872,11 @@ qemuMigrationUpdateJobType(virDomainJobData *jobData) switch ((qemuMonitorMigrationStatus) priv->stats.mig.status) { case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY: - case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER: jobData->status = VIR_DOMAIN_JOB_STATUS_POSTCOPY; break; case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER_SETUP: + case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER: jobData->status = VIR_DOMAIN_JOB_STATUS_POSTCOPY_RECOVER; break; -- 2.47.1

2 1

[PATCH] conf: Do not parse hyperv features with passthrough mode
by Martin Kletzander 13 Jan '25

13 Jan '25

The schema does not allow that anyway and we then format them all back which leads to libvirt producing an invalid XML. Resolves: https://issues.redhat.com/browse/RHEL-70656 Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/conf/domain_conf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index e658b68c48b6..3f88a77a8fea 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -16643,6 +16643,9 @@ virDomainFeaturesHyperVDefParse(virDomainDef *def, def->features[VIR_DOMAIN_FEATURE_HYPERV] = mode; + if (mode == VIR_DOMAIN_HYPERV_MODE_PASSTHROUGH) + return 0; + node = xmlFirstElementChild(node); while (node != NULL) { int feature; -- 2.47.1

2 1

Virtual manager error
by Domenico Panella 13 Jan '25

13 Jan '25

Hi everyone, when i try to run a VM through virt-manager application (Slackware 15), I get the following error: *Errore nell'avvio del dominio: internal error: unknown architecture 'loongarch64'** ** **Traceback (most recent call last):** ** File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper** ** callback(asyncjob, *args, **kwargs)** ** File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb** ** callback(*args, **kwargs)** ** File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn** ** ret = fn(self, *args, **kwargs)** ** File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup** ** self._backend.create()** ** File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1373, in create** ** raise libvirtError('virDomainCreate() failed')** **libvirt.libvirtError: internal error: unknown architecture 'loongarch64'* How can i fix it? Cordially Domenico

2 1