April 2022 - Devel - libvirt List Archives

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

Re: [libvirt] [Qemu-devel] Qemu migration with vhost-user-blk on top of local storage
by Stefan Hajnoczi 27 Oct '23

27 Oct '23

On Wed, Jan 09, 2019 at 06:23:42PM +0800, wuzhouhui wrote: > Hi everyone, > > I'm working qemu with vhost target (e.g. spdk), and I attempt to migrate VM with > 2 local storages. One local storage is a regular file, e.g. /tmp/c74.qcow2, and > the other is a malloc bdev that spdk created. This malloc bdev will exported to > VM via vhost-user-blk. When I execute following command: > > virsh migrate --live --persistent --unsafe --undefinesource --copy-storage-all \ > --p2p --auto-converge --verbose --desturi qemu+tcp://<uri>/system vm0 > > The libvirt reports: > > qemu-2.12.1: error: internal error: unable to execute QEMU command \ > 'nbd-server-add': Cannot find device=drive-virtio-disk1 nor \ > node_name=drive-virtio-disk1 Please post your libvirt domain XML. > Does it means that qemu with spdk on top of local storage don't support migration? > > QEMU: 2.12.1 > SPDK: 18.10 vhost-user-blk bypasses the QEMU block layer, so NBD storage migration at the QEMU level will not work for the vhost-user-blk disk. Stefan

4 4

[libvirt] [PATCH v3] openvswitch: Add new port VLAN mode "dot1q-tunnel"
by luzhipeng＠uniudc.com 27 Oct '23

27 Oct '23

From: ZhiPeng Lu <luzhipeng(a)uniudc.com> Signed-off-by: ZhiPeng Lu <luzhipeng(a)uniudc.com> --- v1->v2: 1. Fix "make syntax-check" failure v2->v3: 1. remove other_config when updating vlan docs/formatnetwork.html.in | 17 +++++++++-------- docs/schemas/networkcommon.rng | 1 + src/conf/netdev_vlan_conf.c | 2 +- src/util/virnetdevopenvswitch.c | 7 +++++++ src/util/virnetdevvlan.h | 1 + 5 files changed, 19 insertions(+), 9 deletions(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 363a72b..3c1ae62 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -688,16 +688,17 @@ For network connections using Open vSwitch it is also possible - to configure 'native-tagged' and 'native-untagged' VLAN modes + to configure 'native-tagged' and 'native-untagged' and 'dot1q-tunnel' + VLAN modes. Since 1.1.0. This is done with the - optional <code>nativeMode</code> attribute on - the <code><tag></code> subelement: <code>nativeMode</code> - may be set to 'tagged' or 'untagged'. The <code>id</code> - attribute of the <code><tag></code> subelement - containing <code>nativeMode</code> sets which VLAN is considered - to be the "native" VLAN for this interface, and + optional <code>nativeMode</code> attribute on the + <code><tag></code> subelement: <code>nativeMode</code> + may be set to 'tagged' or 'untagged' or 'dot1q-tunnel'. + The <code>id</code> attribute of the <code><tag></code> + subelement containing <code>nativeMode</code> sets which VLAN is + considered to be the "native" VLAN for this interface, and the <code>nativeMode</code> attribute determines whether or not - traffic for that VLAN will be tagged. + traffic for that VLAN will be tagged or QinQ. <code><vlan></code> elements can also be specified in diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng index 2699555..11c48ff 100644 --- a/docs/schemas/networkcommon.rng +++ b/docs/schemas/networkcommon.rng @@ -223,6 +223,7 @@ <choice> <value>tagged</value> <value>untagged</value> + <value>dot1q-tunnel</value> </choice> </attribute> </optional> diff --git a/src/conf/netdev_vlan_conf.c b/src/conf/netdev_vlan_conf.c index dff49c6..79710d9 100644 --- a/src/conf/netdev_vlan_conf.c +++ b/src/conf/netdev_vlan_conf.c @@ -29,7 +29,7 @@ #define VIR_FROM_THIS VIR_FROM_NONE VIR_ENUM_IMPL(virNativeVlanMode, VIR_NATIVE_VLAN_MODE_LAST, - "default", "tagged", "untagged") + "default", "tagged", "untagged", "dot1q-tunnel") int virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr ctxt, virNetDevVlanPtr def) diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c index 8fe06fd..9fec30b 100644 --- a/src/util/virnetdevopenvswitch.c +++ b/src/util/virnetdevopenvswitch.c @@ -91,6 +91,11 @@ virNetDevOpenvswitchConstructVlans(virCommandPtr cmd, virNetDevVlanPtr virtVlan) virCommandAddArg(cmd, "vlan_mode=native-untagged"); virCommandAddArgFormat(cmd, "tag=%d", virtVlan->nativeTag); break; + case VIR_NATIVE_VLAN_MODE_DOT1Q_TUNNEL: + virCommandAddArg(cmd, "vlan_mode=dot1q-tunnel"); + virCommandAddArg(cmd, "other_config:qinq-ethtype=802.1q"); + virCommandAddArgFormat(cmd, "tag=%d", virtVlan->nativeTag); + break; case VIR_NATIVE_VLAN_MODE_DEFAULT: default: break; @@ -504,6 +509,8 @@ int virNetDevOpenvswitchUpdateVlan(const char *ifname, "--", "--if-exists", "clear", "Port", ifname, "tag", "--", "--if-exists", "clear", "Port", ifname, "trunk", "--", "--if-exists", "clear", "Port", ifname, "vlan_mode", + "--", "--if-exists", "remove", "Port", ifname, "other_config", + "qinq-ethtype", NULL, "--", "--if-exists", "set", "Port", ifname, NULL); if (virNetDevOpenvswitchConstructVlans(cmd, virtVlan) < 0) diff --git a/src/util/virnetdevvlan.h b/src/util/virnetdevvlan.h index be85f59..0667f9d 100644 --- a/src/util/virnetdevvlan.h +++ b/src/util/virnetdevvlan.h @@ -29,6 +29,7 @@ typedef enum { VIR_NATIVE_VLAN_MODE_DEFAULT = 0, VIR_NATIVE_VLAN_MODE_TAGGED, VIR_NATIVE_VLAN_MODE_UNTAGGED, + VIR_NATIVE_VLAN_MODE_DOT1Q_TUNNEL, VIR_NATIVE_VLAN_MODE_LAST } virNativeVlanMode; -- 1.8.3.1

3 2

[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang 27 Oct '23

27 Oct '23

Seems a backport miss. An extra member is passed to struct virLXCBasicMountInfo. Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn> --- src/lxc/lxc_container.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 28dabec..1c65fa9 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -760,7 +760,7 @@ typedef struct { static const virLXCBasicMountInfo lxcBasicMounts[] = { { "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false }, - { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false }, + { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false }, { "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false }, { "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true }, #if WITH_SELINUX -- 1.7.1

3 2

[libvirt] [PATCH] web docs -- macvtap mode explanation
by Stefan Berger 27 Oct '23

27 Oct '23

This adds more information about the different macvtap device modes. Regards, Stefan

3 2

[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori 27 Oct '23

27 Oct '23

Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd people that are who can throw tomatoes at me for getting bits wrong :-) I wanted to start a discussion about supporting vhost-net in libvirt. vhost-net has not yet been merged into qemu but I expect it will be soon so it's a good time to start this discussion. There are two modes worth supporting for vhost-net in libvirt. The first mode is where vhost-net backs to a tun/tap device. This is behaves in very much the same way that -net tap behaves in qemu today. Basically, the difference is that the virtio backend is in the kernel instead of in qemu so there should be some performance improvement. Current, libvirt invokes qemu with -net tap,fd=X where X is an already open fd to a tun/tap device. I suspect that after we merge vhost-net, libvirt could support vhost-net in this mode by just doing -net vhost,fd=X. I think the only real question for libvirt is whether to provide a user visible switch to use vhost or to just always use vhost when it's available and it makes sense. Personally, I think the later makes sense. The more interesting invocation of vhost-net though is one where the vhost-net device backs directly to a physical network card. In this mode, vhost should get considerably better performance than the current implementation. I don't know the syntax yet, but I think it's reasonable to assume that it will look something like -net tap,dev=eth0. The effect will be that eth0 is dedicated to the guest. On most modern systems, there is a small number of network devices so this model is not all that useful except when dealing with SR-IOV adapters. In that case, each physical device can be exposed as many virtual devices (VFs). There are a few restrictions here though. The biggest is that currently, you can only change the number of VFs by reloading a kernel module so it's really a parameter that must be set at startup time. I think there are a few ways libvirt could support vhost-net in this second mode. The simplest would be to introduce a new tag similar to <source network='br0'>. In fact, if you probed the device type for the network parameter, you could probably do something like <source network='eth0'> and have it Just Work. Another model would be to have libvirt see an SR-IOV adapter as a network pool whereas it handled all of the VF management. Considering how inflexible SR-IOV is today, I'm not sure whether this is the best model. Has anyone put any more thought into this problem or how this should be modeled in libvirt? Michael, could you share your current thinking for -net syntax? -- Regards, Anthony Liguori

8 26

[PATCH 00/18] RFC: Remove deprecated audio features
by Martin Kletzander 15 Sep '23

15 Sep '23

I wanted to deal with https://bugzilla.redhat.com/2043498 and I got a suggesstion that removing deprecated features could actually make it easier to propagate the error. In the end (last patch) it turns out the error is still just reported with error_fatal, so it probably is not really needed, but I really wanted to dig into QEMU more and learn some of the internals for quite some time now. So I used the opportunity. The one-liner ended up being an 18 patch series which was, for someone who has just one commit in QEMU codebase, a pretty challenging task. Although I tried my best to do things properly, I am not sure whether I handled everything correctly, hence the RFC. Any comments are very much appreciated. Thanks and have a nice day ;) Martin Kletzander (18): hw/audio: Remove -soundhw support hw/input/tsc210x: Extract common init code into new function hw/audio: Simplify hda audio init hw/audio/lm4549: Add errp error reporting to init function tests/qtest: Specify audiodev= and -audiodev ui/vnc: Require audiodev= Introduce machine's default-audiodev property audio: Add easy dummy audio initialiser hw/display/xlnx_dp.c: Add audiodev property hw/input/tsc210x.c: Support machine-default audiodev with fallback hw/arm: Support machine-default audiodev with fallback hw/ppc: Support machine-default audiodev with fallback audio: Make AUD_register_card fallible and require audiodev= audio: Require AudioState in AUD_add_capture audio: Be more strict during audio backend initialisation audio: Remove legacy audio environment variables and options audio: Remove unused can_be_default audio/spiceaudio: Fail initialisation when not using spice audio/alsaaudio.c | 1 - audio/audio.c | 204 +++---- audio/audio.h | 5 +- audio/audio_int.h | 1 - audio/audio_legacy.c | 555 ------------------ audio/coreaudio.m | 1 - audio/dbusaudio.c | 1 - audio/dsoundaudio.c | 1 - audio/jackaudio.c | 1 - audio/meson.build | 1 - audio/noaudio.c | 1 - audio/ossaudio.c | 1 - audio/paaudio.c | 1 - audio/sdlaudio.c | 1 - audio/spiceaudio.c | 3 +- audio/wavaudio.c | 1 - docs/about/deprecated.rst | 24 - docs/about/removed-features.rst | 27 + docs/qdev-device-use.txt | 21 +- docs/replay.txt | 2 +- hw/arm/integratorcp.c | 8 +- hw/arm/musicpal.c | 8 +- hw/arm/omap2.c | 11 +- hw/arm/realview.c | 3 + hw/arm/spitz.c | 10 +- hw/arm/versatilepb.c | 3 + hw/arm/vexpress.c | 3 + hw/arm/xlnx-zcu102.c | 4 + hw/arm/z2.c | 12 +- hw/audio/ac97.c | 9 +- hw/audio/adlib.c | 9 +- hw/audio/cs4231a.c | 8 +- hw/audio/es1370.c | 8 +- hw/audio/gus.c | 6 +- hw/audio/hda-codec.c | 37 +- hw/audio/intel-hda.c | 25 +- hw/audio/intel-hda.h | 2 +- hw/audio/lm4549.c | 7 +- hw/audio/lm4549.h | 3 +- hw/audio/meson.build | 1 - hw/audio/pcspk.c | 15 +- hw/audio/pl041.c | 2 +- hw/audio/sb16.c | 9 +- hw/audio/soundhw.c | 177 ------ hw/audio/wm8750.c | 5 +- hw/core/machine.c | 23 + hw/display/xlnx_dp.c | 12 +- hw/input/tsc210x.c | 79 ++- hw/ppc/prep.c | 4 + hw/usb/dev-audio.c | 5 +- include/hw/audio/soundhw.h | 15 - include/hw/boards.h | 1 + qemu-options.hx | 37 -- .../codeconverter/test_regexps.py | 1 - softmmu/qdev-monitor.c | 2 - softmmu/vl.c | 10 - tests/qtest/ac97-test.c | 3 +- tests/qtest/es1370-test.c | 3 +- tests/qtest/fuzz/generic_fuzz_configs.h | 6 +- tests/qtest/intel-hda-test.c | 15 +- ui/vnc.c | 15 +- 61 files changed, 329 insertions(+), 1140 deletions(-) delete mode 100644 audio/audio_legacy.c delete mode 100644 hw/audio/soundhw.c delete mode 100644 include/hw/audio/soundhw.h -- 2.35.1

5 43

Summary on new backup interfaces in QEMU
by Vladimir Sementsov-Ogievskiy 21 Feb '23

21 Feb '23

Hi all! Here I want to summarize new interfaces and use cases for backup in QEMU. TODO for me: convert this into good rst documentation in docs/. OK, let's begin. First, note that drive-backup qmp command is deprecated. Next, some terminology: push backup: the whole process is inside QEMU process, also may be called "internal backup" pull backup: QEMU only exports a kind of snapshot (for example by NBD), and third party software reads this export and stores it somehow, also called "external backup" copy-before-write operations: We usually do backup of active disk, guest is running and may write to the disk during the process of backup. When guest wants to rewrite data region which is not backed up yet, we must stop this guest write, and copy original data to somewhere before continuing guest write. That's a copy-before-write operation. image-fleecing: the technique that allows to export a "snapshotted" state of the active disk with help of copy-before-write operations. We create a temporary image - target for copy-before-write operations, and provide an interface to the user to read the "snapshotted" state. And for read, we do read from temporary image the data which is already changed in original active disk, and we read unchanged data directly from active disk. The temporary image itself is also called "reverse delta" or "reversed delta". == Simple push backup == Just use blockdev-backup, nothing new here. I just note some technical details, that are relatively new: 1. First, backup job inserts copy-before-write filter above source disk, to do copy-before-write operation. 2. Created copy-before-write filter shares internal block-copy state with backup job, so they work in collaboration, to not copy same things twice. == Full pull backup == Assume, we are going to do incremental backup in future, so we also need to create a dirty bitmap, to track dirtiness of active disk since full backup. 1. Create empty temporary image for fleecing. It must be of the same size as active disk. It's not necessary to be qcow2, and if it's a qcow2, you shouldn't make the original active disk a backing file for the new temporary qcow2 image (it was necessary in old fleecing scheme). Example: qemu-img create -f qcow2 temp.qcow2 64G 2. Initialize fleecing scheme and create dirty bitmap for future incremental backup. Assume, disk0 is an active disk, attached to qdev-id sda, to be backed up. qmp: transaction [ block-dirty-bitmap-add {node: disk0, name: bitmap0, persistent: true} blockdev-add* {node-name: tmp-protocol, driver: file, filename: temp.qcow2} blockdev-add {node-name: tmp, driver: qcow2, file: tmp-protocol} blockdev-add {node-name: cbw, driver: copy-before-write, file: disk0, target: tmp} blockdev-replace** {parent-type: qdev, qdev-id: sda, new-child: cbw} blockdev-add {node-name: acc, driver: snapshot-access, file: cbw} ] qmp: nbd-server-start {...} qmp: nbd-server-add {device: acc, ...} This way we create the following block-graph: [guest] [NBD export] | | | root | root v file v [copy-before-write]<------[snapshot-access] | | | file | target v v [active-disk] [temp.qcow2] * "[PATCH 0/2] blockdev-add transaction" series needed for this ** "[PATCH v3 00/11] blockdev-replace" series needed for this Note additional useful options for copy-before-write filter: "[PATCH 0/3] block: copy-before-write: on-cbw-error behavior" provides possibility of option on-cbw-error=break-snapshot, which means that on failure of CBW operation we will not break guest write, but instead all further reads by NBD client will fail, which formally means: break the backup process, not guest write. "[PATCH 0/4] block: copy-before-write: cbw-timeout" provides an option cbw-timeout, to set a timeout for CBW operations. That's very useful to avoid guest stuck. 3. Now third party backup tool can read data from NBD export NBD_CMD_TRIM (discard) operation is supported on the export, it has the following effects: 1. discard this data from temp image, if it is stored here 2. avoid further copy-before-write operation (guest is free to rewrite corresponding data with no extra latency) 3. all further read requests from discarded areas by NBD client will fail So, NBD client may discard regions that are already backed up to avoid extra latency for guest writes and to free disk space on the host. Possible TODO here is to implement NBD protocol extension, that allows to READ & DISCARD in command. In this case we avoid extra command in the wire, but lose possibility of retrying the READ operation if it failed. 4. After backup is complete, we should destroy the fleecing scheme: qmp: nbd-server-stop qmp: blockdev-del {node-name: acc} qmp: blockdev-replace {parent-type: qdev, qdev-id: sda, new-child: disk0} qmp: blockdev-del {node-name: cbw} qmp: blockdev-del {node-name: tmp} qmp: blockdev-del {node-name: tmp-protocol} 5. If backup failed, we should remove created dirty bitmap: qmp: block-dirty-bitmap-remove {node: disk0, name: bitmap0} == Incremental pull backup == OK, now we have a bitmap called bitmap0, and want to do incremental backup, accordingly to that bitmap. In short, we want: - create a new bitmap to continue dirty tracking for next incremental backup - export "snapshotted" state of disk0 through NBD - export "frozen" bitmap, so that external tool know what to copy Mostly, all points remains the same, let's go through: 1. Create empty temporary image for fleecing -- same as for full backup, no difference 2. Initialize fleecing scheme and create dirty bitmap for future incremental backup. qmp: transaction [ block-dirty-bitmap-add {node: disk0, name: bitmap1, persistent: true} block-dirty-bitmap-disable {node: disk0, name: bitmap0} blockdev-add {node-name: tmp-protocol, driver: file, filename: temp.qcow2} blockdev-add {node-name: tmp, driver: qcow2, file: tmp-protocol} blockdev-add {node-name: cbw, driver: copy-before-write, file: disk0, target: tmp, bitmap: {node: disk0, name: bitmap0}} blockdev-replace {parent-type: qdev, qdev-id: sda, new-child: cbw} blockdev-add {node-name: acc, driver: snapshot-access, file: cbw} ] qmp: nbd-server-start {...} qmp: block-export-add {type: nbd, node-name: acc, bitmaps: [{node: disk0, name: bitmap0}]} 3. Now third party backup tool can read data from NBD export - Client may negotiate meta contexts, to query exported dirty bitmap by NBD_BLOCK_STATUS commend - If client reads "not-dirty" (by bitmap0) areas, it gets an error. - NBD_CMD_TRIM (discard) works as for full backup, no difference 4. After backup is complete, we should destroy the fleecing scheme: - Same as for full backup 5. Next, we should handle dirty bitmaps: 5.1 Failure path Merge-back bitmap1 to bitmap0 and continue tracking in bitmap0: qmp: transaction [ block-dirty-bitmap-enable {node: disk0, name: bitmap0} block-dirty-bitmap-merge {node: disk0, target: bitmap0, bitmaps: ['bitmap1']} block-dirty-bitmap-remove {node: disk0, name: bitmap1} ] 5.2 Success path We have two possible user scenarios on success: 5.2.1 Continue tracking for next incremental backup in bitmap1 In this case, just remove bitmap0: qmp: block-dirty-bitmap-remove {node: disk0, name: bitmap0} Or you may not delete bitmap0 and keep it disabled, to be reused in future for differential backup (see below). 5.2.2 Continue tracking for next incremental backup in bitmap0 (assume, we always work with one bitmap and don't want any kind of differential backups, and don't associate bitmap name with stored backups) In this case, enable and clear bitmap0, merge bitmap1 to bitmap0 and remove bitmap1: qmp: transaction [ block-dirty-bitmap-enable {node: disk0, name: bitmap0} block-dirty-bitmap-clear {node: disk0, name: bitmap0} block-dirty-bitmap-merge {node: disk0, target: bitmap0, bitmaps: ['bitmap1']} block-dirty-bitmap-remove {node: disk0, name: bitmap1} ] == Push backup with fleecing full/incremental == Reasoning: the main problem of simple push backup is that guest writes may be seriously affected by copy-on-write operations, when backup target is slow. To solve this problem, we'll use the scheme like for pull backup: we create local temporary image, which is a target for copy-before-write operations, and instead of exporting the "snapshot-access" node we start internal backup from it to the target. So, the scheme and commands looks exactly the same as for full and incremental pull backup. The only difference is that we don't need to start nbd export, but instead we should add target node to qemu and start internal backup. And good thing is that it may be done in same transaction with initializing fleecing scheme: qmp: transaction [ ... initialize fleecing scheme for full or incremental backup ... # Add target node. Here is qcow2 added, but it may be nbd node or something else blockdev-add {node-name: target-protocol, driver: file, filename: target.qcow2} blockdev-add {node-name: target, driver: qcow2, file: target-protocol} # Start backup blockdev-backup {device: acc, target: target, ...} ] If it is an incremental backup, pass also bitmap parameter: blockdev-backup {..., bitmap: bitmap0, sync: incremental, bitmap-mode: never} Note bitmap-mode=never: this means that backup will do nothing with bitmap0, so we have same scheme like for pull backups (handle bitmaps by hand after backup). Still, push-backup scheme may be adopted to use other bitmap modes. What we lack here is discarding in 'acc' node after successful copying of the block to the target, to safe disk space and avoid extra copy-before-write operations. It's a TODO, should be implemented like discard-source parameter for blockdev-backup. == Differential backups == I'm not fan of this idea, but I think it should be described. Assume we have already a chain of incremental backups (represented as qcow2 chain on backup storage server, for example). They corresponds to some points in time: T0, T1, T2, T3. Assume T3 is the last backup. If we want to create usual incremental backup, it would be diff between T3 and current time (which becomes T4). Differential backup say: I want to make backup starting from T1 to current time. What's for? Maybe T2 and T3 was removed or somehow damaged.. How to do that in Qemu: on each incremental backup you start a new bitmap, and _keep_ old one as disabled. This way we have bitmap0 (which presents diff between T0 and T1), bitmap1 (diff T1 T2), bitmap2 (diff T2 T3), and bitmap3 which shows diff from T3 up to current time. bitmap3 is the only enabled bitmap and others are disabled. So, to make differential backup, use block-dirty-bitmap-merge command, to merge all bitmaps you need into one, and than use it in any backup scheme. The drawback is that all these disabled bitmaps eat RAM. Possible solution is to not keep them in RAM, it's OK to keep them in qcow2, and load only on demand. That's not realized now and that's a TODO for thous who want differential backups. -- Best regards, Vladimir

3 2

[libvirt] Semantic change in v4.3 slows down image creation and snapshots (on ZFS)
by Christian Ehrhardt 31 Jul '22

31 Jul '22

Hi, when discussing bug [1] triggered by [2] Daniel and I have found that the change [3] which is in since v4.3 was a semantic change to the behavior of libvirt. virt-manager used and still does issue a volume XML like: <volume> <name>disk.qcow2</name> <capacity>16106127360</capacity> <allocation>16106127360</allocation> <target> <format type="qcow2"/> <features> <lazy_refcounts/> </features> </target> </volume> Up until the commit above that was using preallocation=metadata, but now uses preallocation=falloc. In many cases (read: Fileystems) that won't be very user-visible, but if you are running on ZFS (or anything else that can't fallocate well) this is made worse by [4] slowing down these operations a lot. After the POV for virt-manager seems to have settled on the bug [1] referenced the remaining question is if libvirt should revert/modify the change [3] - and that we agreed required a wider discussion to be had here, hence this mail. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1759454 [2]: https://bugs.launchpad.net/virt-manager/+bug/1847105 [3]: https://libvirt.org/git/?p=libvirt.git;a=commit;h=c9ec7088c7a3f4cd26bb471f1… [4]: https://github.com/zfsonlinux/zfs/issues/326 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

4 3

[PATCH] cmdQemuMonitorCommandQMPWrap: Reset ignored errors from JSON parsing
by Peter Krempa 25 Jul '22

25 Jul '22

'cmdQemuMonitorCommandQMPWrap' is checking whether the user provided string is not valid JSON to avoid wrapping it. In cases where it's not JSON we ignore the error and add the wrapper. If the caller then reports a different non-libvirt error the error from the JSON parsing would be printed as well. Reset errors we ignore: # virsh qemu-monitor-command cd --pass-fds a asdf error: Unable to parse FD number 'a' error: internal error: cannot parse json asdf: lexical error: invalid char in json text. asdf (right here) ------^ In the above case 'asdf' is not valid JSON, but the code did wrap it into '{"execute":"asdf"}', the only problem is the argument for --pass-fds. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- tools/virsh-domain.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 9b1b14cdc2..743660e794 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -9769,6 +9769,8 @@ cmdQemuMonitorCommandQMPWrap(vshControl *ctl, if (virJSONValueIsObject(fullcmdjson)) return g_steal_pointer(&fullcmd); + vshResetLibvirtError(); + /* we try to wrap the command and possible arguments into a JSON object, if * we as fall back we pass through what we've got from the user */ @@ -9787,6 +9789,8 @@ cmdQemuMonitorCommandQMPWrap(vshControl *ctl, * JSON object wrapper and try using that */ g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER; + vshResetLibvirtError(); + virBufferAddLit(&buf, "{"); /* opt points to the _ARGV option bit containing the command so we'll * iterate through the arguments now */ -- 2.35.1

2 2

[PATCH 00/15] docs: Convert some pages to rST and clean up (part 6)
by Peter Krempa 01 Jun '22

01 Jun '22

After this series only 2 non-generated HTML files remain: - index.html.in - 404.html.in It is possible to convert these but the utility of doing so may not be great for now. Additionally this series cleans up some long-broken links and removes unneeded raw HTML passthrough to declare anchors. Pavel Hrdina (2): docs: storage: rename headers to remove duplicate names docs: Convert 'storage' page to rst Peter Krempa (13): docs: formatsecret: Correct link to storage volume XML definition Correct links to TLS certificate setup page docs: Convert 'remote' page to rst docs: remote: Remove 'Limitations' paragraph docs: Convert 'uri' page to rst docs: uri: Remove old 'NULL URI' section docs: uri: Consolidate paragraphs on Xen URIs docs: uri: Move the 'test' hypervisor under a 'local hypervisors heading docs: uri: Rewrite section about transport protocols and extra parameters docs: governance: Remove unused HTML anchors docs: contact: Remove HTML anchors and adjust documents using them docs: bugs: Remove raw HTML anchor 'quality' docs: formatdomain: Remove old unreferenced HTML anchors .gitlab/issue_templates/bug.md | 2 +- docs/bugs.rst | 5 - docs/contact.rst | 11 +- docs/contribute.rst | 10 +- docs/drvesx.rst | 5 +- docs/formatdomain.rst | 112 ----- docs/formatsecret.rst | 8 +- docs/governance.rst | 5 - docs/kbase/tlscerts.rst | 4 +- docs/meson.build | 6 +- docs/page.xsl | 2 +- docs/remote.html.in | 297 ------------ docs/remote.rst | 209 +++++++++ docs/securityprocess.rst | 4 +- docs/storage.html.in | 833 --------------------------------- docs/storage.rst | 790 +++++++++++++++++++++++++++++++ docs/uri.html.in | 507 -------------------- docs/uri.rst | 405 ++++++++++++++++ tools/virt-pki-validate.in | 10 +- 19 files changed, 1431 insertions(+), 1794 deletions(-) delete mode 100644 docs/remote.html.in create mode 100644 docs/remote.rst delete mode 100644 docs/storage.html.in create mode 100644 docs/storage.rst delete mode 100644 docs/uri.html.in create mode 100644 docs/uri.rst -- 2.35.1

3 20

[PATCH] hw/nvme: deprecate the use-intel-id compatibility parameter
by Klaus Jensen 31 May '22

31 May '22

From: Klaus Jensen <k.jensen(a)samsung.com> Since version 5.2 commit 6eb7a071292a ("hw/block/nvme: change controller pci id"), the emulated NVMe controller has defaulted to a non-Intel PCI identifier. Deprecate the compatibility parameter so we can get rid of it once and for all. Signed-off-by: Klaus Jensen <k.jensen(a)samsung.com> --- docs/about/deprecated.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 896e5a97abbd..450f945ac25f 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -356,6 +356,14 @@ contains native support for this feature and thus use of the option ROM approach is obsolete. The native SeaBIOS support can be activated by using ``-machine graphics=off``. +``-device nvme,use-intel-id=on|off`` (since 7.1) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``nvme`` device originally used a PCI Vendor/Device Identifier combination +from Intel that was not properly allocated. Since version 5.2, the controller +has used a properly allocated identifier. Deprecate the ``use-intel-id`` +machine compatibility parameter. + Block device options '''''''''''''''''''' -- 2.35.1

2 2

[PATCH] remote_daemon: Don't run virStateCleanup() if virStateReload() is still running
by Michal Privoznik 19 May '22

19 May '22

When a SIGHUP is received a thread is spawned that runs virStateReload(). However, if SIGINT is received while the former thread is still running then we may get into problematic situation: the cleanup code in main() sees drivers initialized and thus calls virStateCleanup(). So now we have two threads, one running virStateReload() the other virStateCleanup(). In this situation it's very likely that a race condition occurs and either of threads causes SIGSEGV. To fix this, unmark drivers as initialized in the virStateReload() thread for the time the function runs. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2075837 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/remote/remote_daemon.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/src/remote/remote_daemon.c b/src/remote/remote_daemon.c index 26469e0d9f..37d27f93f4 100644 --- a/src/remote/remote_daemon.c +++ b/src/remote/remote_daemon.c @@ -77,7 +77,7 @@ virNetSASLContext *saslCtxt = NULL; virNetServerProgram *remoteProgram = NULL; virNetServerProgram *qemuProgram = NULL; -volatile bool driversInitialized = false; +volatile gint driversInitialized = 0; static void daemonErrorHandler(void *opaque G_GNUC_UNUSED, virErrorPtr err G_GNUC_UNUSED) @@ -453,8 +453,13 @@ static void daemonReloadHandlerThread(void *opaque G_GNUC_UNUSED) VIR_INFO("Reloading configuration on SIGHUP"); virHookCall(VIR_HOOK_DRIVER_DAEMON, "-", VIR_HOOK_DAEMON_OP_RELOAD, SIGHUP, "SIGHUP", NULL, NULL); - if (virStateReload() < 0) + + g_atomic_int_set(&driversInitialized, 0); + if (virStateReload() < 0) { VIR_WARN("Error while reloading drivers"); + } else { + g_atomic_int_inc(&driversInitialized); + } } static void daemonReloadHandler(virNetDaemon *dmn G_GNUC_UNUSED, @@ -463,7 +468,7 @@ static void daemonReloadHandler(virNetDaemon *dmn G_GNUC_UNUSED, { virThread thr; - if (!driversInitialized) { + if (g_atomic_int_get(&driversInitialized) == 0) { VIR_WARN("Drivers are not initialized, reload ignored"); return; } @@ -607,7 +612,7 @@ static void daemonRunStateInit(void *opaque) goto cleanup; } - driversInitialized = true; + g_atomic_int_inc(&driversInitialized); virNetDaemonSetShutdownCallbacks(dmn, virStateShutdownPrepare, @@ -1212,10 +1217,10 @@ int main(int argc, char **argv) { cleanup: virNetlinkEventServiceStopAll(); - if (driversInitialized) { + if (g_atomic_int_get(&driversInitialized) != 0) { /* NB: Possible issue with timing window between driversInitialized * setting if virNetlinkEventServerStart fails */ - driversInitialized = false; + g_atomic_int_set(&driversInitialized, 0); virStateCleanup(); } -- 2.35.1

3 4

[libvirt PATCH v2 0/4] Enable copy/paste for vnc displays
by Jonathon Jongsma 10 May '22

10 May '22

This patch series enables support for the qemu-vdagent character device which enables copy/paste support between guest and client when using vnc graphics. The guest must be configured with something like the following: <channel type='qemu-vdagent'> <source> <clipboard copypaste='yes'/> <mouse mode='client'/> </source> <target type='virtio' name='com.redhat.spice.0'/> </channel> Copy/paste sync requires a vnc client that has support for copy/paste commands. Currently virt-viewer does not work, but the version of tigervnc provided by fedora (executable name 'vncviewer') does work. More details about this device on Gerd's blog: https://www.kraxel.org/blog/2021/05/qemu-cut-paste/ For now I have left the target to be configurable to match the spicevmc channel, although Marc-Andre has suggested to simply hard-code it to the virtio name com.redhat.spice.0 Changes in v2: - change xml syntax to use <clipboard> and <mouse> sub-elements of <source> defined in the same way as they are for the spice display. - fix a build failure when apparmor was enabled - Add another test for when features are turned off Jonathon Jongsma (4): qemu: add capability for qemu-vdagent chardev Rename virDomainGraphicsSpiceMouseMode to virDomainMouseMode conf: add qemu-vdagent channel qemu: add support for qemu-vdagent channel docs/formatdomain.rst | 23 ++++++ src/conf/domain_conf.c | 70 +++++++++++++++++-- src/conf/domain_conf.h | 24 ++++--- src/conf/domain_validate.c | 1 + src/conf/schemas/domaincommon.rng | 51 +++++++++----- src/libvirt_private.syms | 4 +- src/libxl/libxl_conf.c | 8 +-- src/libxl/xen_xl.c | 16 ++--- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 32 +++++++-- src/qemu/qemu_monitor_json.c | 27 +++++++ src/qemu/qemu_process.c | 1 + src/qemu/qemu_validate.c | 9 +++ src/security/security_apparmor.c | 2 + src/security/security_dac.c | 2 + .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../caps_7.0.0.x86_64.xml | 1 + ...l-qemu-vdagent-features.x86_64-latest.args | 41 +++++++++++ .../channel-qemu-vdagent-features.xml | 37 ++++++++++ .../channel-qemu-vdagent.x86_64-latest.args | 41 +++++++++++ .../qemuxml2argvdata/channel-qemu-vdagent.xml | 37 ++++++++++ tests/qemuxml2argvtest.c | 2 + ...el-qemu-vdagent-features.x86_64-latest.xml | 58 +++++++++++++++ .../channel-qemu-vdagent.x86_64-latest.xml | 58 +++++++++++++++ tests/qemuxml2xmltest.c | 2 + tests/testutilsqemu.c | 1 + 29 files changed, 500 insertions(+), 54 deletions(-) create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent-features.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent-features.xml create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.xml create mode 100644 tests/qemuxml2xmloutdata/channel-qemu-vdagent-features.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/channel-qemu-vdagent.x86_64-latest.xml -- 2.35.1

4 11

[PATCH 0/2] test: Link qemuhotplugmock with test_utils_qemu and test_utils
by Michal Privoznik 06 May '22

06 May '22

This is an alternative version to: https://listman.redhat.com/archives/libvir-list/2022-April/230092.html Michal Prívozník (2): test: Link qemuhotplugmock with test_utils_qemu and test_utils tests: Deduplicate some WITH_* checks tests/meson.build | 94 +++++++++++++++++++++-------------------------- 1 file changed, 41 insertions(+), 53 deletions(-) -- 2.35.1

4 6

[PATCH] Support cpu0-id of Qemu QMP query-sev-capabilities
by Niteesh Dubey 06 May '22

06 May '22

It allows libvirt to provide the value of cpu0-id retuned by the Qemu QMP command query-sev-capabilities as implemented by the Qemu Patch [1] which is merged to Qemu master branch and should be available with Qemu 7.1. This is used to get the signed Chip Endorsement Key (CEK) of the CPU of AMD system from AMD's Key Distribution Service (KDS). Similar to cbitpos, reducedPhysBits, maxGuests & maxESGuests; the value of cpu0-id is also provided using 'virsh domcapability'. [1] https://lore.kernel.org/all/20220228093014.882288-1-dovmurik@linux.ibm.com/ Signed-off-by: Niteesh Dubey <niteesh(a)linux.ibm.com> --- include/libvirt/libvirt-host.h | 11 +++++++++++ src/conf/domain_capabilities.c | 4 ++++ src/conf/domain_capabilities.h | 1 + src/qemu/qemu_capabilities.c | 12 ++++++++++++ src/qemu/qemu_driver.c | 5 +++++ src/qemu/qemu_monitor_json.c | 6 ++++++ 6 files changed, 39 insertions(+) diff --git a/include/libvirt/libvirt-host.h b/include/libvirt/libvirt-host.h index b5cf8a4a4a..d35abbd9aa 100644 --- a/include/libvirt/libvirt-host.h +++ b/include/libvirt/libvirt-host.h @@ -537,6 +537,17 @@ typedef virNodeMemoryStats *virNodeMemoryStatsPtr; */ # define VIR_NODE_SEV_CERT_CHAIN "cert-chain" +/** + * VIR_NODE_SEV_CPU0_ID: + * + * Macro represents the unique ID of CPU0 (socket 0) needed to retrieve + * the signed CEK of the CPU from AMD's Key Distribution Service (KDS), + * as VIR_TYPED_PARAMS_STRING. + * + * Since: v8.3.1 + */ +# define VIR_NODE_SEV_CPU0_ID "cpu0-id" + /** * VIR_NODE_SEV_CBITPOS: * diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c index c394a7a390..2a888da1a9 100644 --- a/src/conf/domain_capabilities.c +++ b/src/conf/domain_capabilities.c @@ -601,6 +601,10 @@ virDomainCapsFeatureSEVFormat(virBuffer *buf, sev->max_guests); virBufferAsprintf(buf, "<maxESGuests>%d</maxESGuests>\n", sev->max_es_guests); + if (sev->cpu0_id != NULL) { + virBufferAsprintf(buf, "<cpu0Id>%s</cpu0Id>\n", + sev->cpu0_id); + } virBufferAdjustIndent(buf, -2); virBufferAddLit(buf, "</sev>\n"); } diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h index 1d2f4ac7a5..f2eed80b15 100644 --- a/src/conf/domain_capabilities.h +++ b/src/conf/domain_capabilities.h @@ -185,6 +185,7 @@ typedef struct _virSEVCapability virSEVCapability; struct _virSEVCapability { char *pdh; char *cert_chain; + char *cpu0_id; unsigned int cbitpos; unsigned int reduced_phys_bits; unsigned int max_guests; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index b91db851bb..2d3165e74a 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1957,6 +1957,9 @@ virQEMUCapsSEVInfoCopy(virSEVCapability **dst, tmp->pdh = g_strdup(src->pdh); tmp->cert_chain = g_strdup(src->cert_chain); + if (src->cpu0_id != NULL) { + tmp->cpu0_id = g_strdup(src->cpu0_id); + } tmp->cbitpos = src->cbitpos; tmp->reduced_phys_bits = src->reduced_phys_bits; @@ -4693,6 +4696,11 @@ virQEMUCapsFormatSEVInfo(virQEMUCaps *qemuCaps, virBuffer *buf) virBufferEscapeString(buf, "<pdh>%s</pdh>\n", sev->pdh); virBufferEscapeString(buf, "<certChain>%s</certChain>\n", sev->cert_chain); + if (sev->cpu0_id != NULL) { + virBufferEscapeString(buf, "<cpu0Id>%s</cpu0Id>\n", + sev->cpu0_id); + } + virBufferAdjustIndent(buf, -2); virBufferAddLit(buf, "</sev>\n"); } @@ -6478,6 +6486,10 @@ virQEMUCapsFillDomainFeatureSEVCaps(virQEMUCaps *qemuCaps, domCaps->sev->pdh = g_strdup(cap->pdh); domCaps->sev->cert_chain = g_strdup(cap->cert_chain); + if (cap->cpu0_id != NULL) { + domCaps->sev->cpu0_id = g_strdup(cap->cpu0_id); + } + domCaps->sev->cbitpos = cap->cbitpos; domCaps->sev->reduced_phys_bits = cap->reduced_phys_bits; domCaps->sev->max_guests = cap->max_guests; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index ee0963c30d..464c080409 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -19861,6 +19861,11 @@ qemuGetSEVInfoToParams(virQEMUCaps *qemuCaps, VIR_NODE_SEV_CERT_CHAIN, sev->cert_chain) < 0) goto cleanup; + if ((sev->cpu0_id != NULL) && + (virTypedParamsAddString(&sevParams, &n, &maxpar, + VIR_NODE_SEV_CPU0_ID, sev->cpu0_id) < 0)) + goto cleanup; + if (virTypedParamsAddUInt(&sevParams, &n, &maxpar, VIR_NODE_SEV_CBITPOS, sev->cbitpos) < 0) goto cleanup; diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 776f4ab2ea..9e611e93e8 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -6400,6 +6400,7 @@ qemuMonitorJSONGetSEVCapabilities(qemuMonitor *mon, virJSONValue *caps; const char *pdh = NULL; const char *cert_chain = NULL; + const char *cpu0_id = NULL; unsigned int cbitpos; unsigned int reduced_phys_bits; g_autoptr(virSEVCapability) capability = NULL; @@ -6457,6 +6458,11 @@ qemuMonitorJSONGetSEVCapabilities(qemuMonitor *mon, capability->cert_chain = g_strdup(cert_chain); + cpu0_id = virJSONValueObjectGetString(caps, "cpu0-id"); + if (cpu0_id != NULL) { + capability->cpu0_id = g_strdup(cpu0_id); + } + capability->cbitpos = cbitpos; capability->reduced_phys_bits = reduced_phys_bits; *capabilities = g_steal_pointer(&capability); -- 2.25.1

3 4

[PATCH 0/2] virnetdev: Fix regression in setting VLAN tag
by Michal Privoznik 05 May '22

05 May '22

*** BLURB HERE *** Michal Prívozník (2): virNetDevSetVfMac: Fix error message on invalid args virnetdev: Fix regression in setting VLAN tag src/util/virnetdev.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) -- 2.35.1

3 4

[PATCH v4 00/19] Add 'version' to other exported types
by Victor Toso 05 May '22

05 May '22

Hi, The 4th is coming! v3: https://listman.redhat.com/archives/libvir-list/2022-April/230200.html v2: https://listman.redhat.com/archives/libvir-list/2022-April/230097.html v1: https://listman.redhat.com/archives/libvir-list/2022-April/229881.html I tried to be more careful this time in regards to the patch flow. - The first 4 patches are related to wrong versions introduced in https://gitlab.com/libvirt/libvirt/-/commit/034432e47b Each commit log points out the error I did in v3 and fixes it. If you rather squash them, feel free. - 05/19 "remove comments between enum values" are following Andrea and Peter's suggestion that this should be fixed before adding the version tags: https://listman.redhat.com/archives/libvir-list/2022-April/230304.html - 06/19 "avoid sc_prohibit_nonreentrant in a comment" is the workaround proposed by Peter to avoid syntax-check failure https://listman.redhat.com/archives/libvir-list/2022-April/230238.html - I have set the virAdm exported types to be minimum = v2.0.0. This is for all related types of libvirt-admin: * 08/19 for enums; * 09/19 for macros; * 10/19 for typedefs; * 12/19 for functions; - For exported version of functions, the syms file are the source of truth apart from 4 functions (Peter) https://listman.redhat.com/archives/libvir-list/2022-April/230236.html - Variable's comments are now properly sanitized (Andrea) https://listman.redhat.com/archives/libvir-list/2022-April/230352.html - Removed an extra line in the block of comments (Andrea) https://listman.redhat.com/archives/libvir-list/2022-April/230291.html The CI run for this series: https://gitlab.com/victortoso/libvirt/-/pipelines/522757286 Have a great weekend, Victor Victor Toso (19): docstring: typedef: fix version of virConnectListAllStoragePoolsFlags docstring: typedef: fix version of virDomainDeviceModifyFlags docstring: typedef: fix version of virDomainMemoryModFlags docstring: typedef: fix version of virDomainVcpuFlags docstring: remove comments between enum values docstring: avoid sc_prohibit_nonreentrant in a comment docstring: enums: libvirt: Add 'Since version' metadata docstring: enums: admin: Add 'Since version' metadata docstring: macros: admin: Add 'Since version' metadata docstring: typedef: admin:: Add 'Since version' metadata docstring: function: libvirt: Add 'Since version' metadata docstring: function: admin: Add 'Since version' metadata scripts: apibuild: parse 'Since' version for enums scripts: apibuild: fix parsing block comments from typedef enum scripts: apibuild: parse 'Since' for typedefs scripts: apibuild: parse 'Since' for macros scripts: apibuild: parse 'Since' for functions scripts: apibuild: factor out comment cleaning scripts: apibuild: add parsing variable's comments include/libvirt/libvirt-admin.h | 67 +- include/libvirt/libvirt-domain-checkpoint.h | 28 +- include/libvirt/libvirt-domain-snapshot.h | 60 +- include/libvirt/libvirt-domain.h | 1260 +++++++++++-------- include/libvirt/libvirt-event.h | 24 +- include/libvirt/libvirt-host.h | 62 +- include/libvirt/libvirt-interface.h | 8 +- include/libvirt/libvirt-network.h | 92 +- include/libvirt/libvirt-nodedev.h | 70 +- include/libvirt/libvirt-nwfilter.h | 4 +- include/libvirt/libvirt-secret.h | 40 +- include/libvirt/libvirt-storage.h | 173 +-- include/libvirt/libvirt-stream.h | 24 +- include/libvirt/virterror.h | 408 +++--- scripts/apibuild.py | 163 ++- src/admin/libvirt-admin.c | 62 + src/libvirt-domain-checkpoint.c | 24 + src/libvirt-domain-snapshot.c | 42 + src/libvirt-domain.c | 371 +++++- src/libvirt-host.c | 68 + src/libvirt-interface.c | 42 + src/libvirt-network.c | 89 ++ src/libvirt-nodedev.c | 54 + src/libvirt-nwfilter.c | 48 + src/libvirt-secret.c | 40 + src/libvirt-storage.c | 114 ++ src/libvirt-stream.c | 34 + src/libvirt.c | 12 + src/util/virerror.c | 30 + src/util/virevent.c | 18 + 30 files changed, 2497 insertions(+), 1034 deletions(-) -- 2.35.1

2 34

[PATCH v2] conf: virDomainGraphicsDefValidate: validate attribute 'network' for listen type 'network'
by Amneesh Singh 04 May '22

04 May '22

Related: https://gitlab.com/libvirt/libvirt/-/issues/93 Signed-off-by: Amneesh Singh <natto(a)weirdnatto.in> --- v1 PATCH: https://listman.redhat.com/archives/libvir-list/2022-April/230021.html src/conf/domain_validate.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index 68190fc..e58b84e 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -2347,10 +2347,35 @@ virDomainAudioDefValidate(const virDomainDef *def, return 0; } +static int +virDomainGraphicsDefListensValidate(const virDomainGraphicsDef *def) +{ + size_t i; + + for (i = 0; i < def->nListens; i++) { + if (def->listens[i].type == VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NETWORK && + !def->listens[i].network) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("'network' attribute is required for " + "listen type 'network'")); + return -1; + } + } + + return 0; +} + static int virDomainGraphicsDefValidate(const virDomainDef *def, const virDomainGraphicsDef *graphics) { + if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC || + graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE || + graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_RDP) { + if (virDomainGraphicsDefListensValidate(graphics) < 0) + return -1; + } + if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC) return virDomainEnsureAudioID(def, graphics->data.vnc.audioId); -- 2.35.1

2 1

[RFC PATCH 0/2] Introduce 'absolute' clock offset
by Peter Krempa 04 May '22

04 May '22

Based on https://listman.redhat.com/archives/libvirt-users/2022-April/013537.html Looked as a very simple addition. Peter Krempa (2): conf: Introduce 'absolute' clock offset qemu: Implement 'absolute' clock offset mode docs/formatdomain.rst | 4 ++ src/conf/domain_conf.c | 13 +++++++ src/conf/domain_conf.h | 4 ++ src/conf/schemas/domaincommon.rng | 8 ++++ src/libxl/libxl_conf.c | 1 + src/qemu/qemu_command.c | 10 ++++- .../clock-absolute.x86_64-latest.args | 36 ++++++++++++++++++ tests/qemuxml2argvdata/clock-absolute.xml | 30 +++++++++++++++ tests/qemuxml2argvtest.c | 1 + .../clock-absolute.x86_64-latest.xml | 38 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 11 files changed, 145 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/clock-absolute.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/clock-absolute.xml create mode 100644 tests/qemuxml2xmloutdata/clock-absolute.x86_64-latest.xml -- 2.35.1

3 4

[PATCH] qemu: do not use domain virt type to get default version
by Liang Yan 04 May '22

04 May '22

We do not need VIR_DOMAIN_VIRT_QEMU to get qemu default version. With the 'os_type' and 'arch'in capabilities, we could identify 'emulator' which is enough to get the version. Actually VIR_DOMAIN_VIRT_QEMU is not the only domain virt type for qemu driver, there are VIR_DOMAIN_VIRT_KVM and VIR_DOMAIN_VIRT_HVF. If TCG is disabled in qemu, it will cause the error that could not find suitable emulater when access version. Signed-off-by: Liang Yan <lyan(a)digtalocean.com> --- src/qemu/qemu_capabilities.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index b91db851bb..9a0b7ebeb4 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1857,7 +1857,7 @@ int virQEMUCapsGetDefaultVersion(virCaps *caps, hostarch = virArchFromHost(); if (!(capsdata = virCapabilitiesDomainDataLookup(caps, - VIR_DOMAIN_OSTYPE_HVM, hostarch, VIR_DOMAIN_VIRT_QEMU, + VIR_DOMAIN_OSTYPE_HVM, hostarch, VIR_DOMAIN_VIRT_NONE, NULL, NULL))) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Cannot find suitable emulator for %s"), -- 2.34.1

2 3

[libvirt PATCH v3 00/16] Add QEMU "-display dbus" support
by marcandre.lureau＠redhat.com 04 May '22

04 May '22

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This series implements supports for the uQEMU "-display dbus" support, that landed earlier this week for 7.0. By default, libvirt will start a private VM bus (sharing and reusing the existing "vmstate" VM bus & code). The feature set should cover the needs to replace Spice as local client of choice, including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and arbitrary chardev/channels (for serial etc). The test Gtk4 client is also in progress, currently in development at https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, such as zbus, require an upcoming release. virt-viewer & boxes will need a port to Gtk4 to make use of the shared widget. Comments welcome, as we can still adjust the QEMU side etc. thanks v3: after QEMU 7.0 dev cycle opening and merge - rebased - add 7.0 x86-64 capabilities (instead of tweaking 6.2) - fix version annotations Marc-André Lureau (16): qemu: add chardev-vdagent capability check qemu: add -display dbus capability check qemucapabilitiestest: Add x64 test data for the qemu-7.0 development cycle conf: add <graphics type='dbus'> qemu: start the D-Bus daemon for the display qemu: add -display dbus support virsh: refactor/split cmdDomDisplay() virsh: report the D-Bus bus URI for domdisplay conf: add <audio type='dbus'> support qemu: add audio type 'dbus' conf: add dbus <clipboard> qemu: add dbus clipboard sharing conf: add <serial type='dbus'> qemu: add -chardev dbus support qemu: add usbredir type 'dbus' docs: document <graphics> type dbus NEWS.rst | 7 +- docs/formatdomain.rst | 43 +- docs/schemas/basictypes.rng | 7 + docs/schemas/domaincommon.rng | 71 + src/bhyve/bhyve_command.c | 1 + src/conf/domain_conf.c | 141 +- src/conf/domain_conf.h | 15 + src/conf/domain_validate.c | 41 +- src/libxl/libxl_conf.c | 1 + src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 77 +- src/qemu/qemu_domain.c | 1 + src/qemu/qemu_driver.c | 10 +- src/qemu/qemu_extdevice.c | 13 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_monitor_json.c | 10 + src/qemu/qemu_process.c | 41 +- src/qemu/qemu_validate.c | 33 + src/security/security_dac.c | 2 + src/vmx/vmx.c | 1 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 231 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 237 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 231 + .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../caps_7.0.0.x86_64.replies | 37335 ++++++++++++++++ .../caps_7.0.0.x86_64.xml | 3720 ++ .../graphics-dbus-address.args | 30 + .../graphics-dbus-address.xml | 35 + .../qemuxml2argvdata/graphics-dbus-audio.args | 33 + .../qemuxml2argvdata/graphics-dbus-audio.xml | 45 + .../graphics-dbus-chardev.args | 32 + .../graphics-dbus-chardev.xml | 43 + .../graphics-dbus-clipboard.args | 31 + .../graphics-dbus-clipboard.xml | 35 + tests/qemuxml2argvdata/graphics-dbus-p2p.args | 30 + tests/qemuxml2argvdata/graphics-dbus-p2p.xml | 33 + .../graphics-dbus-usbredir.args | 34 + .../graphics-dbus-usbredir.xml | 30 + tests/qemuxml2argvdata/graphics-dbus.args | 30 + tests/qemuxml2argvdata/graphics-dbus.xml | 33 + tests/qemuxml2argvtest.c | 22 + .../graphics-dbus-address.xml | 1 + .../graphics-dbus-audio.xml | 1 + .../graphics-dbus-chardev.xml | 1 + .../graphics-dbus-clipboard.xml | 1 + .../qemuxml2xmloutdata/graphics-dbus-p2p.xml | 1 + tests/qemuxml2xmloutdata/graphics-dbus.xml | 1 + tests/qemuxml2xmltest.c | 20 + tools/virsh-domain.c | 366 +- 52 files changed, 42981 insertions(+), 192 deletions(-) create mode 100644 tests/domaincapsdata/qemu_7.0.0-q35.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_7.0.0-tcg.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_7.0.0.x86_64.xml create mode 100644 tests/qemucapabilitiesdata/caps_7.0.0.x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus-address.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus-address.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus-audio.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus-audio.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus-chardev.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus-chardev.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus-clipboard.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus-clipboard.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus-p2p.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus-p2p.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus-usbredir.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus-usbredir.xml create mode 100644 tests/qemuxml2argvdata/graphics-dbus.args create mode 100644 tests/qemuxml2argvdata/graphics-dbus.xml create mode 120000 tests/qemuxml2xmloutdata/graphics-dbus-address.xml create mode 120000 tests/qemuxml2xmloutdata/graphics-dbus-audio.xml create mode 120000 tests/qemuxml2xmloutdata/graphics-dbus-chardev.xml create mode 120000 tests/qemuxml2xmloutdata/graphics-dbus-clipboard.xml create mode 120000 tests/qemuxml2xmloutdata/graphics-dbus-p2p.xml create mode 120000 tests/qemuxml2xmloutdata/graphics-dbus.xml -- 2.34.1.8.g35151cf07204

5 23

[libvirt PATCH 0/2] Fix tests on macOS
by Daniel P. Berrangé 03 May '22

03 May '22

NB, even with this done there is still a latent bug affecting all platforms. When we call g_source_destroy the removal is async but we usually close the FD synchronously. This leads to poll'ing on a bad FD. We've actually had this race in libvirt since day 1 - our previous poll() event loop impl before glib would also implement the virEventRemoveHandle call async by just writing to a pipe to interrupt the other thread in poll, just as glib does. We've always relied on parallelism to make this async call almost instantaneous but under the right load conditions we trigger the POLLNVAL / EBADF issue. The only viable solution to this that I see is to only ever call g_source_destroy + g_source_unref from an idle callback, to guarantee that poll() isn't currently running. We know this has a bit of a perf hit on code that is sensitive to main loop iterations, so we tried to avoid it where possible right now: https://listman.redhat.com/archives/libvir-list/2020-November/212411.html I think we'll need to revisit this though, as known BADF problems are not good. Daniel P. Berrangé (2): ci: print stack traces on macOS if any tests fail tests: don't set G_DEBUG=fatal-warnings on macOS ci/cirrus/build.yml | 2 +- tests/meson.build | 17 ++++++++++++++++- 2 files changed, 17 insertions(+), 2 deletions(-) -- 2.35.1

4 10

[libvirt PATCH] conf: ensure only one vgpu has ramfb enabled
by Jonathon Jongsma 02 May '22

02 May '22

Validate the domain configuration to ensure that if there are more than one vgpu assigned to a domain, only one of them has 'ramfb' enabled. This was never a supported configuration. QEMU failed confusingly when attempting to start a domain with this configuration. This change attempts to provide better information about the error. https://bugzilla.redhat.com/show_bug.cgi?id=2079760 Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/conf/domain_validate.c | 19 ++++++++-- ...v-display-ramfb-multiple.x86_64-latest.err | 1 + .../hostdev-mdev-display-ramfb-multiple.xml | 38 +++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 4 files changed, 56 insertions(+), 3 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.x86_64-latest.err create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.xml diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index 68190fc3e2..f4d6e6e0c5 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -1194,20 +1194,33 @@ virDomainDefDuplicateDiskInfoValidate(const virDomainDef *def) } static int -virDomainDefDuplicateHostdevInfoValidate(const virDomainDef *def) +virDomainDefHostdevValidate(const virDomainDef *def) { size_t i; size_t j; + bool ramfbEnabled = false; for (i = 0; i < def->nhostdevs; i++) { + virDomainHostdevDef *dev = def->hostdevs[i]; + for (j = i + 1; j < def->nhostdevs; j++) { - if (virDomainHostdevMatch(def->hostdevs[i], + if (virDomainHostdevMatch(dev, def->hostdevs[j])) { virReportError(VIR_ERR_XML_ERROR, "%s", _("Hostdev already exists in the domain configuration")); return -1; } } + + if (dev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV && + dev->source.subsys.u.mdev.ramfb == VIR_TRISTATE_SWITCH_ON) { + if (ramfbEnabled) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Only one vgpu device can have 'ramfb' enabled")); + return -1; + } + ramfbEnabled = true; + } } return 0; @@ -1664,7 +1677,7 @@ virDomainDefValidateInternal(const virDomainDef *def, if (virDomainDefDuplicateDiskInfoValidate(def) < 0) return -1; - if (virDomainDefDuplicateHostdevInfoValidate(def) < 0) + if (virDomainDefHostdevValidate(def) < 0) return -1; if (virDomainDefDuplicateDriveAddressesValidate(def) < 0) diff --git a/tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.x86_64-latest.err b/tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.x86_64-latest.err new file mode 100644 index 0000000000..07ce47abf7 --- /dev/null +++ b/tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.x86_64-latest.err @@ -0,0 +1 @@ +unsupported configuration: Only one vgpu device can have 'ramfb' enabled diff --git a/tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.xml b/tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.xml new file mode 100644 index 0000000000..1fe53726b5 --- /dev/null +++ b/tests/qemuxml2argvdata/hostdev-mdev-display-ramfb-multiple.xml @@ -0,0 +1,38 @@ +<domain type='qemu'> + <name>QEMUGuest2</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='usb' index='0'> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + </controller> + <graphics type='vnc'/> + <hostdev mode='subsystem' type='mdev' model='vfio-pci' display='on' ramfb='on'> + <source> + <address uuid='53764d0e-85a0-42b4-af5c-2046b460b1dc'/> + </source> + </hostdev> + <hostdev mode='subsystem' type='mdev' model='vfio-pci' display='on' ramfb='on'> + <source> + <address uuid='53764d0e-85a0-42b4-af5c-2046b460b1dd'/> + </source> + </hostdev> + <video> + <model type='qxl' heads='1'/> + </video> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 41fd032f19..e334c59eb7 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1896,6 +1896,7 @@ mymain(void) QEMU_CAPS_DEVICE_VFIO_PCI, QEMU_CAPS_VFIO_PCI_DISPLAY); DO_TEST_CAPS_LATEST("hostdev-mdev-display-ramfb"); + DO_TEST_CAPS_LATEST_PARSE_ERROR("hostdev-mdev-display-ramfb-multiple"); DO_TEST_PARSE_ERROR("hostdev-vfio-zpci-wrong-arch", QEMU_CAPS_DEVICE_VFIO_PCI); DO_TEST("hostdev-vfio-zpci", -- 2.35.1

2 1

[libvirt RFCv5 00/27] multifd save restore prototype
by Claudio Fontana 30 Apr '22

30 Apr '22

This is the multifd save prototype in semi-functional state, with both save and restore minimally functional. There are still quite a few rough edges. KNOWN ISSUES: 1) this applies only to virsh save and virsh restore for now (no managed save etc). 2) error handling is not good yet, especially during resume, errors may leave behind a qemu process and such. May need some help find all of these cases 3) the compression part is demonstrative only, there needs to be more attention to compression options, and detecting the compression used to store the multifd saves. ... changes from v4: * runIO renamed to virFileDiskCopy and rethought arguments * renamed new APIs from ...ParametersFlags to ...Params * introduce the new virDomainSaveParams and virDomainRestoreParams without any additional parameters, so they can be upstreamed first. * solved the issue in the gendispatch.pl script generating code that was missing the conn parameter. --- changes from v3: * reordered series to have all helper-related change at the start * solved all reported issues from ninja test, including documentation * fixed most broken migration capabilities code (still imperfect likely) * added G_GNUC_UNUSED as needed * after multifd restore, added what I think were the missing operations: qemuProcessRefreshState(), qemuProcessStartCPUs() - most importantly, virDomainObjSave() The domain now starts running after restore without further encouragement * removed the sleep(10) from the multifd-helper changes from v2: * added ability to restore the VM from disk using multifd * fixed the multifd-helper to work in both directions, assuming the need to listen for save, and connect for restore. * fixed a large number of bugs, and probably introduced some :-) Thanks for your thoughts, Claudio Claudio Fontana (27): iohelper: introduce new struct to carry copy operation parameters iohelper: refactor copy operation as a separate function iohelper: move runIO function to virfile.c virfile: rename runIO to virFileDiskCopy virfile: change virFileDiskCopy arguments to extend beyond stdin, stdout virfile: add comment about the use of SEEK_END in virFileDiskCopy multifd-helper: new helper for parallel save/restore libvirt: introduce virDomainSaveParams public API libvirt: introduce virDomainRestoreParams public API remote: Add RPC support for the virDomainSaveParams API gendispatch: add DomainRestoreParams as requiring conn argument remote: Add RPC support for the virDomainRestoreParams API qemu: add implementation for virDomainSaveParams API qemu: add implementation for virDomainRestoreParams API libvirt: add new VIR_DOMAIN_SAVE_PARALLEL flag and parameter qemu: add stub support for VIR_DOMAIN_SAVE_PARALLEL in save qemu: add stub support for VIR_DOMAIN_SAVE_PARALLEL in restore qemu: saveimage: introduce virQEMUSaveFd qemu: wire up saveimage code with the multifd helper qemu: capabilities: add multifd to the probed migration capabilities qemu: implement qemuMigrationSrcToFilesMultiFd qemu: add parameter to qemuMigrationDstRun to skip waiting qemu: implement qemuSaveImageLoadMultiFd tools: add parallel parameter to virsh save command tools: add parallel parameter to virsh restore command docs: update refs to virDomainSaveParams and virDomainRestoreParams qemu: add migration parameter multifd-compression docs/formatsnapshot.rst | 5 +- docs/manpages/virsh.rst | 34 +- include/libvirt/libvirt-domain.h | 49 ++ po/POTFILES.in | 1 + src/driver-hypervisor.h | 14 + src/libvirt-domain.c | 99 +++- src/libvirt_private.syms | 1 + src/libvirt_public.syms | 6 + src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_driver.c | 239 +++++++-- src/qemu/qemu_migration.c | 155 ++++-- src/qemu/qemu_migration.h | 16 +- src/qemu/qemu_migration_params.c | 71 ++- src/qemu/qemu_migration_params.h | 15 + src/qemu/qemu_process.c | 3 +- src/qemu/qemu_process.h | 5 +- src/qemu/qemu_saveimage.c | 496 ++++++++++++++---- src/qemu/qemu_saveimage.h | 49 +- src/qemu/qemu_snapshot.c | 6 +- src/remote/remote_driver.c | 2 + src/remote/remote_protocol.x | 29 +- src/remote_protocol-structs | 17 + src/rpc/gendispatch.pl | 5 +- src/util/iohelper.c | 162 +----- src/util/meson.build | 19 + src/util/multifd-helper.c | 249 +++++++++ src/util/virfile.c | 218 ++++++++ src/util/virfile.h | 2 + src/util/virthread.c | 5 + src/util/virthread.h | 1 + .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 2 + .../caps_5.0.0.riscv64.xml | 2 + .../caps_5.0.0.x86_64.xml | 2 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 2 + .../caps_5.1.0.x86_64.xml | 2 + .../caps_5.2.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 2 + .../caps_5.2.0.riscv64.xml | 2 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 2 + .../caps_5.2.0.x86_64.xml | 2 + .../caps_6.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 2 + .../caps_6.0.0.x86_64.xml | 2 + .../caps_6.1.0.x86_64.xml | 2 + .../caps_6.2.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 2 + .../caps_6.2.0.x86_64.xml | 2 + .../caps_7.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 2 + .../caps_7.0.0.x86_64.xml | 2 + tools/virsh-domain.c | 96 +++- 64 files changed, 1686 insertions(+), 446 deletions(-) create mode 100644 src/util/multifd-helper.c -- 2.34.1

1 27