[libvirt] [PATCH 6/8] qemu: checkpoint: Forbid creating checkpoints until we support backups

[Eric Blake]

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 at 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