January 2025 - Devel - libvirt List Archives

[PATCH 00/20] qemu: support mapped-ram+directio+mulitfd
by Jim Fehlig 15 Jan '25

15 Jan '25

This series is essentially V1 of a prior RFC [1] to support QEMU's mapped-ram stream format [2] and migration capability. Along with supporting mapped-ram, it implements a design approach we discussed for supporting parallel save/restore [3]. In summary, the approach is 1. Add mapped-ram migration capability 2. Steal an element from save header 'unused' for a 'features' variable and bump save version to 3. 3. Add /etc/libvirt/qemu.conf knob for the save format version, defaulting to latest v3 4. Use v3 (aka mapped-ram) by default 5. Use mapped-ram with BYPASS_CACHE for v3, old approach for v2 6. include: Define constants for parallel save/restore 7. qemu: Add support for parallel save. Implies mapped-ram, reject if v2 8. qemu: Add support for parallel restore. Implies mapped-ram. Reject if v2 9. tools: add parallel parameter to virsh save command 10. tools: add parallel parameter to virsh restore command With this series, saving and restoring using mapped-ram is enabled by default if the underlying QEMU advertises the mapped-ram migration capability. It can be disabled by changing the 'save_image_version' setting in qemu.conf. To use mapped-ram with QEMU: - The 'mapped-ram' migration capability must be set to true - The 'multifd' migration capability must be set to true and the 'multifd-channels' migration parameter must set to a value >= 1 - QEMU must be provided an fdset containing the migration fd(s) - The 'migrate' qmp command is invoked with a URI referencing the fdset and an offset where to start reading or writing the data stream, e.g. {"execute":"migrate", "arguments":{"detach":true,"resume":false, "uri":"file:/dev/fdset/0,offset=0x11921"}} The mapped-ram stream, in conjunction with direct IO and multifd, can significantly improve the time required to save VM memory state. The following tables compare mapped-ram with the existing, sequential save stream. In all cases, the save and restore operations are to/from a block device comprised of two NVMe disks in RAID0 configuration with xfs (~8600MiB/s). The values in the 'save time' and 'restore time' columns were scraped from the 'real' time reported by time(1). The 'Size' and 'Blocks' columns were provided by the corresponding outputs of stat(1). VM: 32G RAM, 1 vcpu, idle (shortly after boot) | save | restore | | time | time | Size | Blocks -----------------------+---------+---------+--------------+-------- legacy | 6.193s | 4.399s | 985744812 | 1925288 -----------------------+---------+---------+--------------+-------- mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472 -----------------------+---------+---------+--------------+-------- legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328 -----------------------+---------+---------+--------------+-------- mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304 -----------------------+---------+---------+--------------+-------- mapped-ram + direct IO | | | | + multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312 ------------------------------------------------------------------- VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory | save | restore | | time | time | Size | Blocks -----------------------+---------+---------+--------------+--------- legacy | 25.800s | 14.332s | 33154309983 | 64754512 -----------------------+---------+---------+--------------+--------- mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160 -----------------------+---------+---------+--------------+--------- legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520 -----------------------+---------+---------+--------------+--------- mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040 -----------------------+-------- +---------+--------------+--------- mapped-ram + direct IO | | | | + multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776 -------------------------------------------------------------------- As can be seen from the tables, one caveat of mapped-ram is the logical file size of a saved image is basically equivalent to the VM memory size. Note however that mapped-ram typically uses fewer blocks on disk. Support for mapped-ram+direct-io only recently landed in upstream QEMU and will first appear in the 9.1 release, which may complicate merging support in libvirt. Specifically, I'm not sure how to detect if the combination is supported by QEMU. Suggestions welcomed. Similar to the RFC, V1 ignores compression. libvirt currently supports compression by connecting the output of QEMU's save stream to the specified compression program via a pipe. This approach is incompatible with mapped-ram since the fd provided to QEMU must be seekable. In general, we can consider mapped-ram and compression incompatible and document they cannot be used together. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/EF6… [2] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/map… [3] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/K4B… Claudio Fontana (2): include: Define constants for parallel save/restore tools: add parallel parameter to virsh restore command Jim Fehlig (17): lib: virDomainSaveParams: Ensure absolute save path qemu_fd: Add function to retrieve fdset ID qemu: Add function to check capability in migration params qemu: Add function to get bool value from migration params qemu: Add mapped-ram migration capability qemu: Add function to get migration params for save qemu: QEMU_SAVE_VERSION: Bump to version 3 qemu: conf: Add setting for save image version qemu: Add helper function for creating save image fd qemu: Add support for mapped-ram on save qemu: Decompose qemuSaveImageOpen qemu: Move creation of qemuProcessIncomingDef struct qemu: Apply migration parameters in qemuMigrationDstRun qemu: Add support for mapped-ram on restore qemu: Support O_DIRECT with mapped-ram on save qemu: Support O_DIRECT with mapped-ram on restore qemu: Add support for parallel save and restore Li Zhang (1): tools: add parallel parameter to virsh save command docs/manpages/virsh.rst | 9 +- include/libvirt/libvirt-domain.h | 13 ++ src/libvirt-domain.c | 52 +++++-- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 6 + src/qemu/qemu_conf.c | 16 +++ src/qemu/qemu_conf.h | 5 + src/qemu/qemu_driver.c | 104 +++++++++----- src/qemu/qemu_fd.c | 18 +++ src/qemu/qemu_fd.h | 3 + src/qemu/qemu_migration.c | 192 +++++++++++++++++-------- src/qemu/qemu_migration.h | 9 +- src/qemu/qemu_migration_params.c | 86 ++++++++++++ src/qemu/qemu_migration_params.h | 17 +++ src/qemu/qemu_monitor.c | 39 ++++++ src/qemu/qemu_monitor.h | 5 + src/qemu/qemu_process.c | 120 +++++++++++----- src/qemu/qemu_process.h | 19 ++- src/qemu/qemu_saveimage.c | 216 ++++++++++++++++++++--------- src/qemu/qemu_saveimage.h | 35 +++-- src/qemu/qemu_snapshot.c | 26 ++-- src/qemu/test_libvirtd_qemu.aug.in | 1 + tools/virsh-domain.c | 79 +++++++++-- 23 files changed, 827 insertions(+), 244 deletions(-) -- 2.35.3

4 47

[PATCH] NEWS: Document some of my fixes in this release
by Jiri Denemark 15 Jan '25

15 Jan '25

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 15042595ed..1d3e3c3cff 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -61,6 +61,19 @@ v11.0.0 (unreleased) schema. This is now fixed by not parsing any specified features when the passthrough mode is used. + * qemu: Fix a crash when starting a domain with ovs bridge and QOS + + * cpu: Add missing -v1 variants for CPU models + + Some CPU models (mostly old ones) were missed when versioned CPU model + names were introduced in the previous release. + + * qemu: Fix false error when recovering failed post-copy migration + + In some cases libvirt would report a failure to recover post-copy migration + even though the recovery started just fine and migration would eventually + successfully finish. + v10.10.0 (2024-12-02) ===================== -- 2.47.1

2 1

[PATCH] NEWS: Add few things I changed this release
by Martin Kletzander 15 Jan '25

15 Jan '25

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 9f0804ec67ff..02679602cc6a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,10 @@ v11.0.0 (unreleased) * **New features** + * qemu: Add support for direct and extended tlbflush features + + Domains can now utilise more tlbflush hyperv features. + * **Improvements** * ch: Enable user aliases @@ -42,6 +46,14 @@ v11.0.0 (unreleased) Fix a possible crash when starting a transient domain which was introduced in the previous release. + * qemu: Do not format invalid XML with hyperv features in passthrough mode + + When hyperv features were specified together with ``mode="passthrough"`` + libvirt parsed and formatted such features in the domain XML even though + they were not used at all, resulting in XML that is not valid based on our + schema. This is now fixed by not parsing any specified features when the + passthrough mode is used. + v10.10.0 (2024-12-02) ===================== -- 2.48.0

2 1

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 15 Jan '25

15 Jan '25

There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index eedb6008bd..9f0804ec67 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -19,6 +19,22 @@ v11.0.0 (unreleased) * **Improvements** + * ch: Enable user aliases + + User can now specify custom aliases for devices in domain XML + + * qemu: Grab a QUERY job when formatting domain XML + + Under some specific conditions it might have happened that domain XML did + not contain runtime information or returned an XML that's in process of + changing (e.g. by a thread that's hotplugging a device). Formatting domain + XML now serializes properly with other threads. + + * virtiofs: Allow read only mode + + The ``<filesystem/>`` with `virtiofsd` backend can now use ``<readonly/>`` + tag to export underlying filesystem in read only mode. + * **Bug fixes** * qemu: tpm: do not update profile name for transient domains -- 2.45.2

2 1

[libvirt PATCH] NEWS: document bug fix for snapshots
by Pavel Hrdina 14 Jan '25

14 Jan '25

Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- NEWS.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 08d1d24d48..98f489dfb0 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -21,6 +21,13 @@ v11.0.0 (unreleased) * **Bug fixes** + * qemu: Fix snapshot to not delete disk image with internal snapshot + + When a VM has internal snapshot that is parent to external snapshot and user + reverts to the internal snapshot and deletes the external snapshot Libvirt + would delete the disk image containing the internal snapshot. This would result + in data loss. + v10.10.0 (2024-12-02) ===================== -- 2.47.1

2 1

[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

[PATCH v4 0/4] iproute2 bridge vlan support
by Leigh Brown 11 Jan '25

11 Jan '25

I have incorporated Laine's feedback and added Reviewed-by tags. I also noticed that I hadn't updated the patch series description, so I updated it to reflect the change to using netlink, for posterity. Description ----------- The iproute2 bridge command supports the capability for VLAN filtering that allows each interface connected to a standard linux bridge to be configured to use one or more VLANs. For simple setups, this capability is enough to allow virtual machines or containers to be put onto separate VLANs without creating multiple bridges and VLANs on the host. The first patch adds a new function virNetDevBridgeVlanFilterSet that allows a VLAN filter to be added or removed from an interface associated with a bridge. The second patch adds virNetDevBridgeSetupVlans that will, given a virNetDevVlan structure, call virNetDevBridgeVlanFilterSet to apply the required VLAN filtering for the given interface. The third patch adjusts the domain and network validation to permit standard linux bridges to allow VLAN configuration and updates calls to virNetDevBridgeAddPort to pass the VLAN configuration. The fourth patch updates documentation to match the new capability. Changes since v3 ---------------- - Update patch series description. - Fix coding style. - Add G_GNUC_UNUSED annotation to virNetDevBridgeAddPort for MacOS. Changes since v2 ---------------- - Convert to use netlink rather than executing bridge vlan commands. - Add unsupported on this platform error message on FreeBSD. Changes since v1 ---------------- - Fix bug in virNetDevSetupVlans where bridge port has no native vlan. - Update bridge network validation to permit vlan configuration. - Update documentation to match the functionality. - Tweak some of the commit descriptions for clarity. Usage example ------------- Configure the host with systemd-networkd as follows: /etc/systemd/network/br0.netdev (br0.network not shown) [NetDev] Name=br0 Kind=bridge MACAddress=xx:xx:xx:xx:xx:xx [Bridge] VLANFiltering=on /etc/systemd/network/eno1.network [Match] Name=eno1 [Network] Bridge=br0 [Link] MTUBytes=9000 [BridgeVLAN] VLAN=40 [BridgeVLAN] VLAN=60 Then add <vlan> tags into the lxc or qemu config: lxc interface definition: <interface type='bridge'> <mac address='xx:xx:xx:xx:xx:xx'/> <source bridge='br0'/> <vlan> <tag id='40'/> </vlan> </interface> qemu interface definition: <interface type='network'> <mac address='xx:xx:xx:xx:xx:xx'/> <source network='br0'/> <vlan> <tag id='60'/> </vlan> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> Then, after starting them, you will see the following $ sudo bridge vlan port vlan-id eno1 1 PVID Egress Untagged 40 60 br0 1 PVID Egress Untagged vnet0 60 PVID Egress Untagged vnet1 40 PVID Egress Untagged Regards, Leigh Brown (4): util: add netlink bridge vlan filtering util: Add vlan support to virNetDevBridgeAddPort Enable vlan support for standard linux bridges docs: standard linux bridges now support vlans docs/formatdomain.rst | 37 +++++++++--------- docs/formatnetwork.rst | 45 +++++++++++----------- src/conf/domain_validate.c | 3 +- src/lxc/lxc_process.c | 2 +- src/network/bridge_driver.c | 13 ++++--- src/util/virnetdevbridge.c | 75 +++++++++++++++++++++++++++++++++++-- src/util/virnetdevbridge.h | 4 +- src/util/virnetdevtap.c | 2 +- src/util/virnetlink.c | 66 ++++++++++++++++++++++++++++++++ src/util/virnetlink.h | 7 ++++ 10 files changed, 201 insertions(+), 53 deletions(-) -- 2.39.5

3 8

[libvirt PATCH] qemu: snapshot: delete disk image only if parent snapshot is external
by Pavel Hrdina 11 Jan '25

11 Jan '25

When we are deleting external snapshot that is not active we only need to delete overlay disk image of the parent snapshot. This works correctly even if parent snapshot is external and active as it will have another overlay created when user reverted to that snapshot. In case the parent snapshot is internal there are no overlay disk images created as everything is stored internally within the disk image. In this case we would delete the actual disk image storing internal snapshots and most likely the original disk image as well resulting in data loss once the VM is shutoff. Fixes: https://gitlab.com/libvirt/libvirt/-/issues/734 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_snapshot.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 18b2e478f6..80cd54bf33 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -3144,6 +3144,8 @@ qemuSnapshotDeleteExternalPrepareData(virDomainObj *vm, return -1; } + data->parentSnap = qemuSnapshotFindParentSnapForDisk(snap, data->snapDisk); + if (data->merge) { virStorageSource *snapDiskSrc = NULL; @@ -3185,8 +3187,6 @@ qemuSnapshotDeleteExternalPrepareData(virDomainObj *vm, qemuSnapshotGetDisksWithBackingStore(vm, snap, data); } - data->parentSnap = qemuSnapshotFindParentSnapForDisk(snap, data->snapDisk); - if (data->parentSnap && !virDomainSnapshotIsExternal(data->parentSnap)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", _("deleting external snapshot that has internal snapshot as parent not supported")); @@ -3642,10 +3642,12 @@ qemuSnapshotDiscardExternal(virDomainObj *vm, if (!data->job) goto error; } else { - if (virStorageSourceInit(data->parentDomDisk->src) < 0 || - virStorageSourceUnlink(data->parentDomDisk->src) < 0) { - VIR_WARN("Failed to remove snapshot image '%s'", - data->snapDisk->name); + if (data->parentSnap && virDomainSnapshotIsExternal(data->parentSnap)) { + if (virStorageSourceInit(data->parentDomDisk->src) < 0 || + virStorageSourceUnlink(data->parentDomDisk->src) < 0) { + VIR_WARN("Failed to remove snapshot image '%s'", + data->snapDisk->name); + } } } } -- 2.47.1

2 2

[PATCH 0/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Akio Kakuno 10 Jan '25

10 Jan '25

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 suppor is no yet merged, but I would like to receive reviews and comments on the overall direction. [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. [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, which qemu does not yet support. Therefore, I put a hack in the code at hand and only confirmed the communication. Also, I think we should check whether CPUFW supports CCA or not in qemu_firmware.c, but it is not yet implemented. - Verified that the CCA VM can be started from 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 based on Linaro's qemu(9.1.91). https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/v3?ref_type=heads Signed-off-by: Akio Kakuno <fj3333bs(a)fujitsu.com> Best Regards. Akio Kakuno (1): RFC: Add Arm CCA support for getting capability information and running Realm VM docs/formatdomain.rst | 28 ++++++ docs/formatdomaincaps.rst | 26 ++++- src/conf/domain_capabilities.c | 41 ++++++++ src/conf/domain_capabilities.h | 12 +++ src/conf/domain_conf.c | 13 +++ src/conf/domain_conf.h | 7 ++ src/conf/schemas/domaincaps.rng | 14 +++ src/conf/schemas/domaincommon.rng | 14 +++ src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 156 ++++++++++++++++++++++++++++++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 32 ++++++ src/qemu/qemu_driver.c | 2 + src/qemu/qemu_monitor.c | 10 ++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 104 ++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 7 ++ 22 files changed, 487 insertions(+), 1 deletion(-) -- 2.34.1

3 3

[PATCH] Passing a domain XML to a polkit rule engine
by Takuya Nakaike 10 Jan '25

10 Jan '25

This patch is a draft implementation to pass a domain XML to a polkit access driver. With this new feature, a polkit rule can verify the domain XML to be deployed on a host, and thus protect deploying a malicious VM. There is a discussion about this new feature in the following issue. https://gitlab.com/libvirt/libvirt/-/issues/719 Any question, comment, and suggestion are welcome. Thanks, Signed-off-by: Takuya Nakaike <nakaike(a)jp.ibm.com> --- src/access/viraccessdriverpolkit.c | 2 ++ src/access/viraccessmanager.c | 22 ++++++++++++++++++++++ src/access/viraccessmanager.h | 3 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 3 +++ 5 files changed, 31 insertions(+) diff --git a/src/access/viraccessdriverpolkit.c b/src/access/viraccessdriverpolkit.c index 83381183a5..56457010e0 100644 --- a/src/access/viraccessdriverpolkit.c +++ b/src/access/viraccessdriverpolkit.c @@ -177,10 +177,12 @@ virAccessDriverPolkitCheckDomain(virAccessManager *manager, virAccessPermDomain perm) { char uuidstr[VIR_UUID_STRING_BUFLEN]; + char *xml = virAccessManagerGetXMLDesc(domain); const char *attrs[] = { "connect_driver", driverName, "domain_name", domain->name, "domain_uuid", uuidstr, + "xml", xml != NULL ? xml : "", NULL, }; virUUIDFormat(domain->uuid, uuidstr); diff --git a/src/access/viraccessmanager.c b/src/access/viraccessmanager.c index 6d9fdee5f1..7be31eb19a 100644 --- a/src/access/viraccessmanager.c +++ b/src/access/viraccessmanager.c @@ -44,11 +44,13 @@ struct _virAccessManager { virObjectLockable parent; virAccessDriver *drv; + virDomainXMLOption *xmlopt; void *privateData; }; static virClass *virAccessManagerClass; static virAccessManager *virAccessManagerDefault; +static virDomainXMLOption *virAccessManagerXMLOption = NULL; static void virAccessManagerDispose(void *obj); @@ -376,3 +378,23 @@ int virAccessManagerCheckStorageVol(virAccessManager *manager, return virAccessManagerSanitizeError(ret, driverName); } + +virDomainXMLOption *virAccessManagerGetXMLOption(void) +{ + return virAccessManagerXMLOption; +} + +void virAccessManagerSetXMLOption(virDomainXMLOption *xmlopt) +{ + virObjectUnref(virAccessManagerXMLOption); + + virAccessManagerXMLOption = virObjectRef(xmlopt); +} + +char *virAccessManagerGetXMLDesc(virDomainDef *domain) +{ + if (virAccessManagerGetXMLOption() != NULL) { + return virDomainDefFormat(domain, virAccessManagerGetXMLOption(), 0); + } + return NULL; +} diff --git a/src/access/viraccessmanager.h b/src/access/viraccessmanager.h index 2050ac9b85..3516f4f8e4 100644 --- a/src/access/viraccessmanager.h +++ b/src/access/viraccessmanager.h @@ -94,3 +94,6 @@ int virAccessManagerCheckStorageVol(virAccessManager *manager, virStoragePoolDef *pool, virStorageVolDef *vol, virAccessPermStorageVol perm); +virDomainXMLOption *virAccessManagerGetXMLOption(void); +void virAccessManagerSetXMLOption(virDomainXMLOption *xmlopt); +char *virAccessManagerGetXMLDesc(virDomainDef *domain); diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 33b93cbd3e..8bcbc9c478 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -19,6 +19,7 @@ virAccessManagerGetDefault; virAccessManagerNew; virAccessManagerNewStack; virAccessManagerSetDefault; +virAccessManagerSetXMLOption; # access/viraccessperm.h diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d2eddbd9ae..f9880f8ee3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -105,6 +105,7 @@ #include "virdomaincheckpointobjlist.h" #include "virutil.h" #include "backup_conf.h" +#include "viraccessmanager.h" #define VIR_FROM_THIS VIR_FROM_QEMU @@ -835,6 +836,8 @@ qemuStateInitialize(bool privileged, defsecmodel))) goto error; + virAccessManagerSetXMLOption(qemu_driver->xmlopt); + qemu_driver->nbdkitCapsCache = qemuNbdkitCapsCacheNew(cfg->cacheDir); /* If hugetlbfs is present, then we need to create a sub-directory within -- 2.43.5

2 1

[PATCH 0/2] storage_file: De-modularize the 'fs' backend
by Peter Krempa 10 Jan '25

10 Jan '25

See 1/2 for rationale. Peter Krempa (2): storage_file: de-modularize the local file backend NEWS: Mention de-modularization of the 'fs' storage file backend NEWS.rst | 9 +++++++++ libvirt.spec.in | 1 - src/storage_file/meson.build | 16 ---------------- src/storage_file/storage_file_backend.c | 11 ++++++----- 4 files changed, 15 insertions(+), 22 deletions(-) -- 2.47.1

2 4

[PATCH] docs: Clarify documentation of host-model CPU mode
by Jiri Denemark 10 Jan '25

10 Jan '25

The host-model CPU mode was described as similar to copying the host CPU definition from capabilities, which has not been the case for ages. The host-model definition from domain capabilities is used instead. Only the first sentence changed, but it required reformatting essentially the whole paragraph so I used this as an opportunity to reformat it a little bit more and split the long paragraph into several smaller ones for better readability. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- docs/formatdomain.rst | 68 ++++++++++++++++++++++++------------------- 1 file changed, 38 insertions(+), 30 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 02c5361905..00acf7aa91 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -1482,38 +1482,46 @@ In case no restrictions need to be put on CPU model and its features, a simpler presented to the guest. This is the default when no ``mode`` attribute is specified. This mode makes it so that a persistent guest will see the same hardware no matter what host the guest is booted on. + ``host-model`` - The ``host-model`` mode is essentially a shortcut to copying host CPU - definition from capabilities XML into domain XML. Since the CPU definition - is copied just before starting a domain, exactly the same XML can be used - on different hosts while still providing the best guest CPU each host - supports. The ``match`` attribute can't be used in this mode. Specifying - CPU model is not supported either, but ``model``'s ``fallback`` attribute - may still be used. Using the ``feature`` element, specific flags may be - enabled or disabled specifically in addition to the host model. This may - be used to fine tune features that can be emulated. :since:`(Since 1.1.1)` - . Libvirt does not model every aspect of each CPU so the guest CPU will - not match the host CPU exactly. On the other hand, the ABI provided to the + The ``host-model`` mode is essentially a shortcut to copying host-model + CPU definition from `domain capabilities XML + <formatdomaincaps.html#cpu-configuration>`__ into domain XML. Since the + CPU definition is copied just before starting a domain, exactly the same + XML can be used on different hosts while still providing the best guest + CPU each host supports. The ``match`` attribute can't be used in this + mode. Specifying CPU model is not supported either, but ``model``'s + ``fallback`` attribute may still be used. Using the ``feature`` element, + specific flags may be enabled or disabled specifically in addition to the + host model. This may be used to fine tune features that can be emulated. + :since:`(Since 1.1.1)` + + Libvirt does not model every aspect of each CPU so the guest CPU will not + match the host CPU exactly. On the other hand, the ABI provided to the guest is reproducible. During migration, complete CPU model definition is - transferred to the destination host so the migrated guest will see exactly - the same CPU model for the running instance of the guest, even if the - destination host contains more capable CPUs or newer kernel; but shutting - down and restarting the guest may present different hardware to the guest - according to the capabilities of the new host. Prior to libvirt 3.2.0 and - QEMU 2.9.0 detection of the host CPU model via QEMU is not supported. Thus - the CPU configuration created using ``host-model`` may not work as - expected. :since:`Since 3.2.0 and QEMU 2.9.0` this mode works the way it - was designed and it is indicated by the ``fallback`` attribute set to - ``forbid`` in the host-model CPU definition advertised in `domain - capabilities XML <formatdomaincaps.html#cpu-configuration>`__. When - ``fallback`` attribute is set to ``allow`` in the domain capabilities - XML, it is recommended to use ``custom`` mode with just the CPU model - from the host capabilities XML. :since:`Since 1.2.11` PowerISA allows - processors to run VMs in binary compatibility mode supporting an older - version of ISA. Libvirt on PowerPC architecture uses the ``host-model`` - to signify a guest mode CPU running in binary compatibility mode. - Example: When a user needs a power7 VM to run in compatibility mode on a - Power8 host, this can be described in XML as follows : + transferred to the destination host so the migrated guest will see + exactly the same CPU model for the running instance of the guest, even if + the destination host contains more capable CPUs or newer kernel; but + shutting down and restarting the guest may present different hardware to + the guest according to the capabilities of the new host. + + Prior to libvirt 3.2.0 and QEMU 2.9.0 detection of the host CPU model via + QEMU is not supported. Thus the CPU configuration created using + ``host-model`` may not work as expected. :since:`Since 3.2.0 and QEMU + 2.9.0` this mode works the way it was designed and it is indicated by the + ``fallback`` attribute set to ``forbid`` in the host-model CPU definition + advertised in `domain capabilities XML + <formatdomaincaps.html#cpu-configuration>`__. When ``fallback`` attribute + is set to ``allow`` in the domain capabilities XML, it is recommended to + use ``custom`` mode with just the CPU model from the host capabilities + XML. + + :since:`Since 1.2.11` PowerISA allows processors to run VMs in binary + compatibility mode supporting an older version of ISA. Libvirt on + PowerPC architecture uses the ``host-model`` to signify a guest mode CPU + running in binary compatibility mode. Example: When a user needs a power7 + VM to run in compatibility mode on a Power8 host, this can be described + in XML as follows: :: -- 2.47.1

2 1

[PATCH] spec: Disable ch driver on RHEL
by Jiri Denemark 09 Jan '25

09 Jan '25

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index eb8b35da76..2bc8dfd323 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -133,6 +133,7 @@ %define with_libxl 0 %define with_hyperv 0 %define with_lxc 0 + %define with_ch 0 %endif %define with_firewalld_zone 0%{!?_without_firewalld_zone:1} -- 2.47.1

2 1

[PATCH] rpc: log details of OS signals received by daemon
by Daniel P. Berrangé 09 Jan '25

09 Jan '25

When debugging it is useful to know what signals are being received and metadata related to them. Log this data before calling the signal handling callbacks. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/rpc/virnetdaemon.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/rpc/virnetdaemon.c b/src/rpc/virnetdaemon.c index e4c6261536..94c23e973f 100644 --- a/src/rpc/virnetdaemon.c +++ b/src/rpc/virnetdaemon.c @@ -562,6 +562,10 @@ virNetDaemonSignalEvent(int watch, virNetDaemonSignalFunc func = dmn->signals[i]->func; void *funcopaque = dmn->signals[i]->opaque; virObjectUnlock(dmn); + VIR_DEBUG("Dispatch signal num=%d errno=%d code=%d pid=%llu uid=%llu status=%d", + siginfo.si_signo, siginfo.si_errno, siginfo.si_code, + (unsigned long long)siginfo.si_pid, (unsigned long long)siginfo.si_uid, + siginfo.si_status); func(dmn, &siginfo, funcopaque); return; } -- 2.47.1

2 1

[PATCH] util: don't attempt to acquire logind inhibitor if not requested
by Daniel P. Berrangé 09 Jan '25

09 Jan '25

When VIR_INHIBITOR_WHAT_NONE is passed to virInhibitorNew, it is an indication that daemon shutdown should be inhibited, but no OS level inhibitors acquired. This is done by the virtnetworkd daemon, for example, to prevent shutdown while running virtual machines are present, without blocking / delaying OS shutdown. Unfortunately the code forgot to skip the DBus call in this case, resulting in errors being logged. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/util/virinhibitor.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/util/virinhibitor.c b/src/util/virinhibitor.c index 647bdc9fbb..a95021de5a 100644 --- a/src/util/virinhibitor.c +++ b/src/util/virinhibitor.c @@ -152,7 +152,7 @@ virInhibitor *virInhibitorNew(virInhibitorWhat what, virInhibitor *inhibitor = g_new0(virInhibitor, 1); inhibitor->fd = -1; - inhibitor->what = virInhibitorWhatFormat(what); + inhibitor->what = what ? virInhibitorWhatFormat(what) : NULL; inhibitor->who = g_strdup(who); inhibitor->why = g_strdup(why); inhibitor->mode = virInhibitorModeTypeToString(mode); @@ -171,7 +171,8 @@ void virInhibitorHold(virInhibitor *inhibitor) inhibitor->action(true, inhibitor->actionData); } #ifdef G_OS_UNIX - if (virInhibitorAcquire( + if (inhibitor->what && + virInhibitorAcquire( inhibitor->what, inhibitor->who, inhibitor->why, inhibitor->mode, &inhibitor->fd) < 0) { VIR_ERROR(_("Failed to acquire inhibitor: %1$s"), -- 2.47.1

2 1

[PATCH v5 0/4] iproute2 bridge vlan support
by Leigh Brown 09 Jan '25

09 Jan '25

Very sorry, I blindly fixed the lack of braces on the multiline if statements pointed out by Laine, but didn't check for others. I have now fixed up the remaining ones. Description ----------- The iproute2 bridge command supports the capability for VLAN filtering that allows each interface connected to a standard linux bridge to be configured to use one or more VLANs. For simple setups, this capability is enough to allow virtual machines or containers to be put onto separate VLANs without creating multiple bridges and VLANs on the host. The first patch adds a new function virNetDevBridgeVlanFilterSet that allows a VLAN filter to be added or removed from an interface associated with a bridge. The second patch adds virNetDevBridgeSetupVlans that will, given a virNetDevVlan structure, call virNetDevBridgeVlanFilterSet to apply the required VLAN filtering for the given interface. The third patch adjusts the domain and network validation to permit standard linux bridges to allow VLAN configuration and updates calls to virNetDevBridgeAddPort to pass the VLAN configuration. The fourth patch updates documentation to match the new capability. Changes since v4 ---------------- - Fix the remaining examples of missing braces in virNetDevBridgeSetupVlans. Changes since v3 ---------------- - Update patch series description. - Fix coding style. - Add G_GNUC_UNUSED annotation to virNetDevBridgeAddPort for MacOS. Changes since v2 ---------------- - Convert to use netlink rather than executing bridge vlan commands. - Add unsupported on this platform error message on FreeBSD. Changes since v1 ---------------- - Fix bug in virNetDevSetupVlans where bridge port has no native vlan. - Update bridge network validation to permit vlan configuration. - Update documentation to match the functionality. - Tweak some of the commit descriptions for clarity. Usage example ------------- Configure the host with systemd-networkd as follows: /etc/systemd/network/br0.netdev (br0.network not shown) [NetDev] Name=br0 Kind=bridge MACAddress=xx:xx:xx:xx:xx:xx [Bridge] VLANFiltering=on /etc/systemd/network/eno1.network [Match] Name=eno1 [Network] Bridge=br0 [Link] MTUBytes=9000 [BridgeVLAN] VLAN=40 [BridgeVLAN] VLAN=60 Then add <vlan> tags into the lxc or qemu config: lxc interface definition: <interface type='bridge'> <mac address='xx:xx:xx:xx:xx:xx'/> <source bridge='br0'/> <vlan> <tag id='40'/> </vlan> </interface> qemu interface definition: <interface type='network'> <mac address='xx:xx:xx:xx:xx:xx'/> <source network='br0'/> <vlan> <tag id='60'/> </vlan> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> Then, after starting them, you will see the following $ sudo bridge vlan port vlan-id eno1 1 PVID Egress Untagged 40 60 br0 1 PVID Egress Untagged vnet0 60 PVID Egress Untagged vnet1 40 PVID Egress Untagged Regards, Leigh Brown (4): util: add netlink bridge vlan filtering util: Add vlan support to virNetDevBridgeAddPort Enable vlan support for standard linux bridges docs: standard linux bridges now support vlans docs/formatdomain.rst | 37 +++++++++--------- docs/formatnetwork.rst | 45 +++++++++++----------- src/conf/domain_validate.c | 3 +- src/lxc/lxc_process.c | 2 +- src/network/bridge_driver.c | 13 ++++--- src/util/virnetdevbridge.c | 77 +++++++++++++++++++++++++++++++++++-- src/util/virnetdevbridge.h | 4 +- src/util/virnetdevtap.c | 2 +- src/util/virnetlink.c | 66 +++++++++++++++++++++++++++++++ src/util/virnetlink.h | 7 ++++ 10 files changed, 203 insertions(+), 53 deletions(-) -- 2.39.5

2 5