[libvirt] RFC: API additions for enhanced snapshot support

[Motonobu Ichimura]

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>