[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Extensions to the libvirt Storage API

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]