On Mon, Feb 18, 2019 at 17:16:41 +0100, Kashyap Chamarthy wrote: > On Wed, Feb 06, 2019 at 01:17:58PM -0600, Eric Blake wrote: > > The following is the latest version of my API proposal for > > incremental backups, and follows along from the demo I presented > > as part of my KVM Forum 2018 talk: > > https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup-eric-blake-red-hat > > > > The patches are also available via https://repo.or.cz/libvirt/ericb.git > > at the tag backup-v4. > > > > Integration with external snapshots is still not included in these > > patches, although I have been playing more with that locally, and > > I still haven't gotten a working demonstration of a push-mode > > incremental backup. > > > > At this point, I'm posting mainly because there have been enough > > changes in qemu (the backup APIs are now stable! and in qemu.git > > in time for 4.0) and libvirt (several releases and code cleanups > > in between, such that the v3 no longer applies easily), while I > > continue to work locally on more features, addressing the review > > comments I got on v3, and remove the 'wip' tag on several of the > > later patches. > > > > Among other things, I still haven't determined how we want to > > integrate checkpoints with external snapshots; we could either have: > > > > virDomainSnapshotCreateXML("<domainsnapshot>...") # existing > > virDomainBackupBegin("<domainbackup>...", "<domaincheckpoint>...") # this series > > virDomainSnapshotCheckpointCreateXML("<domainsnapshot>...", "<domaincheckpoint>...") # new > > A slightly related question: when these new APIs (thanks for working on > them!) are merged, am I right in assuming that they should be able to > "replace" the existing (and provide additional): > > virDomainBlockRebase(); and > virDomainBlockCopy() > > ... _provided_ that an application is adjusted to using libvirt that is > new enough to drive QEMU's '-blockdev', QMP `blockdev-add` et al? > > Or is that (the new APIs being backward-compatible with blockRebase() > and blockCopy()) an explicit non-goal? > > I'm only this out of curiosity. The checkpoints are really orthogonal to the backing chain/shapshot managemet. Checkpoints don't really store any data but rather provide a way to determine which blocks were changed and thus need backup. Also one point is that checkpoints don't allow (or I did not notice it in the proposal) to capture memory state along with the disk state. In the ideal world of snapshots when deletion/revertion was implemented we'd never expose the virDomainBlockCommit and virDomainBlockPull APIs including the multi-use backdoor virDomainBlockRebase() which should have never existed and users would do equivalent operations using the snapshot APIs. virDomainBlockCopy is useful on it's own though but badly combines with snapshots. This will need some fixing. With the new checkpoint APIs the situation is even more "fun" as modification of the backing chain involves in some cases changes to the bitmaps. Ideally these would do "the right thing (TM)" during snapshot deletion/reversion. Given that at this time we don't support snapshot deletion/reversion for external snapshots we can use the excuse that snapshot management is not implemented so that checkpoints don't need to be modified. Since virDomainBlockCommit/virDomainBlockPull are basically a backdoor to do snapshot merging which is not actually recorded in the snapshot XML the same damage can happen to the checkpoints. I'm not sure how we want to deal with that at this point though.
Attachment:
signature.asc
Description: PGP signature
