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.
