[libvirt-users] how "safe" is blockcommit ?

[Gionatan Danti]

Il 07-09-2018 21:26 Eric Blake ha scritto:
> We're also trying to add support for incremental backups into a future
> version of libvirt on top of the qemu 3.0 feature of persistent
> bitmaps in qcow2 images, which could indeed guarantee that you
> transfer only the portions of the guest disk that were touched since
> the last backup.  But as that's still something I'm trying to code up,
> your solution of using rsync to pick out the deltas is as good as
> anything you can get right now.

Plain rsync is going to be very slow for large file transfer. I strongly 
suggest to experiment with rsync "--inplace no-whole-file" options to 
really transfer/write changed bits only. If that does not cut in, you 
can try with bdsync[1] or blocksync[2]

[1] https://github.com/TargetHolding/bdsync
[2] https://github.com/shodanshok/blocksync

>> - blockcommit the overlay: blockcommit guest /path/to/testsn --active 
>> --wait --verbose --pivot
>> - delete the snapshot: snapshot-delete guest --snapshotname testsn 
>> --metadata
>> - remove the overlay
>> 
>> Is that ok ? How "safe" is blockcommit on a running guest ?
> 
> Yep, that's the right way to do it!  It's perfectly safe - the guest
> doesn't care whether it is reading/writing from the backing file or
> the overlay, and even if the blockcommit action is aborted, you can
> restart it for the same effects.

I found the "manual overlay rm" a bit of a pain. What is the reason why 
a successfull blockcommit does not delete the just-inactivate overlay 
file?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8