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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list