On Mon, May 05, 2008 at 11:39:44PM +0200, Stefan de Konink wrote:
On Mon, 5 May 2008, Daniel P. Berrange wrote:
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 where does the information mapping netapp pathnames to the the LUNs come from ? If LUNs can change when re-scanning what happens to LUNs already in use for other guests ? It doesn't sound usable if LUNs that are in use get renumbered at rescan. AFAICT this is basically just suggesting an alternate naming scheme for storage volumes, instead of 'lun-XXX' where XXX is the number, you want a name that's independant of LUN numbering. So the key question is where does the information for the persistent names come from ? 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 :|