[libvirt] RFC: API additions for enhanced snapshot support

[Eric Blake]

On 06/20/2011 04:22 PM, Motonobu Ichimura wrote:
>> /* 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?

I'm not yet convinced we need storage-type-specific functionality; the
XML elements can be optional, and if a particular element is not needed
by a particular storage driver, then that driver can ignore the element
(that is, the point of the snapshot XML on the create API is to provide
details like name or description where the default is not good enough,
and on dumpxml it will be the minimum xml for what was actually used in
creating the snapshot).

I believe that libvirt already has code for distinguishing between
different storage types (directory vs. block device), and can therefore
already tell whether a block device is an LVM partition.  It also
shouldn't be too hard to tell whether a disk image belongs to a btrfs
mount point, for using btrfs copy-on-write cloning (if nothing else,
coreutils' cp has already done this, so I have examples to copy from).
But I'll probably have to get more familiar with that code as I expand
this API beyond qcow2, and it certainly makes sense to consider whether
'virsh vol-info' should be expanded to display information already known
by libvirt (whether the volume is file- or block-based; if block-based
whether the partition is LVM, and if file-based what file system the
containing mount point appears to be).  That may indeed involve adding
more APIs beyond this proposal, but I think that this proposal will work
for 0.9.3 even if such new APIs are delayed until after the release.

>> /* 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.

Yes, we can add new virError values as we come across situations where
such operations are unsupported, but which don't fit well into any
existing error values.

>> 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

Wouldn't the snapshot volume size always be equal to the volume size of
the original?  Or is there really value in allowing the snapshot size to
be configured to something different (and if different, must it always
be <= original, or does a larger snapshot than the original make sense)?

>> 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.

I'm not quite sure I follow the scenario you are envisioning here.
Would you mind stepping through an example (mapping [proposed] libvirt
API calls to lvm commands would be helpful), on how an original lvm
partition is created, then a snapshot partition, then how you run out of
volume size in that snapshot?  It sounds like you are saying that there
is a way to create an lvm snapshot that is valid at the time that is
created, but later on, subsequent actions cause the snapshot to run out
of space and no longer be valid.  But my understanding is that a
snapshot is a constant size (it represents a known state of the disk at
a fixed point in time), only the deltas to that snapshot (aka the live
disk) ever have the potential to grow beyond the amount of storage used
by the snapshot.  Or are you worried about creating an lvm snapshot by
libvirt, but then a third party program changes the property of the lvm
snapshot volume to change its size?

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110620/4d733a7e/attachment-0001.sig>