[libvirt] [PATCH v4 00/20] Incremental Backup API additions

[Peter Krempa]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190218/7803aa4e/attachment-0001.sig>