[Libvir] RFC 'xen like scripts'

[Stefan de Konink]

On Mon, 5 May 2008, Daniel P. Berrange wrote:

> > netapp://username/partition
> >
> > I would prefer to let libvirt figure out where the lun can be found on the
> > system. (This involves connecting to the fileserver, fetching the LUN,
> > looking up the connection on the Linux side, reading the symlink).
>
> So you're wanting to pass this URL directly to the domain config, rather
> than the storage pool ?  If so, then I'd suggest a different approach
> which is to extend the domain XML so it can refer to a libvirt managed
> storage volume explicitly
>
> Instead of doing
>
>     <disk type="block">
>        <source dev="/dev/sdf"/>
>     </disk>
>
> Refering to the storage pool and volume name (which are independant of
> the disk path)
>
>     <disk type="vol">
>        <source pool="somepool" vol="somelun"/>
>     </disk>
>
> When starting the VM, libvirt can turn the pool + volume name into a
> path.

This would work indeed for NetApp. Where somelun would be the 'path' on
the server, that should be resolved to a lun.

> > For the iscsi backend, like we have discussed before, just discovery needs
> > to be implemented. The problem with the NetApp implementation is that it
> > exports all 'luns' at the same time. Technically this can be done 'host
> > based', but still *far* from implementable in libvirt using the current
> > configuration.
>
> I'm struggling to understand where there's needs to be a netapp specific
> impl of the iSCSI backend. Either netapp complies with iSCSI spec or it
> doesn't. The iSCSI backend is inteded to work with any compliant server.
> Or are you trying to use to netapp specific functionality that isn't
> actually part of its iSCSI support ?

Short answer:

NetApp puts *all* iSCSI luns on one connection.

Add 'automatic' lunnumbering and no explicit exported comments
in Vendor names etc. to the scenario and you see my ballpark.


So to make it more simple:

OpenSolaris		NetApp
All Luns exported	Per hostgroup export of all assigned luns
Maintains 'use'		Doesn't know if a specifc lun is used
Uses an identifier	Uses one iSCSI identifier, needs rescanning
			lun can be fetched from 'configuration interface'


Due to the reason all LUNs are exported over one connection, a
rescan before usage a rescan is always required. LUN numbering is not
stable, nor they can be found at the client side.


So I guess the best way to see this device is as a 'already connected'
scsi device, that has many disks that can be swapped around. And that it
is connected to the network with an information service. For some obscure
reason the 'information' service doesn't use the same IP address as the
iSCSI connection.



...a lot of fun to put it all in C.


Stefan