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.                                                                   


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

(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?


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?

libvir-list mailing list

Reply via email to