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

[Eric Blake]

On 04/23/2018 04:31 AM, Vladimir Sementsov-Ogievskiy wrote:

>> And if there is more than one bitmap on snap1, do we
>> need to bring all of those bitmaps forward into snap2, or just the one
>> that was currently active?
> 
> Again, I think, to make snapshots unrelated, it's better to keep them
> all. Let disk snapshot to be a snapshot of dirty-bitmaps too.

So that means creating a new external snapshot (a new qcow2 wrapper)
should copy all existing bitmaps from the backing file into the new
active layer?

> 
>> Similarly, if we later decide to live commit
>> snap2 back into snap1, we'll want to merge the changes in snap2.B2 back
>> into snap1.B1 (now that snap1 is once again active, it needs to track
>> all changes that were merged in, and all future changes until the next
>> snapshot).
> 
> And here we will just drop older versions of bitmaps.
> 
>>   Which means we need to at least be thinking about cross-node
>> snapshot merges,
> 
> hmm, what is it?

By "cross-node snapshot merge", I meant the situation where we have:

base <- snap1 (containing bitmap B1) <- snap2 (containing bitmap B2)

If we need to create a bitmap containing the merge of B1 and B2, whether
that new bitmap B3 is stored in snap1 or in snap2, we are doing a
cross-node merge (because the two source bitmaps in the merge live on
different nodes of the backing chain).

-- 
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/20180423/6e624491/attachment-0001.sig>