July 2026 - Devel - libvirt List Archives

[PATCH v3 0/7] Add TLS-PSK support for migration
by Abhisek Panda 01 Sep '26

01 Sep '26

QEMU provides the capability to encrypt the migration data stream using two transport layer security (TLS) authentication schemes: X.509 certificates and pre-shared keys (PSK). Currently, Libvirt only supports the X.509-based TLS authentication scheme. In TLS X.509 certificates, a set of live migrations utilize a fixed set of static certificates for encrypted migration. In this authentication scheme, users require to deploy a certificate authority and monitor the certificate expiration window. In case certificates are compromised all the future live migrations are vulnerable. To resolve this, this patch series introduce the support for pre-shared key-based authentication scheme. This mechanism relies on symmetric pre-shared keys (a secret key that is known to both sender and receiver prior to secure communication) for providing secure transfer of data. Libvirt solely manages the lifecycle of the ephemeral pre-shared keys, including, generation, persistent storage, and cleanup. Libvirt generates the key on the source machine, then transfers it to the destination machine using the migration cookie. To allow users to configure the size of the key, Libvirt provides the migrate_tls_psk_length configuration parameter in qemu.conf. To avoid introduction of an additional VIR_MIGRATE_* flag, we rely on existing the VIR_MIGRATE_TLS flag. If the VIR_MIGRATE_TLS flag is set but the necessary X.509 credential files are missing on the destination, then we fallback to using PSK-based authentication scheme during migration. v3: 1. Destination host decides which TLS authentication scheme to use. 2. The directory of the key file is set to <tls_psk_state_dir>/$ID-$VMNAME. 3. Use the same alias for both tls-creds-x509 and tls-creds-psk objects. 4. Validate the length of the pre-shared key. 5. Unit test to validate the pre-shared key in the migration cookie. v2: 1. Libvirt manages the lifecycle of pre-shared keys. 2. Transfer of keys to the destination via the migration cookie 3. Remove the VIR_MIGRATE_TLS_PSK flag instead rely on VIR_MIGRATE_TLS and availability of ca-cert.pem on source. 4. Drop VIR_MIGRATE_PARAM_TLS_PSK_DIRECTORY, Libvirt solely manages the pre-shared keys. Abhisek Panda (7): conf: Add a configuration param for TLS-PSK qemu: Manage a pre-shared key's lifecycle qemu: Add support to build the tls-creds-psk object qemu: rename tls-creds-x509 obj related functions qemu: Manage tls-creds-psk object lifecycle qemu: Set up the migrate TLS-PSK objects tests: Add testing of pre-shared key lifecycle include/libvirt/libvirt-domain.h | 11 +- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 8 ++ src/qemu/qemu_command.c | 26 ++++ src/qemu/qemu_command.h | 7 + src/qemu/qemu_conf.c | 22 ++++ src/qemu/qemu_conf.h | 2 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 6 + src/qemu/qemu_hotplug.c | 40 +++--- src/qemu/qemu_hotplug.h | 24 ++-- src/qemu/qemu_migration.c | 202 +++++++++++++++++++++++++---- src/qemu/qemu_migration_cookie.c | 94 +++++++++++++- src/qemu/qemu_migration_cookie.h | 5 + src/qemu/qemu_migration_params.c | 98 +++++++++++--- src/qemu/qemu_migration_params.h | 22 +++- src/qemu/test_libvirtd_qemu.aug.in | 1 + tests/qemumigrationcookiexmltest.c | 141 +++++++++++++++++++- tests/testutilsqemu.c | 12 ++ 20 files changed, 631 insertions(+), 93 deletions(-) -- 2.43.7

2 19

[PATCH 0/6] conf: add vlen tag for RISC-V CPUs
by Heinrich Schuchardt 18 Aug '26

18 Aug '26

RISC-V CPUs may provide a scalable vector extension. The length of the vector registers is implementation specific. QEMU allows to set the vector length as a CPU property, e.g. '-cpu rva23s64,vlen=256'. To describe this feature a new CPU tag is introduced: <vlen value='N'> According to the RISC-V ISA specification vlen must be a power of 2 in the range 8 to 65536. A configuration test is provided. Heinrich Schuchardt (6): conf: add vlen tag for RISC-V CPUs schemas: add cpuVlen definition for RISC-V vector length qemu: validate that CPU vlen is only used with RISC-V qemu: emit vlen= CPU property on the command line tests: provide vlen configuration test docs: add vlen to formatdomain documentation docs/formatdomain.rst | 13 ++++++++ src/conf/cpu_conf.c | 25 +++++++++++++++ src/conf/cpu_conf.h | 1 + src/conf/schemas/cputypes.rng | 11 +++++++ src/qemu/qemu_command.c | 3 ++ src/qemu/qemu_validate.c | 9 ++++++ .../riscv64-virt-vlen.riscv64-latest.args | 31 +++++++++++++++++++ .../riscv64-virt-vlen.riscv64-latest.xml | 26 ++++++++++++++++ tests/qemuxmlconfdata/riscv64-virt-vlen.xml | 26 ++++++++++++++++ tests/qemuxmlconftest.c | 2 ++ 10 files changed, 147 insertions(+) create mode 100644 tests/qemuxmlconfdata/riscv64-virt-vlen.riscv64-latest.args create mode 100644 tests/qemuxmlconfdata/riscv64-virt-vlen.riscv64-latest.xml create mode 100644 tests/qemuxmlconfdata/riscv64-virt-vlen.xml -- 2.53.0

1 7

[PATCH 0/2] qemu: Fix detach of a CD-ROM device with no media
by Mitsuru Kariya 14 Aug '26

14 Aug '26

Detaching a CD-ROM device that has no media inserted currently logs an internal error: internal error: unable to execute QEMU command 'blockdev-del': Failed to find node with node-name='libvirt-N-storage' or, when no stale node name is present in the source: internal error: argument key 'node-name' must not have null value The root cause is that an empty disk source (path == NULL) satisfies virStorageSourceIsBacking() while no corresponding blockdev node ever exists in QEMU, so the detach path prepares a blockdev-del for a node that was never created. Patch 1 fixes the detach path itself: qemuDomainRemoveDiskDevice() now skips the blockdev detach preparation for an empty source, mirroring what the old-media detach in qemuDomainChangeMediaBlockdev() already does. Patch 2 fixes the way the stale node name gets there in the first place: qemuDomainChangeEjectableMedia() ran the full image setup (qemuDomainPrepareDiskSource(), backing chain detection, storage access, managed PR) even when ejecting to no media, assigning node names to an empty source that are never realized in QEMU. The setup is now skipped for an empty source, mirroring qemuDomainAttachDeviceDiskLiveInternal(), and rollback only revokes storage access when it was actually granted. To reproduce the 1st message: 1. Start a domain with a CD-ROM device with media attached 2. virsh change-media $dom $target --eject --live 3. virsh detach-disk $dom $target --live To reproduce the 2nd message: 1. Start a domain with a CD-ROM device without media attached 2. virsh detach-disk $dom $target --live No regression tests are added. Neither failure mode is reachable from qemuhotplugtest: the "null value" variant fails while constructing the blockdev-del arguments, before any QMP command is sent, leaving nothing for the test monitor to observe; the stale-node-name variant does emit a blockdev-del and would be detectable, but requires a preceding media eject to set up, which qemuhotplugtest cannot drive. Mitsuru Kariya (2): qemu: Skip empty disk source when detaching a disk device qemu: Don't prepare an empty disk source on media change src/qemu/qemu_hotplug.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) base-commit: 674fcf87bdd479302032fbeb331fea2aa51606ac -- 2.43.0

2 4

[PATCH 0/3] bhyve: support setting serial number for disks
by Roman Bogorodskiy 13 Aug '26

13 Aug '26

Roman Bogorodskiy (3): bhyve: support setting serial number for SATA disks bhyve: support setting serial number for NVMe controllers bhyve: forbid "," in disk serial numbers src/bhyve/bhyve_command.c | 5 ++++ src/bhyve/bhyve_domain.c | 15 ++++++++++ ...hyvexml2argv-nvme-explicit-controller.args | 9 ++++++ ...vexml2argv-nvme-explicit-controller.ldargs | 4 +++ ...bhyvexml2argv-nvme-explicit-controller.xml | 20 +++++++++++++ .../bhyvexml2argv-nvme-invalid-serial.xml | 20 +++++++++++++ ...bhyvexml2argv-sata-disk-invalid-serial.xml | 23 +++++++++++++++ .../bhyvexml2argv-sata-rotation-rate.args | 2 +- .../bhyvexml2argv-sata-rotation-rate.xml | 3 ++ tests/bhyvexml2argvtest.c | 3 ++ ...yvexml2xmlout-nvme-explicit-controller.xml | 28 +++++++++++++++++++ tests/bhyvexml2xmltest.c | 3 ++ 12 files changed, 134 insertions(+), 1 deletion(-) create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-explicit-controller.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-nvme-invalid-serial.xml create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-sata-disk-invalid-serial.xml create mode 100644 tests/bhyvexml2xmloutdata/x86_64/bhyvexml2xmlout-nvme-explicit-controller.xml -- 2.52.0

2 6

[PATCH 0/2] bhyve: implement virDomainGetGuestInfo()
by Roman Bogorodskiy 13 Aug '26

13 Aug '26

Roman Bogorodskiy (2): qemu: move qemuAgent*InfoFormatParams to hypervisor/qemu_agent.c bhyve: implement virDomainGetGuestInfo() src/bhyve/bhyve_driver.c | 192 ++++++++++++++++++++++++++++++++++++ src/hypervisor/qemu_agent.c | 159 +++++++++++++++++++++++++++++ src/hypervisor/qemu_agent.h | 17 ++++ src/libvirt_private.syms | 3 + src/qemu/qemu_driver.c | 162 +----------------------------- 5 files changed, 372 insertions(+), 161 deletions(-) -- 2.52.0

2 4

[PATCH v2 00/21] qom: introduce property flags to track external user input
by Zhao Liu 13 Aug '26

13 Aug '26

Hi, This is the v2 trying to introduce property flags to detect user's property setting (from CLI/QMP/HMP). I dropped RFC tag since previous RFC v1 [1]. Though this work the follow-up of v2.6 & v2.7 machines' removal [2], now it is decoupled from [2] totally since v2 doesn't detect compat property and only focuses on external user setting, so this series is based on master branch at the commit 28a6ca268c2c ("Merge tag 'single- binary-20260203' of https://github.com/philmd/qemu into staging"). And you can also find the code here: https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026 This series introduces 3 property flags: * USER_SET: Any external user property setting (from CLI/HMP/QMP) is marked as USER_SET. * DEPRECATED: Once a property is marked as DEPRECATED, any external user property setting will trigger a warning. * INTERNAL: Once a property is marked as INTERNAL, any external user property setting will cause an error. More details or document for these 3 flags, you can refer patch 7. Compared with RFC v1, v2 mainly: * introduce USER_SET property flag to identify all user's setting. - patch 7 for document. * construct DEPRECATED & INTERNAL flag on USER_SET. - patch 7 for document. * cover more comprehensive user set cases. - patch 8-13. * provide examples about new flags (USER_SET/DEPRECATED/INTELNAL). - patch 15/16/17 are examples for DEPRECATED flag. - patch 18 is the example for INTERNAL flag. - patch 20 is the example for USER_SET flag. I think v2 should now cover "nearly" all cases (patch 8-13) where users set properties: one approach is to trace the call chain of object_property_set(). Even if there are cases that were missed, they can be easily addressed based on this series: object_property_set(obj, ...); /* Insert this call after object_property_set(). */ object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...); [1]: RFC v1: https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel… [2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.… Thanks and Best Regards, Zhao --- Zhao Liu (21): qom/object: use BIT macro for ObjectPropertyFlags qom/object: cache ObjectPropertyFlags in ObjectProperty qom/object: factor out object_class_property_try_add() qom/object: add flags argument in object_{class_}property_try_add() qom/object: rename object_{class_}property_try_add() to object_{class_}property_add_full() qom/object: add helpers to set/get/clear property flags qom/object: introduce user interaction flags for properties qom/object: add from_user argument in object_property_parse() qom/object: mark global property set from CLI as USER_SET qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as USER_SET qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as USER_SET qom/object_interfaces: mark properties set from qdict & keyval as USER_SET system/vl: mark property set in object_parse_property_opt() as USER_SET hw/core/qdev-properties: allow qdev properties accept flags target/i386: deprecate fill-mtrr-mask property target/i386: deprecate cpuid-0xb property hw/intc/ioapic: deprecate version property target/i386: mark x-consistent-cache property as internal-only target/i386: remove redundant validation for lbr-fmt property target/i386: detect user provided lbr-fmt via property flag hw/core/qdev-properties: support valid default value for DEFINE_PROP_UINT64_CHECKMASK docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-) -- 2.34.1

10 45

[PATCH v2 0/5] virsh: Add missing TAB completers for several commands
by rsmigiel＠redhat.com 13 Aug '26

13 Aug '26

From: Radoslaw Smigielski <rsmigiel(a)redhat.com> These changes add missing virsh TAB completion callbacks for several commands. Fixed or added completers covers command grouped by similar options: output paths: - dump --file - save --file - blockcopy --dest - screenshot --file (fixes pre-existing wrong annotation) display / native format: - domdisplay --type - domxml-from-native --format - domxml-to-native --format storage volume formats: - vol-create-as --format - vol-create-as --backing-vol-format attach-disk: - targetbus, type, cache, io, mode, sourcetype, subdriver - source-host-socket In patch 1/5 added vshCompletePathLocalCreate, a new noop completer for local file paths used as command output where the target file may not exist yet. This is the counterpart to vshCompletePathLocalExisting, which is for existing files used as input. In patch 2/5 adds a completer for domdisplay --type using virDomainGraphicsTypeToString and VIR_DOMAIN_GRAPHICS_TYPE_LAST so the options stays in sync with libvirt graphics types. Replaced the static list from first patch set. In patch 3/5 adds virshDomainXMLNativeFormatCompleter for domxml-from-native --format (hypervisor-dependent native config format list). In virshDomainXMLNativeFormatCompleter() added 4 new "static const char[]" variables, follow the same pattern appears in the same file. Even though these variables could be a non-static local arrays. In patch 4/5 reuses existing completers for domxml-to-native --format and vol-create-as --format / --backing-vol-format. In 5/5 adds few enum and static-list completers for attach-disk options targetbus, type, cache, io, mode, and sourcetype, and reuses the storage file format completer for subdriver. In virshDomainAttachDiskSourceTypeCompleter, I added a static list of element types, I did not find any existing variable with the same list content. Partially-fixes: https://gitlab.com/libvirt/libvirt/-/work_items/9 Radoslaw Smigielski (5): virsh: Add vshCompletePathLocalCreate completer for output paths virsh: Add completer for '--type' option of 'domdisplay' command virsh: Add completer for '--format' option of 'domxml-from-native' command virsh: Add missing TAB completers for several options virsh: Add missing TAB completers for 'attach-disk' command tools/virsh-completer-domain.c | 122 +++++++++++++++++++++++++++++++++ tools/virsh-completer-domain.h | 40 +++++++++++ tools/virsh-domain.c | 16 ++++- tools/virsh-volume.c | 2 + tools/vsh-completer.c | 18 +++++ tools/vsh-completer.h | 5 ++ 6 files changed, 202 insertions(+), 1 deletion(-) -- 2.54.0

2 12

[PATCH] qemu: Pass driver to qemuDomainRestoreInternal explicitly
by Daniel Golle 13 Aug '26

13 Aug '26

qemuAutostartDomain() starts domains with conn=NULL as there is no client connection during driver initialisation. Since the managed save restore path of qemuDomainObjStart() was switched to qemuDomainRestoreInternal(), which obtains the driver by dereferencing conn->privateData, any domain with both a managed save image and the autostart (or autostart-once) flag crashes virtqemud/libvirtd with SIGSEGV on daemon startup. The session daemon's auto-shutdown feature creates exactly this combination on logout with a running VM (auto_shutdown_try_save saves the domain and auto_shutdown_restore marks it autostart-once), so the first daemon start of every subsequent boot segfaults and clients such as GNOME Boxes fail with "Cannot recv data: Connection reset by peer", showing an empty machine list. Pass the driver as an explicit parameter, as qemuDomainObjRestore() did before it was merged into qemuDomainRestoreInternal(), and keep @conn only for use by the ACL check callbacks, which are not used in the autostart code path. Fixes: 0e2ab427782c ("qemu: driver: Merge 'qemuDomainRestoreInternal' and 'qemuDomainObjRestore'") Signed-off-by: Daniel Golle <daniel(a)makrotopia.org> --- Observed with libvirt 12.5.0 and QEMU 11.0.2 on Arch Linux; the code in current git master is identical. Reproducer (any session domain, regular autostart takes the same path): $ virsh -c qemu:///session managedsave DOMAIN $ virsh -c qemu:///session autostart DOMAIN --once # simulate the first daemon start of a boot: $ rm "$XDG_RUNTIME_DIR/libvirt/qemu/run/autostarted" $ pkill -x virtqemud $ virsh -c qemu:///session list --all error: failed to connect to the hypervisor error: Cannot recv data: Connection reset by peer Backtrace of the crashing thread (12.5.0, distro debug symbols): #0 qemuDomainRestoreInternal (conn=conn@entry=0x0, ...) at ../src/qemu/qemu_driver.c:5940 #1 qemuDomainObjStart.constprop.0 (conn=conn@entry=0x0, ...) at ../src/qemu/qemu_driver.c:6509 #2 qemuAutostartDomain at ../src/qemu/qemu_driver.c:185 #3 virDomainDriverAutoStartOne at ../src/hypervisor/domain_driver.c:700 #7 virDomainDriverAutoStart at ../src/hypervisor/domain_driver.c:728 #8 qemuStateInitialize at ../src/qemu/qemu_driver.c:962 #9 virStateInitialize at ../src/libvirt.c:667 Tested on current master in an isolated session environment with a minimal diskless domain: unpatched, the daemon reproducibly segfaults on startup after the steps above; patched, it starts cleanly and restores the domain from its managed save image. The explicit restore APIs (virDomainRestore*) behave as before. src/qemu/qemu_driver.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 3d57de38..d478d383 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5901,7 +5901,8 @@ qemuNodeGetSecurityModel(virConnectPtr conn, /** * qemuDomainRestoreInternal: - * @conn: connection object + * @driver: QEMU driver + * @conn: connection object (optional if @ensureACL is NULL) * @vmRestore: Domain object (optional; see below) * @path: path to the save image file * @unlink_corrupt: remove corrupted save image file @path @@ -5926,7 +5927,8 @@ qemuNodeGetSecurityModel(virConnectPtr conn, * corrupted image was removed 1 is returned. */ static int -qemuDomainRestoreInternal(virConnectPtr conn, +qemuDomainRestoreInternal(virQEMUDriver *driver, + virConnectPtr conn, virDomainObj *vmRestore, const char *path, bool unlink_corrupt, @@ -5937,7 +5939,6 @@ qemuDomainRestoreInternal(virConnectPtr conn, int (*ensureACL)(virConnectPtr, virDomainDef *), virDomainAsyncJob asyncJob) { - virQEMUDriver *driver = conn->privateData; qemuDomainObjPrivate *priv = NULL; g_autoptr(virDomainDef) def = NULL; virDomainObj *vm = NULL; @@ -6096,7 +6097,8 @@ qemuDomainRestoreFlags(virConnectPtr conn, { virCheckFlags(QEMU_DOMAIN_RESTORE_FLAGS, -1); - return qemuDomainRestoreInternal(conn, NULL, path, false, dxml, NULL, 0, + return qemuDomainRestoreInternal(conn->privateData, conn, NULL, path, + false, dxml, NULL, 0, flags, virDomainRestoreFlagsEnsureACL, VIR_ASYNC_JOB_START); } @@ -6105,7 +6107,8 @@ static int qemuDomainRestore(virConnectPtr conn, const char *path) { - return qemuDomainRestoreInternal(conn, NULL, path, false, NULL, NULL, 0, + return qemuDomainRestoreInternal(conn->privateData, conn, NULL, path, + false, NULL, NULL, 0, 0, virDomainRestoreEnsureACL, VIR_ASYNC_JOB_START); } @@ -6141,7 +6144,8 @@ qemuDomainRestoreParams(virConnectPtr conn, return -1; } - ret = qemuDomainRestoreInternal(conn, NULL, path, false, dxml, params, nparams, + ret = qemuDomainRestoreInternal(conn->privateData, conn, NULL, path, + false, dxml, params, nparams, flags, virDomainRestoreParamsEnsureACL, VIR_ASYNC_JOB_START); return ret; @@ -6506,7 +6510,7 @@ qemuDomainObjStart(virConnectPtr conn, restore_flags |= bypass_cache ? VIR_DOMAIN_SAVE_BYPASS_CACHE : 0; restore_flags |= reset_nvram ? VIR_DOMAIN_SAVE_RESET_NVRAM : 0; - ret = qemuDomainRestoreInternal(conn, vm, managed_save, true, NULL, NULL, 0, + ret = qemuDomainRestoreInternal(driver, conn, vm, managed_save, true, NULL, NULL, 0, restore_flags, NULL, asyncJob); -- 2.55.0

2 1

[PATCH 1/1] remote: fix stale status snapshot in daemonStreamHandleWrite
by Denis V. Lunev 13 Aug '26

13 Aug '26

daemonStreamHandleWrite() snapshots status from msg->header.status before dispatching to the per-type handler, then reuses that stale snapshot afterwards to decide whether to send a fake release reply. A stale snapshot lets it send that reply twice for the same 'msg', linking the message to itself and deadlooping the event loop thread in virNetMessageQueuePush()'s tail-walk loop. Remove the 'status' variable and read msg->header.status directly at the point of use instead. Commit 411cbe7199c ("remote: fix stream use-after-free") introduced it alongside its real fix: it also moved virNetMessageQueueServe() to dequeue 'msg' from stream->rx before dispatch instead of after, which is what actually prevents corrupting stream->rx's linkage and remains unchanged here. The variable itself was never load-bearing: no dispatch handler frees 'msg' on the path that reaches this check, so reading msg->header.status straight from 'msg' cannot go stale. Fixes: 411cbe7199ce ("remote: fix stream use-after-free") Signed-off-by: Denis V. Lunev <den(a)openvz.org> --- src/remote/remote_daemon_stream.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 3777c8e684..437cec374f 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -736,7 +736,6 @@ static int daemonStreamHandleWrite(virNetServerClient *client, daemonClientStream *stream) { - virNetMessageStatus status = VIR_NET_OK; VIR_DEBUG("client=%p, stream=%p", client, stream); while (stream->rx && !stream->closed) { @@ -748,10 +747,8 @@ daemonStreamHandleWrite(virNetServerClient *client, * Otherwise just carry on with processing stream * data. */ ret = daemonStreamHandleHole(client, stream, msg); - status = msg->header.status; } else if (msg->header.type == VIR_NET_STREAM) { - status = msg->header.status; - switch (status) { + switch (msg->header.status) { case VIR_NET_OK: ret = daemonStreamHandleFinish(client, stream, msg); break; @@ -791,7 +788,7 @@ daemonStreamHandleWrite(virNetServerClient *client, * onto the wire, but this causes the client to reset * its active request count / throttling */ - if (status == VIR_NET_CONTINUE) { + if (msg->header.status == VIR_NET_CONTINUE) { virNetMessageClear(msg); msg->header.type = VIR_NET_REPLY; if (virNetServerClientSendMessage(client, msg) < 0) { -- 2.53.0

4 6

[PATCH 0/3] bhyve: implement virDomainSetLifecycleAction() API
by Roman Bogorodskiy 13 Aug '26

13 Aug '26

Roman Bogorodskiy (3): bhyve: add validation for lifecycle actions bhyve: monitor: respect on_poweroff / on_reboot settings bhyve: implement virDomainSetLifecycleAction() API src/bhyve/bhyve_domain.c | 36 +++++++++++++ src/bhyve/bhyve_domain.h | 3 ++ src/bhyve/bhyve_driver.c | 110 ++++++++++++++++++++++++++++++++++++++ src/bhyve/bhyve_monitor.c | 20 +++++-- 4 files changed, 165 insertions(+), 4 deletions(-) -- 2.52.0

2 5