Re: [libvirt] RFC? finding potential storage pool resources
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