On 4/24/19 8:26 AM, Peter Krempa wrote: > On Wed, Apr 17, 2019 at 09:09:03 -0500, Eric Blake wrote: >> Introduce a bunch of new public APIs related to backup checkpoints. >> Checkpoints are modeled heavily after virDomainSnapshotPtr (both >> represent a point in time of the guest), although a snapshot exists >> with the intent of rolling back to that state, while a checkpoint >> exists to make it possible to create an incremental backup at a later >> time. >> >> The following map shows the API relations to snapshots, with new APIs >> on the right: >> >> Operate on a domain object to create/redefine a child: >> virDomainSnapshotCreateXML virDomainCheckpointCreateXML >> >> Operate on a child object for lifetime management: >> virDomainSnapshotDelete virDomainCheckpointDelete >> virDomainSnapshotFree virDomainCheckpointFree >> virDomainSnapshotRef virDomainCheckpointRef >> >> Operate on a child object to learn more about it: >> virDomainSnapshotGetXMLDesc virDomainCheckpointGetXMLDesc >> virDomainSnapshotGetConnect virDomainCheckpointGetConnect >> virDomainSnapshotGetDomain virDomainCheckpointGetDomain >> virDomainSnapshotGetName virDomainCheckpiontGetName >> virDomainSnapshotGetParent virDomainCheckpiontGetParent >> virDomainSnapshotHasMetadata virDomainCheckpointHasMetadata >> virDomainSnapshotIsCurrent virDomainCheckpointIsCurrent > > The 'current' checkpoint has very sparse documentation. While it makes > some sense for the current snapshot to exist I'm not persuaded we need > this for checkpoints. > > In case of checkpoints the bitmaps backing it track the state even if > you create a new bitmap unlike checkpoints. Thus it does not seem to > make sense to me. > > If you think it does please elaborate, ideally in form of documentation. I can add documentation, but the short answer is that there are two ways to implement differential backups: 1. One active bitmap for every point in time that you might ever need a differential backup from; if you have 20 checkpoints, then you have 20 active bitmaps, and each guest write has to potentially modify all 20 bitmaps, but backups can directly use the desired bitmap and nothing else for that particular backup: Time: T1 T2 T3 T4 present Bitmap1: -------------------------------- Bitmap2: -------------------------- Bitmap3: ------------------- Bitmap4: ------------ 2. One disabled bitmap for every delta between two consecutive points in time, plus one active bitmap since the most recent point in time; if you have 20 checkpoints, then you have 19 disabled bitmap and 1 active 1, where each guest write only has to modify 1 bitmap, but backups have to construct a temporary bitmap that contains the union of all bitmaps that span the time in question: Time: T1 T2 T3 T4 present Bitmap1: ------ Bitmap2: ------- Bitmap3: ------- Bitmap4: ------------ Given that guest writes are more frequent than backup operations, and that performing the creation of a temporary bitmap to merge together other bitmaps at the start of a bitmap is not all that onerous, the code goes with approach 2. And, since there is always 1 active bitmap while the rest are disabled, it lends itself well to the notion of a current checkpoint (one that is tracking active guest writes). > >> Operate on a domain object to list all children: >> virDomainSnapshotNum (no counterpart, this is the old >> virDomainSnapshotListNames racy interface) >> virDomainSnapshotListAllSnapshots virDomainListAllCheckpoints >> >> Operate on a child object to list descendents: >> virDomainSnapshotNumChildren (no counterpart, this is the old >> virDomainSnapshotListChildrenNames racy interface) >> virDomainSnapshotListAllChildren virDomainCheckpointListAllChildren >> >> Operate on a domain to locate a particular child: >> virDomainSnapshotLookupByName virDomainCheckpointLookupByName >> virDomainHasCurrentSnapshot virDomainHasCurrentCheckpoint >> virDomainSnapshotCurrent virDomainCheckpointCurrent >> >> Operate on a snapshot to roll back to earlier state: >> virDomainSnapshotRevert (no counterpart, instead checkpoints >> are used in incremental backups via > > This patch or a different one should also add docs to virDomainSnapshotRevert > that outline what happens to the checkpoints when reverting snapshots. Right now, it needs to be an error (until we actually design how the two should play together nicely, the most conservative approach is to state that reverting a domain with checkpoints risks enough confusion to be forbidden in the initial implementation, even if we lift that restriction later when we iron out how it should work). > > Basically what should happen is that an alternate reality should > probably be created as the disk images can change at that point > > >> XML to virDomainBackupBegin) >> >> Signed-off-by: Eric Blake <eblake@xxxxxxxxxx> >> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
