- Devel - libvirt List Archives

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 10 Apr '26

10 Apr '26

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

2 1

[RFC] nftables: switch to nft -f
by Dion Bosschieter 09 Apr '26

09 Apr '26

Hi, I'd like to propose switching from individual nft commands to nft -f in the nftables firewall backend — either as a new backend or as an extension of the existing one. The main motivation is performance. In benchmarking, nft -f is about 46% faster: The following commands are run on the .args files in the nwfilter nftables v6 patch. $ time for i in *.args; do n=$(echo $i | sed s/.args$//); sudo ./reset-tables.sh; sudo sh -e $i; done real 0m8.335s user 0m0.320s sys 0m0.564s $ time for i in *.output; do sudo ./reset-tables.sh skipvmap; sudo nft -f $i; done real 0m4.518s user 0m0.274s sys 0m0.498s On top of that, loading a full ruleset via nft -f is atomic for the whole set of changes, which allows us to remove the rollback logic and removes the need for tmp rules. One issue I see is that the current approach allows certain commands to fail silently, deleting something that doesn't exist won't abort the operation. That's not the case with nft -f, where a failure stops the whole load. One approach here is to only use nft -f for sections that don't contain ignore-errors commands, and run those separately as individual commands. As described earlier: to handle the current non-atomic nature, we have a few extra commands in place — a temporary jump rule, delete vmap entry, add vmap entry. The tmp jump can be replaced by running nft -f instead. I wonder what your opinions are about adding nft -f. Regards, Dion

2 2

[PATCH] qemu: Drop unused @driver from function comments
by wang.yechao255＠zte.com.cn 09 Apr '26

09 Apr '26

From: Wang Yechao <wang.yechao255(a)zte.com.cn> Clean up stale @driver parameter documentation from several functions that no longer take such a parameter. This is a pure comment correction. Signed-off-by: Wang Yechao <wang.yechao255(a)zte.com.cn> --- src/qemu/qemu_domain.c | 3 --- src/qemu/qemu_driver.c | 1 - src/qemu/qemu_hotplug.c | 3 --- src/qemu/qemu_migration.c | 1 - src/qemu/qemu_migration_params.c | 2 -- 5 files changed, 10 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 91d57ee60b..d4a76b43b4 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8668,7 +8668,6 @@ qemuDomainSupportsVcpuHotplug(virDomainObj *vm) /** * qemuDomainRefreshVcpuInfo: - * @driver: qemu driver data * @vm: domain object * @asyncJob: current asynchronous job type * @state: refresh vcpu state @@ -8805,7 +8804,6 @@ qemuDomainRefreshVcpuInfo(virDomainObj *vm, /** * qemuDomainRefreshVcpuHalted: - * @driver: qemu driver data * @vm: domain object * @asyncJob: current asynchronous job type * @@ -11049,7 +11047,6 @@ qemuDomainObjIsActive(virDomainObj *vm) /** * virDomainRefreshStatsSchema: - * @driver: qemu driver data * @vm: Pointer to the vm object * * Load data into dom->privateData->statsSchema if not stored diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2d31d4aa31..610289c2ab 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9631,7 +9631,6 @@ qemuDomainBlockStatsGatherTotals(qemuBlockStats *data, /** * qemuDomainBlocksStatsGather: - * @driver: driver object * @vm: domain object * @path: to gather the statistics for * @retstats: returns pointer to structure holding the stats diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b7a282b96e..b43e293201 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -372,7 +372,6 @@ qemuHotplugAttachDBusVMState(virDomainObj *vm, /** * qemuHotplugRemoveDBusVMState: - * @driver: QEMU driver object * @vm: domain object * @asyncJob: asynchronous job identifier * @@ -407,7 +406,6 @@ qemuHotplugRemoveDBusVMState(virDomainObj *vm, /** * qemuHotplugAttachManagedPR: - * @driver: QEMU driver object * @vm: domain object * @src: new disk source to be attached to @vm * @asyncJob: asynchronous job identifier @@ -499,7 +497,6 @@ qemuHotplugRemoveManagedPR(virDomainObj *vm, /** * qemuDomainChangeMediaBlockdev: - * @driver: qemu driver structure * @vm: domain definition * @disk: disk definition to change the source of * @oldsrc: old source definition diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 33cc0f0ffe..6d6349777d 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -948,7 +948,6 @@ qemuMigrationSrcNBDCopyCancelOne(virDomainObj *vm, /** * qemuMigrationSrcNBDCopyCancel: - * @driver: qemu driver * @vm: domain * @abortMigration: The migration is being cancelled. * diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c index dd47516742..b698897062 100644 --- a/src/qemu/qemu_migration_params.c +++ b/src/qemu/qemu_migration_params.c @@ -1074,7 +1074,6 @@ qemuMigrationParamsApplyValues(virDomainObj *vm, /** * qemuMigrationParamsApply - * @driver: qemu driver * @vm: domain object * @asyncJob: migration job * @migParams: migration parameters to send to QEMU @@ -1276,7 +1275,6 @@ qemuMigrationParamsTLSHostnameIsSet(qemuMigrationParams *migParams) /* qemuMigrationParamsResetTLS - * @driver: pointer to qemu driver * @vm: domain object * @asyncJob: migration job to join * @apiFlags: API flags used to start the migration -- 2.27.0

1 0

[PATCH v2 0/6] util: log infor to help troubleshoot file/socket open failures
by Laine Stump 09 Apr '26

09 Apr '26

The first couple patches are just related cleanups I noticed while doing the others, then a couple patches to simplify adding more lines to the bannder printed at the top of the log, and then finally the last couple patches add some info to the banner at the top of the log that would be generally useful when trying to understand why some random file or socket failed to be created or opened. V2: I've fixed a few nits Peter found, and modified the format and contents of the banner based on suggestions from Peter and Daniel Laine Stump (6): util: log the name of the log directory that couldn't be created util: consistently use typedef virLogMetadata util: eliminate duplicate code in virLogVMessage util: make it easier to add lines to the log "init banner" util: add info to log banner about uid and user environment util: add info about g_get_user_*_dir directories to log banner src/util/virlog.c | 226 ++++++++++++++++++++++++++++++---------------- src/util/virlog.h | 4 +- tests/testutils.c | 2 +- 3 files changed, 150 insertions(+), 82 deletions(-) -- 2.53.0

2 11

[PATCH 0/6] util: log infor to help troubleshoot file/socket open failures
by Laine Stump 09 Apr '26

09 Apr '26

The first couple patches are just related cleanups I noticed while doing the others, then a couple patches to simplify adding more lines to the bannder printed at the top of the log, and then finally the last couple patches add some info to the banner at the top of the log that would be generally useful when trying to understand why some random file or socket failed to be created or opened. Ideas on what else to add (or what to remove, or how to better format it) are welcome! Laine Stump (6): util: log the name of the log directory that couldn't be created util: consistently use typedef virLogMetadata util: eliminate duplicate code in virLogVMessage util: make it easier to add lines to the log "init banner" util: add info to log banner about uid and user environment util: add info about g_get_user_*_dir directories to log banner src/util/virlog.c | 231 ++++++++++++++++++++++++++++++---------------- src/util/virlog.h | 4 +- tests/testutils.c | 2 +- 3 files changed, 155 insertions(+), 82 deletions(-) -- 2.53.0

4 20

[PATCH 0/2] util: Move udev settle wait to vNIC create functions
by Michal Privoznik 09 Apr '26

09 Apr '26

See 1/2 for in depth explanation. Michal Prívozník (2): util: Wait for udev to settle after creating vNIC virnetdevmacvlan: Drop udev busy loop from virNetDevMacVLanTapOpen() src/util/virnetdevmacvlan.c | 24 ++++++++++-------------- src/util/virnetdevtap.c | 6 ++++++ src/util/virnetdevveth.c | 4 ++++ 3 files changed, 20 insertions(+), 14 deletions(-) -- 2.52.0

4 7

[PATCH 00/16] qemu: reduce direct usage of cfg->user
by Cole Robinson 08 Apr '26

08 Apr '26

In the qemu driver, cfg->user and cfg->group are `user` and `group` from qemu.conf, the default qemu process user and owner for the security DAC driver. These are driver wide default configuration. They are used throughout driver code for storage access and launching sub processes. However code using cfg->user and cfg->group directly is usually subtly wrong, because these values can be overridden for individual VMs with XML like: <domain> <seclabel type='static' model='dac' relabel='yes'> <label>+1234:+4567</label> </seclabel> </domain> Most of the qemu storage code already gets this right (where these values can also be overridden at the <disk> level). This series fixes many other users by reusing the existing qemuDomainGetImageIds function used by the storage code. https://redhat.atlassian.net/browse/RHEL-119651 Cole Robinson (16): qemu: require non-NULL 'cfg' in qemuDomainGetImageIds() qemu: tweak qemuDomainGetImageIds() argument handling qemu: saveimage: use qemuDomainGetImageIds() qemu: domain taint: use qemuDomainGetImageIds() qemu: migrate to file: use qemuDomainGetImageIds() qemu: core dump: use qemuDomainGetImageIds() qemu: storage stat: use qemuDomainGetImageIds() qemu: tpm: use qemuDomainGetImageIds() qemu: block copy: use qemuDomainGetImageIds() qemu: cpu compare: use qemuDomainGetImageIds() qemu: nvram: use qemuDomainGetImageIds() qemu: simplify qemuProcessPrepareDomainStorage() args qemu: nbdkit: use qemuDomainGetImageIds() qemu: remove qemuDomainOpenFile() TODO comment qemu: don't check virParseOwnershipIds() error qemu: use qemuDomainGetImageIds() in qemuDomainOpenFile() src/qemu/qemu_backup.c | 12 +-- src/qemu/qemu_domain.c | 150 +++++++++++++++++++------------------- src/qemu/qemu_domain.h | 14 ++-- src/qemu/qemu_driver.c | 25 +++++-- src/qemu/qemu_hotplug.c | 6 +- src/qemu/qemu_migration.c | 5 +- src/qemu/qemu_process.c | 20 ++--- src/qemu/qemu_saveimage.c | 5 +- src/qemu/qemu_snapshot.c | 6 +- src/qemu/qemu_tpm.c | 6 +- 10 files changed, 130 insertions(+), 119 deletions(-) -- 2.53.0

2 37

[PATCH 0/6] qemu: sync initial dir perms with RPM spec
by Cole Robinson 08 Apr '26

08 Apr '26

The qemu driver creates a bunch of directories at startup, example /var/lib/libvirt/qemu/*. The initial mode mask on these directories is almost always specified as 0777, which leaves it up to umask to lock things down. As a result, if running from git, directories are usually created 0755 which seems overly permissive for a system daemon. This doesn't have much effect from RPM users at least, since the spec file pre-creates most of these directories with more limited permissions. This series syncs the code to match what we already specify in the spec file. Code is simplified first, and some missing dirs are added to the spec at the end. Cole Robinson (6): qemu: driver: split out qemuStateInitializeDirs qemu: driver: streamline dir creation qemu: driver: don't chown() dirname(cfg->channelTargetDir) qemu: driver: sync dir creation permissions with RPM spec qemu: driver: adjust mode mask for rdpStateDir qemu: driver: adjust mode mask for channelTargetDir libvirt.spec.in | 2 + src/qemu/qemu_driver.c | 249 ++++++++++++----------------------------- 2 files changed, 74 insertions(+), 177 deletions(-) -- 2.53.0

2 12

FYI: possible mailman service disruption 2026/04/08
by Daniel P. Berrangé 08 Apr '26

08 Apr '26

The hosting of the libvirt mailman instance will be moving to a new location tomorrow on 2026/04/08, at around 0900-1000 UTC. While we don't expect any significant loss of service, there could be minor short term, temporary disruption for sending emails while DNS records update. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|

1 1

[PATCH v2 0/2] remote: Remove dependency of virt-secret-init-encryption from libvirtd
by Arun Menon 08 Apr '26

08 Apr '26

The monolithic libvirtd.service currently has a dependency on virt-secret-init-encryption.service. This causes libvirtd to fail to start on systems where the secret driver is not installed or enabled, as systemd cannot satisfy the Requires= unit or the LoadCredentialEncrypted= path. See below, Requires=virt-secret-init-encryption.service LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key This series accomplishes the following: The first commit decouples the secrets encryption logic from the main libvirtd service file. It is moved into a new systemd drop-in (10-secret.conf) which is only installed when libvirt is built with secret driver support. The override snippet is added to the daemon-driver-secret package. The second commit is a simple refactoring configuration_data of virt-secret-init-encryption. No functional change is intended. Arun Menon (2): remote: Move secrets encryption dependency to a systemd drop-in secret: Update virt_secret_init_encryption_conf initialization libvirt.spec.in | 2 ++ src/remote/libvirtd.service.in | 4 ---- src/remote/meson.build | 15 +++++++++++++++ src/remote/secret.conf.in | 7 +++++++ src/secret/meson.build | 6 +++--- 5 files changed, 27 insertions(+), 7 deletions(-) create mode 100644 src/remote/secret.conf.in -- 2.53.0

3 5