On Tue, Jul 27, 2010 at 06:28:01PM -0500, Patrick Dignan wrote: > Hi Everyone, > > I'm looking at implementing some functionality in libvirt that would > allow it to call functions in an unpublished iSCSI library. Some of the > functionality I wish to implement is not currently part of the libvirt > storage API. I wanted to suggest the following additions to the storage > API: grow volumes, show whether thin provisioning is enabled, enable > thin provisioning, disable thin provisioning, create snapshots, and > delete snapshots. I've added a patch at the end of the mail showing how > I think these functions should be implemented. Note that I have not > included details about the virStorageSnapshotDefPtr yet, that's the next > step. > > Perhaps this should be in a separate mail for better threading, but it > seems a bit strange to me that the storage interface isn't pluggable in > the traditional sense. In order to add a backend to libvirt, one has to > make modifications all over the place, for example: virt-inst, the > Makefile.am, the configure.ac, storage_backend.h, and several other > places. It would make sense to me to make this pluggable such that > someone could just load in a library that implements the required > functions and some identifying information (eg type of storage, > description, etc). A list of supported backends could be stored in > empty files in a directory somewhere, or some similar hack. This way > someone could write a plugin for tgtd for example, or in my case the > library I'm working with. I think this would also help others with > writing plugins for more storage backends. How difficult do you think > this would be? I'm willing to do a reasonable amount of work to get > this implemented, but I want to know what the experts think! We explicitly don't support external driver plugins in libvirt for a couple of reasons - We don't want to support use of closed source plugins - We don't want to guarentee stability of any aspect of libvirt's internal API We would like to see support for the various vendor specific iSCSI extensions to allow volume creation/deletion, but want that code to be part of the libvirt codebase. > /* File creation/cloning functions used for cloning between backends */ > int virStorageBackendCreateRaw(virConnectPtr conn, > @@ -76,6 +83,12 @@ > virStorageBackendCreateVol createVol; > virStorageBackendRefreshVol refreshVol; > virStorageBackendDeleteVol deleteVol; > + virStorageBackendGrowVol growVol; I'd call this 'resizeVol' since there's no reason we can't also support shrinking. > + virStorageBackendThinProvisionShow thinProvisionShow; > + virStorageBackendThinProvisionEnable thinProvisionEnable; > + virStorageBackendThinProvisionDisable thinProvisionDisable; I'm not really liking this as a concept. The other storage drivers, and indeed my iSCSI server, deal with thin provisioning on a per-volume basis when creating the volume. The libvirt model is that if in the XML, then <allocation> value is zero then the user is requesting thin provisioning of that volume. ie no storage allocated for it upfront. If <allocation> matches <capacity> then the volume should be fully allocated upfront. > + virStorageBackendCreateSnapshot createSnapshot; > + virStorageBackendDeleteSnapshot deleteSnapshot; There's no need for snapshot APIs. This functionality is already supported via the normal volume creation API, just specify the original volume to be snapshotted in the XML as the backing store. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list