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