Hi Dan, On Mon, 28 Apr 2008, Daniel P. Berrange wrote: > > I wonder if people are already working on the libvirt storage side to > > support 'remote' highlevel filesystems. For example ZFS or NetApp storage > > machines could benefit from an easy interface. > > In the 0.4.0 release we added storage management APIs. There is a concept > of a storage pool, containing storage volumes. There are various impls of > storage pools, one of which is iSCSI. This lets you login to iSCSI servers, > enumerate LUNs, determine the persistent stable path for a LUN and then > assign it to a guest. Similarly given a guest disk, you can query the > storage volume associated wih the path, and then query the storage pool > associated with the volume. Letting you map in both directions between > guests and iSCSI servers/volumes. This is basically missing the point :) Create, Delete, Snapshots, clones, etc. are basically the things ones would like to do using a standard interface. Even the creation and deletion maybe 'delegated quota management' could be things to go into the storage API. As you have mentioned before on IRC, the iSCSI part is not finished, especially the auto discovery. The NetApp iSCSI (imho) is not the most smart implementation one could use it requires quering the storage backend for lun allocation and thus rescanning. Personally I think the stable paths are overrated. The only thing that anyone should specify is the identifier! Then the backend figures out where and if this can be accomplished. Since LUNs (as in propriatry extensions/mappings) require rescanning plus quering anyway it is solving the wrong problem. (at least on a service provider level, where things tend to change often, more than a 'stable' setup) Stefan -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list