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

[Nikolay Shirokovskiy]

On 18.04.2018 18:24, Eric Blake wrote:
> 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.
> 

It is proposed to introduce checkpoints and their relationships to qemu and qcow2 in [1].
So that no need to have libvirt metadata for that. Also checkpoints itself are not
enought to restore a domain of course so does it make sense to store domain config
with checkpoints? Looks like it is a backup client responsibility.

In case of push backups storing domain config looks useful. But we can distinguish
between checkpoints and backups.

[1] https://www.redhat.com/archives/libvir-list/2018-April/msg01306.html