[Libvir] RFC 'xen like scripts'

[Stefan de Konink]

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