[libvirt] [RFC v2] external (pull) backup API

[John Snow]

On 04/03/2018 08:01 AM, Nikolay Shirokovskiy wrote:
> Hi, all.                                                                                         
>                                                                                                  
> This is another RFC on pull backup API. This API provides means to read domain                   
> disks in a snapshotted state so that client can back them up as well as means                    
> to write domain disks to revert them to backed up state. The previous version                    
> of RFC is [1]. I'll also describe the API implementation details to shed light                   
> on misc qemu dirty bitmap commands usage.                                                        
>                                                                                                  
> This API does not use existent disks snapshots. Instead it introduces snapshots                  
> provided by qemu's blockdev-backup command. The reason is we need snapshotted                    
> disk state only temporarily for duration of backup operation and newly                           
> introduced snapshots can be easily discarded at the end of operation without                     
> block commit operation. Technically difference is next. On usual snapshot we                     
> create new image backed by original and all new data goes to the new image thus                  
> original image stays in a snapshotted state. In temporary snapshots we create                    
> new image backed by original and all new data still goes to the original image                   
> but before new data is written old data to be overwritten is popped out to the new               
> image thus we get snapshotted state thru new image.                                              
>                                                                                                  
> Disks snapshots as well as disks itself are avaiable to read/write thru qemu                     
> NBD server.                                                                                      

[snip!]

Do you think it's possible to characterize this API proposal as two
mechanisms:

(1) A mechanism for creating and manipulating "checkpoints" -- which are
book-ended by bitmap objects in QEMU -- implemented by the creation,
deletion, 'disabling' and 'merging' of bitmaps, and

(2) A mechanism for the consumption of said checkpoints via NBD / the
"fleecing" mechanisms that allow a live export of a static view of the
disk at that time (block snapshots + NBD exports)

If this is the case, do you think it is possible to consider (1) and (2)
somewhat orthogonal items -- in so far as it might be possible to add
support to libvirt directly to add push-model support for writing out
these checkpoints?

i.e.

once you have created a temporary snapshot and merged the various
component bitmaps into it, instead of creating an ephemeral block
snapshot and exporting it via NBD, we request a `blockdev-backup` with a
libvirt-specified target instead?

You don't have to add support for this right away, but I would really
enjoy if any API we check in here has the capacity to support both
push-and-pull paradigms without getting too ugly.

Does that sound like it can easily fit in with your designs so far?