Hello!

I'd like to leave a trace for others hitting this issue. QEMU 10.0.7,
present in debian Trixie,
has a bug leading to corruption of guest qcow2 image in the following scenario:

* have qcow2 images for VM guest drives
* have high ongoing disk IO activity within the guest during the steps below
* virsh snapshot-create-as --domain VMNAME --name "kvmsnap-VMNAME"
--no-metadata --atomic --disk-only vdX,external
* wait a bit - during this time I'm running rsync to copy VM's qcow2 files
* virsh blockcommit VMNAME vdX--active --pivot --verbose

Corruption happens rarely, is not guaranteed to happen. Nevertheless
others have seen
it happening as well. Please see for ongoing discussion, so far
there's no official fix.
https://gitlab.com/qemu-project/qemu/-/issues/3273.

Looks like it's a regression starting from qemu 8.2.0 affecting that
and later releases.

Possibly disabling default discard='unmap' might resolve it at the
expense of faster wear of
the underlying SSD/NVMe storage and performance.



Thanks for maintenance of this package!