[libvirt] RFC: API additions for enhanced snapshot support
Motonobu Ichimura
motonobu at gmail.com
Mon Jun 20 22:22:53 UTC 2011
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 at 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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110621/4468d4a8/attachment-0001.htm>
More information about the libvir-list
mailing list