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