[libvirt] RFC? finding potential storage pool resources

[David Lively]

On Thu, 2008-07-17 at 22:42 +0100, Daniel P. Berrange wrote:
> 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.

Thanks for the pointers.  I like your proposal, but I agree the API
contract isn't general enough (what about possible future driver
types??)  Perhaps your hostname parameter could be replaced with a
source_spec parameter which is an XML document consisting of a storage
pool <source> element (with entries appropriate to the given storage
pool type)?

So for network storage, you'd pass a source_spec (a string) like:
   <source>
     <host name="foo.bar.com" port=123 />
   </source>

source_spec would be optional for some storage pool types, like "disk"
and "logical".  (And if specified, it could restrict the discovery to
those sources listed??  There are scalability issues as SANs
proliferate ... even on hosts with a single HBA ....)

Using the storage pool <source> element here should essentially
guarantee this is general enough to support all storage drivers.  (If a
future storage driver requires the <source> XML to be extended, the
discovery API is extended in the same way.)

(I like your later hardware device enumeration API proposal too.  I'm
ignoring it for now for the sake of simplicity ...)

Dave