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

[Eric Blake]

On 04/11/2018 11:14 PM, John Snow wrote:
>>> 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.                                              
>>
> 
> Oh, I see -- you're using blockdev-backup sync=none to accomplish
> fleecing snapshots. It's a little confusing here without the sync=none
> information, as usually blockdev-backup provides... backups, not snapshots.

Right now, I'm leaning towards a single
virDomainBackupStart()/virDomainBackupEnd() pair that work for both push
and pull model backups:

push model: Start() command points to the place to use as the
destination that qemu will push to; it either provides the checkpoint to
start from (qemu's "sync":"incremental", using the appropriate bitmap(s)
to construct how much data to actually push to the destination), or
omits the checkpoint (full backup, qemu's "sync":"full"); optionally
creates a new checkpoint at the same time; emits a libvirt event to note
when the backup job is complete; then user calls End() to tear down any
resources (qemu can no longer write to the destination)

pull model: Start() command points to place to use as temporary storage
so that guest can continue to write, AND includes the details of the NBD
server to set up for third-party access to the backup. The command
optionally provides the checkpoint to expose over NBD (which gets
translated into the bitmap(s) to expose as block status), or omits it
(the third party has to assume that the full image is dirty); either
way, the temporary storage uses "sync":"none", and it is up to the third
party connecting to NBD how much of the image to read (whether a
checkpoint was specified or not, the third-party can read the entire
image if desired, or only a fraction of the image if desired; but a
checkpoint has to be provided if the third party plans on learning how
much of the image to read to capture an incremental backup).  There is
no event emitted by libvirt; the user calls End() when the third-party
client is done using the NBD connection.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180418/b04c9057/attachment-0001.sig>