RFC: revert to external snapshot API

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Tue Aug 31 13:46:25 UTC 2021

Hi, all.

I want to implement reverting to external snapshot functionality.
I've checked the mailing list history and found some previous attempts
(not sure if this is a complete list of them).

[1] was done in 2012 by the Redhat team itself. [2] and [3] was done in
Looks like it was not clear how the API should look like.

For example we have disk.qcow2 <- disk.snap1 chain <- disk.snap2 chain
having snap1 and snap2 snapshots). Now we want to revert to snap1 snapshot.
snapshot state is held by disk.qcow2 image. We can run reverted domain on
disk.qcow2 itself but then we lose snap1 (held by disk.qcow2) and snap2
(held by disk.snap1). So we definitely should run on some overlay over
disk.qcow2. But then what name should be given to overlay? We should have
an option for mgmt to specify this name like in case of snapshots itself.

The [1] has some discussion on adding extra options to reverting
Like for example if we revert back to snap2 then having the ability to run
state in disk.snap2 rather than disk.snap1. My opinion is there is no need
as if one wants to revert to the state of disk2.snap2 it can take a
snapshot (some
snap3). At the same time one needs to be aware that revert operation loses
current state and later one can revert only to the states of snapshots.
This is the way internal snapshots work and the way one expects external
snapshots to work too.

The [2] takes an approach of reusing current top image as overlay on revert
that in the above example disk.snap2 will be overlay over disk.qcow2 on
reverting to snap1 snapshot. IMHO this is a confusing naming scheme.

The [3] suggests a different scheme for naming images. For example after
snapshot snap1 the chain should be disk.snap1 <- disk.qcow2 which looks very
appealing to me. With this naming using the [2] approach is quite natural.
Implementing this does not look hard even for a running domain but this is
a big change to API and all mgmt need to be aware of (well it could be done
safely using a new flag).

Anyway we can go on with current image names. In order to specify overlay
image name let's introduce new API:

    int virDomainRevertToSnapshotXML(virDomainSnapshotPtr snapshot,
                                     char *xmlDesc,
                                     unsigned int flags)

with XML like:

        <disk name='vda'>
          <source file='/path/to/revert/overlay'/>

Having an XML looks like a bit overkill right now but I could not
find a better solution.

If overlay name is omitted the generated name will be like disk.snap1-1 in
above example to be in alignment with creating a snapshot case. So that
images hold states derived from snap1 state. We can also support reverting
external snapshot thru existing virDomainRevertToSnapshot for those who
rely on
generated names using this naming scheme.

[1] Re: [PATCHv4 4/4] snapshot: qemu: Implement reverting of external

[2] Re: [PATCH 1/5] snapshot: Implement reverting for external disk

[3] External disk snapshot paths and the revert operation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210831/615eb168/attachment-0001.htm>

More information about the libvir-list mailing list