[libvirt] RFC: API additions for enhanced snapshot support

[Eric Blake]

On 07/05/2011 04:26 AM, Osier Yang wrote:
> 
> Does it also need to enhance volume's XML so that it can include
> <volSnapshot>....</volSnapshot>?

No.  We _don't_ want to modify virStorageVolGetXMLDesc to output
snapshot information from a virStorageVolPtr, rather you would use the
new APIs to query whether a virStorageVol has associated snapshot
information, and if so, grab a new virStorageVolSnapshotPtr object that
wraps the information, and use virStorageVolSnapshotGetXMLDesc on that
new object to get the <volSnapshot> XML.

That is, this is parallel to the existing virDomainPtr and
virDomainSnapshotPtr - the XML for a given domain does not give you any
details about snapshots (or checkpoints) tied to the domain; rather, you
use the virDomainSnapshot API to get the corresponding snapshot object
tied to a domain, then do all your queries on the snapshot object.

>  Since you are already planning
> to introduce kinds of new storage volume APIs. One might want to
> manage the snapshots without domain.

That's the whole point of my RFC.  The _existing_ virDomainSnapshot APIs
allow management of checkpoints (disk + memory), and can easily be
extended to also manage snapshots (disk only) associated with a domain,
whereas my proposed new virStorageVolSnapshot API is for management of
snapshots of a given disk image without an associated domain.

> If so, it might also need modifications on bunch of internal storage
> volume APIs, such as volDelete, volCreateFromXML, volGetXMLDesc.
> etc, it might also need to introduce new flags for the according public
> APIs, the good is that it seems all of these APIs has "flags" argument.

I'm not sure I follow what additional modifications you are envisioning,
although I'll give it a shot:

Right now, virStorageVolDelete has a flags argument, but does not have
any defined flags.  What should happen if the virStorageVolPtr has
associated snapshots?  I can see the use of adding new flags:

virStorageVolDelete(,0) - fail if there are associated snapshots
virStorageVolDelete(,VIR_STORAGE_VOL_DELETE_SNAPSHOTS) - delete both the
image and all snapshots associated with the image

I don't see any changes to virStorageVolGetXMLDesc.

Right now, virStorageVolCreateFromXML creates a clone storage volume,
and takes a flags argument but no defined flags.  What happens if the
input virStorageVolPtr clonevol passed to that API has associated
snapshots?  Will the new volume also have the same snapshots as the old
volume?  Will the cloning also duplicate the snapshots?  Is the new
volume a flattened version of the input (no backing files in the new
image)?  There are probably several useful behaviors, and I'm not sure
whether they should be controlled by new flags, by new elements in the
xmldesc argument, or some combination of those.  But you certainly have
a point that there is more to think about when cloning an existing
volume if that existing volume has associated snapshots.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110705/8e0e8086/attachment-0001.sig>