[libvirt] RFC: API additions for enhanced snapshot support

[Stefan Hajnoczi]

On Wed, Jun 22, 2011 at 9:27 AM, Daniel Veillard <veillard at redhat.com> wrote:
> On Tue, Jun 21, 2011 at 02:12:28PM +0100, Stefan Hajnoczi wrote:
>> On Tue, Jun 21, 2011 at 11:30 AM, Daniel P. Berrange
>> <berrange at redhat.com> wrote:
>> > For formats like LVM, brtfs, SCSI, etc,  libvirt will have todo all
>> > the work of creating the snapshot, possibly then telling QEMU to
>> > switch the backing file of a virtual disk to the new image (if the
>> > snapshot mechanism works that way).
>>
>> Putting non-virtualization storage management code into libvirt seems
>> suboptimal since other applications may also want to use these generic
>> features.  However, I'm not aware of a storage management API for
>> Linux that would support LVM and various SAN/NAS appliances.  Ideally
>> we would have something like that and libvirt can use the storage
>> management API without knowing all the different storage types.
>>
>> A service like udisks with plugins for SAN/NAS appliances could solve
>> the problem of where to put the storage management code.
>
>  Well there is multiple answers to this "sub-optimality"
>  1/ we can't really wait, there are some parallel developments I'm
>     following (from a distance) which may provide some of this
>     the key point is trying to keep some compatibility in the
>     objects and terms of the API to be able to reuse them
>  2/ if we develop some code in libvirt for this is could be separated
>     as a library once it's mature enough
>
> IMHO the point is making sure the way we represent things maps easilly
> with how other specs or library may do it, then we should be able to
> reuse them (e.g. CDMI snapshots
> http://cdmi.sniacloud.com/CDMI_Spec/14-Snapshots/14-Snapshots.htm )

I agree.  The main thing is getting the semantics and the model right
so that it can represent the various storage types/APIs.

Stefan