On Tue, Nov 30, 2021 at 08:15:30 +0200, Jeff Brown wrote:
Please advise:
After a scheduled crontab snapshot backup of a VM it failed to do a blockcommit, and is currently writing to both the snapshot and the original QCOW2 images.
(I don't think it's a bug, and suspect that I caused it by running the backup script manually while the snapshot was already running.)
$ virsh blockcommit VM sda --active --pivot --shallow --verbose error: block copy still active: disk 'sda' already in active block job
The '--pivot' switch here ...
$ virsh blockjob VM sda --info Active Block Commit: [100 %]
$ virsh domblkerror VM No errors found
Running on Debian 9 (Stretch).
$ virsh version Compiled against library: libvirt 3.0.0 Using library: libvirt 3.0.0 Using API: QEMU 3.0.0 Running hypervisor: QEMU 2.8.1
(this is a rather old libvirt version, but what I suggest below should work)
Now, I've read up on the probable solution, somewhat, but running $ virsh blockjob $domain --abort on this production server scares me; and I'm just asking whether it would be advisable to stop services and make a full data backup prior to doing so? It would entail taking the services offline for at least an hour. The snapshot is currently at 12GB, and according to blockjob --info the VM image is 100% in synch.
... is equivalent to do a 'virsh blockjob $VM $DISK --pivot' after the blockjob is complete. In your case, the original virsh invocation was probably killed or missed the finishing event and thus didn't finalize the blockjob.