Hi, I'm new to this ML, and very interested in this topic. I'm going to try to implement LVM snapshot feature using this framework. 2011/6/16 Eric Blake <eblake@redhat.com>
/* Opaque type to manage a snapshot of a single storage volume. */ typedef virStorageVolSnapshotPtr;
I'm just wondering how to detect storage type and to choose assosiate shapshot functionality. Is there any idea about it?
/* 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.]
For LVM, it may be lvconvert --merge , but requires recent version of lvm and linux kernel, So, there are some failure reason (toolchain doesn't support it or toolchain supports, but failed) I don't know how to handle these case for now, but we may need to add some virErrorNumber to indicate snapshot-related error. - 元のメッセージを表示 -
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.]
In LVM case, taking snapshot(lvcreate) needs at least snapshot volume size as an argument, So, I think storage-specific element can be inserted in this XML format
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.
LVM snapshot may become invalid in the case of running out the volume size, So, adding an API for checking whether snapshot is valid will be needed. Regards,