"Kilgaard" <Kilgaard@hotmail.com> writes:

> "Ulrich Windl" <Ulrich.Windl@RZ.Uni-Regensburg.DE> wrote in message
> news:87r6mmfhci.fsf@pc9454.klinik.uni-regensburg.de...
> > "Kilgaard" <Kilgaard@hotmail.com> writes:
> >
> > [...]
> >> I have not (yet) tried this on an EVA, but HP-UX (11.00, 11.11 and 11.23)
> >> will work quite happily on non-contiguous LUNs off a VA array.
> >>
> >> Will test on an EVA6000 (with HPUX 11.23 IA) for you.
> >
> > Thanks. I only noticed that for HP-UX the LUNs are not presented as type
> > "disk", but as "RAID"; maybe that makes the difference? (Linux would
> > detect
> > the LUNs, but would not use those as disks (until the presentation OS was
> > set
> > to Linux...))
> >
>
> On my 11.23 IPF server I presented a new LUN6 to the server. This server
> currently has LUNs 1 and 3 presented, but it did have a LUN2 at some point
> in the past (and hence the gap in the numbering). Note the LUN6 is still on
> the same sctl as the existing LUNs. I did not want to polute the server with
> addition sctl's so kept the LUN as 7 or less. This may be the issue you are
> seeing in that LUN9 will be on a different sctl, but I have another server
> (11.00 attached to a VA array) that uses LUNs 100 thru 104.

[...]

Exactly that was the problem: I was looking for some hwpath like *.9 (which
does not exist, because SCSI LUNs are restricted to the range of 0-7). From
the docs I learned that a EVA LUN is presented in a fabric to something like
FC-Adapter, ..., Bus=(LUN / 128), Target=(LUN % 128) / 8, Lun=LUN % 8

Sorry, but the "Lun" was confusing me. Our older storage systems all had LUN
numbers < 7.

Regards,
Ulrich