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

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.