Re: [Libvir] RFC 'xen like scripts'
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