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