[libvirt] RFC? finding potential storage pool resources

[Daniel P. Berrange]

On Thu, Jul 17, 2008 at 05:28:01PM -0400, David Lively wrote:
> Hi -
> 
>   I'm looking into using (which I think means extending) libvirt to
> enumerate "potential" storage pool resources, in particular:
>   * existing physical disk device names (for creating "disk" pools)
>   * existing logical volume group names (for creating "logical" pools)
> 
> Note that List{Defined,Active}StorageGroups don't do the trick.  Suppose
> this is a new host and I'm trying to start defining the storage pools
> (and I want to be able to use existing volume groups, for example).  I
> don't see how to do that within the current libvirt framework.  If I'm
> missing something, please let me know (and ignore the rest of this
> message ...).

You're not missing anything - this is a TODO item. When I wrote the
original storage APIs, I had a prototype

  http://www.redhat.com/archives/libvir-list/2008-February/msg00107.html
  http://www.redhat.com/archives/libvir-list/2008-February/msg00108.html

 int                     virConnectDiscoverStoragePools(virConnectPtr conn,
 						        const char *hostname,
 					 	        const char *type,
 						        unsigned int flags,
 						        char ***xmlDesc);

Which was intended to probe for available storage of the requested type
(eg, LVM, vs disks, vs iSCSI targets, etc, etc), and return a list of XML
documents describing each discovered object. This could be fed into the
API virStoragePoolDefineXML.

I didn't include this in the end, because I wasn't happy with the 
API contract. For example, it only allows a hostname to be specified
as metadata, but it may be desirable to include a port number as well
for network based storage.

> This could be done by adding some new calls like:
>    int virConnectListPhysDisks(virConnectPtr conn, char ** const name, int maxnames)
> ???   int virConnectListLogicalVolGroups(virConnectPtr conn, char ** const name, int maxnames)
>     ... plus a pair of NumOf functions ...
> 
> But these are each storage-driver specific.  For example, if I'm not
> using the "logical" storage driver, I have no need (or means) of listing
> volume groups.  So maybe it's cleaner to fold these two functions into
> one, now parameterized by storage driver type:
>   int virConnectListStorageSources(virConnectPtr conn, const char *type, char ** const name, int maxnames)
>    ... plus a NumOf function ...
> where <type> is one of the supported storage pool types.

Yes, I definitely want the discovery API to be able to handle disks,
LVM, iSCSI, FibreChanel, NFS - basically everything in one.

That said, in the case of physical disks, we may well end up with a
parallel way to discover disk device names, via generic hardware device
enumeration APIs

http://www.redhat.com/archives/libvir-list/2008-April/msg00005.html

> So, if <type> is "disk", ListStorageSources acts like ListPhysDisks,
> and if <type> is "logical", ListStorageSources acts like ListLogicalVolumeGroups,
> (and we return empty lists or some sort of "unsupported" error for any
> other types ... can't list all possible network servers, for instance).

For network sources I anticipated that you'd provide a hostname when
triggering discovery. For NFS, this is sufficient to let you query
all exported volumes. For iSCSI this lets you query available target
names.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|