On Sat, Sep 08, 2018 at 19:28:47 +0200, Gionatan Danti wrote:
Il 07-09-2018 21:26 Eric Blake ha scritto:
[...]
> > - 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?
It was not implemented because currently we don't track what happens to
the backing chain after a successful commit, but rather we redetect it
afterwards.
The commit operation can remove more than one image from the backing
chain and thus tracking what happened is very important if you want to
remove the files afterwards.
I'm currently working on supporting -blockdev which includes full
backing chain tracking so the implementation of deletion of the images
obsoleted with block commit will become much simpler [*].
Peter
[*] I'm not promising to implement that feature soon though.