[libvirt] [RFC]: Snapshot API

Matthias Bolte matthias.bolte at googlemail.com
Tue Mar 23 18:35:22 UTC 2010


2010/3/23 Chris Lalancette <clalance at redhat.com>:
> Hello,
>     As some of you know, I've been working on a new snapshot API.
> This API is heavily based on DanB's earlier API proposed here:
>
> https://www.redhat.com/archives/libvir-list/2010-January/msg00626.html
>
> I've made some modifications to make it more libvirt-ish, and to add a
> couple of features I think it lacked.  The full documentation is below.
> Any comments are appreciated.
>
> /* NOTE: struct _virDomainSnapshot is a private structure, ala
>  * struct _virDomain.
>  */
> typedef struct _virDomainSnapshot virDomainSnapshot;
>
> /* Take a snapshot of the current VM state */
> virDomainSnapshotPtr virDomainSnapshotCreateXML(virDomainPtr domain,
>                                                const char *xmlDesc,
>                                                unsigned int flags);
>
> /* Dump the XML of a snapshot */
> /* NOTE: see below for proposed XML */
> char *virDomainSnapshotGetXMLDesc(virDomainSnapshotPtr snapshot,
>                                  unsigned int flags);
>
> /* Return the number of snapshots for this domain */
> int virDomainSnapshotNum(virDomainPtr domain, unsigned int flags);

Shouldn't this be called virDomainNumOfSnapshots to be consistent with
the naming or other num-of functions?

>
> /* Get the names of all snapshots for this domain */
> int virDomainListSnapshotNames(virDomainPtr domain, char **names, int nameslen,
>                               unsigned int flags);
>
> /* Get a handle to a named snapshot */
> virDomainSnapshotPtr virDomainSnapshotLookupByName(virDomainPtr domain,
>                                                   const char *name,
>                                                   unsigned int flags);
>
> /* Set this snapshot as the current one for a domain, to be
>  * used next time domain is started */
> int virDomainSnapshotActivate(virDomainSnapshotPtr snapshot,
>                              unsigned int flags);

This delayed semantic cannot be implemented for ESX. ESX can revert to
a snapshot immediately only. I think the same holds true for
VirtualBox.

Maybe I misunterstand this. What should happen if you call activate on
a running domain?

> /* Deactivate a snapshot - with no flags, the snapshot is not used anymore,
>  * but also not removed.  With a MERGE flag, it merges the snapshot into
>  * the base image.  With a DISCARD flag, it deletes the snapshot.  MERGE
>  * and DISCARD are mutually-exclusive.  Note that this operation can
>  * generally only happen when the domain is shut down, though this is
>  * hypervisor-specific */
> typedef enum {
>    VIR_DOMAIN_SNAPSHOT_DEACTIVATE_MERGE,
>    VIR_DOMAIN_SNAPSHOT_DEACTIVATE_DISCARD,
> } virDomainSnapshotDeactivate;
> int virDomainSnapshotDeactivate(virDomainSnapshotPtr snapshot,
>                                unsigned int flags);

I'm not sure if virDomainSnapshotDeactivate is a good name.

Why would I deactivate a snapshot, but not merge/discard it? What's
the use case for this?

> int virDomainSnapshotFree(virDomainSnapshotPtr snapshot);
>
> NOTE: During snapshot creation, *none* of the fields are required.  That is,
> you can call virDomainSnapshotCreateXML() with an XML of "<domainsnapshot/>".
> In this case, the individual driver will make up a <name> for you, the
> <creationdate> will be set to the current time+date, <description> will be
> empty, <state> will be "off", <compression> will be empty, and <parent> will
> be empty.  If you do want to specify some fields during
> virDomainSnapshotCreateXML(), note that the only ones that are settable are
> <name>, <description>, <compression>, and <parent>; the rest are ignored,

How can <parent> be settable? If I have snapshots A and B

  A -> B -> current state

and I create a new snapshot C, then B will be the parent of C.

  A -> B -> C -> current state

If I create another snapshot D now and specify A to be its parent,
what's supposed to happen then?

Matthias




More information about the libvir-list mailing list