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

[John Snow]

On 04/13/2018 05:16 AM, Nikolay Shirokovskiy wrote:
> 
> 
> On 13.04.2018 00:16, John Snow wrote:
>>
>>
>> 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)
> 
> I can't share this view because checkpoints and snapshots are created
> in one transation in pull scheme so you can't not move these two to
> different mechs.
> 

That's not a problem - transactions are comprised of elementary actions,
so it's okay to make an artificial distinction between half of the
actions and half of the others if it aids in the composition of other
transaction types.

> I'll rather see 2 mechanism here at least for pull scheme.
> 
> 1. create snapshots (and optionally checkpoints)
> 2. export snapshots
> 

You're thinking more of the Libvirt API calls instead of the component
mechanisms these API manipulate, I think.

>>
>> 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?
>>
> 
> I think push scheme require 3rd (1st is fleece snapshots, 2nd is exporting
> snapshots) API. First push backup has nothing to do with exporting of course. Second
> contrary to fleece snapshots it will require additional parameter - a checkpoint
> in past in case of incremental backup. It also have quite different image parameter.
> In case of fleece snapshot fleece image will only store small delta even in case of
> full backups. In case of push backup image will store full disk in case of full
> backups.
> 
> Nikolay
> 

That doesn't sound too crazy. As long as the idea of a "checkpoint" can
be re-used for push-model backups, I am pretty happy with the design
overall as presented, once we iron out some of the technicalities, like:

(1) What do we name the API calls?
(2) Do we store metadata in the bitmap names?
(3) What does the XML look like?

etc. the general idea seems okay to me AFAICT. Eric Blake is currently
on a brief leave but will be back Tuesday. I think if you can resume
discussions with Daniel Berrange and Eric Blake on the API design we'll
be able to make progress here.

Thanks for your work so far,
--John