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@xxxxxxxxxx> 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 )
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list