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

[John Snow]

On 04/12/2018 04:58 AM, Nikolay Shirokovskiy wrote:
> On 11.04.2018 19:32, Eric Blake wrote:
>> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:


[snip]


>>
>> I'm trying to figure out how BlockCheckpoint and BlockSnapshots relate.
>> Maybe it will be more clear when I read the implementation section
>> below.  Is the idea that I can't create a BlockSnapshot without first
>> having a checkpoint available?  If so, where does that fit in the
>> <domainblocksnapshot> XML?
> 
> No, you can create snapshot without available checkpoints. Actually the first snapshot
> is like that.
> 
> Now if you create a snapshot with checkpoint and then delete the snapshot
> the checkpoint remains, so we need an API to delete them if we wish.
> 

Hmm - OK, you are being careful to label three notions separately:

(1) Checkpoints (which are metadata objects in libvirt supported by
bitmaps in QEMU, roughly)
(2) BlockSnapshots (which expose data using checkpoints as metadata)
(3) Backups (which are made by a 3rd party client using a snapshot)

In this case, though, if a snapshot is requested it probably ought to be
*prepared* to create a checkpoint in case that snapshot is used by the
third party client to make a backup, right?

IOW, a snapshot -- though ignorant of how it is used -- can be and often
will be used to accomplish an incremental backup and as such must be
prepared to manipulate the checkpoints/bitmaps/etc in such a way to be
able to make a new checkpoint.

Right?


[snip]


>> 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...?