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