On Tue, 6 May 2008, Daniel P. Berrange wrote:
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 ?
The information service, so in my case ssh script.
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.
Luns that don't change get not remapped. But if a user decides to destroy a disk, and have one with the same name again, it is most likely to get a other lun. But with the same name.
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 ?
Exactly this is what I want. If I have a iSCSI uri, I want to have it discovered, if I have a netapp uri I want to have it 'discovered' too, but in this case I provide the address of the administrative interface. And unlike you do for storage pools with iSCSI that the provided target name for volumes should 'match up' with the 'discovered name', I want this to be transparent to the user. *Because* Linux might have a target /dev/bla-by-path/X but who says *BSD, *Solaris has it? (Yes I know, there are other problems, but the base problem is that the target provided target device is pretty limited to one OS running udev.) Stefan