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

/* Opaque type to manage a snapshot of a single storage volume. */ typedef virStorageVolSnapshotPtr;

/* Revert a volume back to the state of a snapshot, returning 0 on success. Flags is 0 for now. */ int virStorageVolRevertToSnapsot(virStorageVolSnapshotPtr snapshot, unsigned int flags); [For qcow2, this would involve qemu-img snapshot -a. Here, a useful flag might be whether to delete any changes made after the point of the snapshot; virDomainRevertToSnapshot should probably honor the same type of flag.]

As for the XML changes, it makes sense to snapshot just a subset of disks when you only care about crash-consistent state or if you can rely on a guest agent to quiesce the subset of disk(s) you care about, so the existing <domainsnapshot> element needs a new optional subelement to control which disks are snapshotted; additionally, this subelement will be useful for disk image formats that require additional complexity (such as a secondary file name, rather than the inline snapshot feature of qcow2). I'm envisioning something like the following: <domainsnapshot> <name>whatever</name> <disk name='/path/to/image1' snapshot='no'/> <disk name='/path/to/image2'> <volsnapshot>...</volsnapshot> </disk> </domainsnapshot> where there can be up to as many <disk> elements as there are disk <devices> in the domain xml; any domain disk not listed is given default treatment. The name attribute of <disk> is mandatory, in order to match this disk element to one of the domain disks. The snapshot='yes|no' attribute is optional, defaulting to yes, in order to skip a particular disk. The <volsnapshot> subelement is optional, but if present, it would be the same XML as is provided to the virStorageVolSnapshotCreateXML. [And since my first phase of implementation will be focused on inline qcow2 snapshots, I don't yet know what that XML will need to contain for any other type of snapshots, such as mapping out how the snapshot backing file will be named in relation to the possibly new live file.]

Any feedback on this approach? Any other APIs that would be useful to add? I'd like to get all the new APIs in place for 0.9.3 with minimal qcow2 functionality, then use the time before 0.9.4 to further enhance the APIs to cover more snapshot cases but without having to add any new APIs.