Re: [libvirt] RFC: API additions for enhanced snapshot support

On 07/05/2011 04:26 AM, Osier Yang wrote: 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. 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. 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(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org