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@xxxxxxxxxx> --- 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
