On 9/26/19 10:51 AM, Peter Krempa wrote:
Checkpoints by themselves are not very useful for anything else than
testing the few bitmap interactions that are currently implemented.
It's very unlikely that anybody used this feature and thus we can
disable it until we have a more complete implementation ready.
Additionally the code for deleting checkpoints has many broken failure
scenarios which should be fixed first.
I suspect you are probably right.
This will require support of
deleting a bitmap in a qemu 'transaction' which was not released yet.
However, I'm not yet convinced on this point. Deleting a bitmap does
not have to be atomic with other actions from the standpoint of correct
contents of remaining bitmaps. I _do_ see that an atomic delete makes
it easier to delete multiple bitmaps at once, without having to worry
about failure states if one delete fails after another succeeded; but it
may still be possible to make things work without transactioned delete.
On the flip side, waiting to support checkpoints until qemu makes it
nice, and not worrying about older qemu, makes for less code to maintain.
Curious users obviously can use the qemu namespace in the XML to enable
this for experiments:
<domain type='kvm'
xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
<qemu:capabilities>
<qemu:add capability='incremental-backup'/>
</qemu:capabilities>
</domain>
Useful to know, for testing things in the meantime. Does this need to
go on any of our published documentation, perhaps in
docs/formatcheckpoint.html.in?
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_checkpoint.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org