On Wed, Jun 22, 2011 at 9:27 AM, Daniel Veillard <veillard@xxxxxxxxxx> 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@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 ) I agree. The main thing is getting the semantics and the model right so that it can represent the various storage types/APIs. Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list