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