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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list