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.