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