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

[Eric Blake]

On 04/13/2018 04:47 AM, Nikolay Shirokovskiy wrote:

>>>> Earlier, you said that the new virDomainBlockSnapshotPtr are
>>>> independent, with no relations between them.  But here, you are wanting
>>>> to keep incremental backups related to one another.
>>>
>>> Yes, but backups are not snapshots. All backup relation management are on
>>> client. In pull backup scheme libvirt is only here to export a snapshotted
>>> disk state with optionally a CBT from some point in time. Client itself
>>> makes backups and track their relationships.
>>>
>>> However as we use chain of disabled bitmaps with one active bitmap on tip
>>> of the chain and qemu does not track their order we need to do it in
>>> libvirt.
>>>
>>
>> Well, you seem to be tracking it in *qemu*, by using the name field.
>> Should we not make a commitment to whether or not we store this lineage
>> information in either qemu OR libvirt, but not distributed across both...?
>>
> 
> I don't know actual use cases to decide. A commitment that this meta is stored
> in disks like proposed can be useful IMHO so that mgmt can expect that dumb reinserting
> disks to a different domain (recreated for example) keep all checkpoints.

I'm still trying to figure out how to represent checkpoint metadata in
libvirt XML; I'm not yet sure whether exposing it directly in <domain>
makes sense, or whether checkpoints should be more like <domainsnapshot>
in that they are a separate object, each containing a copy of the
<domain> at the time they were created, and allowing parent->child
relationships between objects that were created along the same
guest-visible timeline of events.  But your comment about wanting to
store lineage information between checkpoints in the qcow2 metadata, so
that you can recreate that lineage when inserting that qcow2 file into a
different <domain>, feels rather fragile.

With <domainsnapshot>, libvirt has APIs for recreating snapshot objects
to (re-)teach libvirt about state that was copied from some other
location.  It seems like having a similar way to recreate checkpoint
objects would be the proper way to plug in a qcow2 file with persistent
bitmaps already existing, in order to get libvirt to know the proper
<checkpoint> relationships that it can now use from that qcow2 file.

-- 
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/c4c01982/attachment-0001.sig>