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.