3:51 p.m.
Hi All,
I have just finished some scripts that allows 'native Xen' to use some
facilities of NetApp. Basically using a vfiler, and a q-tree Xen can be
provisioned. Allowing: netapp://customer/disk
Some scripts can be found here:
http://kinkrsoftware.nl/contrib/xen/
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.
Currently I'm building these 'block' scripts because they give
straightforward facities to my setup. But if anyone wants to team up to
get this all inside some more abstract libvirt setup I would happy to
join.
Stefan
4:02 p.m.
On Mon, Apr 28, 2008 at 10:51:16PM +0200, Stefan de Konink wrote:
Hi All,
I have just finished some scripts that allows 'native Xen' to use some
facilities of NetApp. Basically using a vfiler, and a q-tree Xen can be
provisioned. Allowing: netapp://customer/disk
Some scripts can be found here:
http://kinkrsoftware.nl/contrib/xen/
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.
Dan.
--
|: Red Hat, Engineering, Boston -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 :|
4:41 p.m.
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
6052
days inactive
6052
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Stefan de Konink