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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
