Maximum LUNS on a single HBA.

[Paul Thomson_2]

Hi I am having issues with my rp3410 server not seeing more than 8 LUN's down either of its HBA's . It should see 11.
Example c5t0d0 --> c5t0d7 (3 are missing)

Originally I had d0 --> d2 but 8 more where added this week for extra storage.

The storage team advise that they are presented and OK, yet the HPUX server only sees 5 of the new LUNS.

I have checked the document
http://docs.hp.com/en/7154/Max_LUN_whitepaper_v11.23.pdf

This advises that 11i V1 before 2003 can see 512 LUNs/ HBA and after 2003 December, with the correct patch level (which this server has) can use 1536 LUN's / HBA.

The Fibrecard is a dual A6826A, before I perform an unrequired reboot, any thopughts as my storage team think this is a HBA issue ?

Thanks
Paul

[Wim Rombauts]

You should certainly see paths like c5t1d0 --> c5t1d7. Mu HP-UX 11iv1 systems have LUN's upt to t2d2 (so 18 of them).

You checked with ioscan -fnC disk ? (Just to make sure)

The only other option I can see is that the LUN's are not mapped to your system's HBA-WWN's correctly.

[Paul Thomson_2]

Hi Wim, yes, I saw the additional LUN's via ioscan -fnC disk. I also have systems which have been allocated LUN 20 something from a VA and show as c?t2d5 indicating the ability to have more. I just wondered as this storage array shows the LUNS as HITACHI DF600F. But then to HPUX its only a disk !

Thanks
Paul

[Tim Nelson]

keep in mind that the HW addresses show up in octal on hpux.

e.g.
0/10/0/0/0.20.8.0.0.0-7 ( luns 0-7 )
0/10/0/0/0.20.8.0.1.0-7 ( luns 8-15 )
and so on.

cxt0d0-7 then cxt1d0-7 ( this is lun 8-15 ), etc..

Unless some masking on the array is incorrect then there should be no issue.

[Paul Thomson_2]

Hi Tim

yes, that makes sense.
On this system the H/W address are going upto
0/3/1/1.1.0.255.0.0.7

But not to the next
0/3/1/1.1.0.255.1.1.0

Thanks
Paul

[Tim Nelson]

So the expectation is
0/3/1/1.1.0.255.0.0.0
0/3/1/1.1.0.255.0.0.1
0/3/1/1.1.0.255.0.0.2
...
0/3/1/1.1.0.255.0.0.7
This takes care of the first 8 luns and as you stated you can see these from the server.

Then we should see
0/3/1/1.1.0.255.0.1.0
0/3/1/1.1.0.255.0.1.1
0/3/1/1.1.0.255.0.1.2
but no luck.

The only thing I can think of is.
1) lun masking is incorrect
2) The presentation of the last three luns is down some different path that is not zoned for this server.
2) The HBA on the array is not set for HPUX ( not sure about this )

If other HPUX servers seem ok then use those configs to compare to this one.

Above are just troubleshooting ideas.

Any SecurePath products on this server ?

This just may be a weird FC thing and a reboot may just be your next best troubleshooting attempt.

If the reboot works it would be great to know why these next luns do not show on the fly.

[Steven E. Protter · Accepted solution]

Shalom,

I had this bug myself Paul.
For HB storage 512 LUNS.

For the non-HP storage maximum of 8 LUNS.

I was promised a bug fix, and waited three years and did not receive it.

SEP

[Torsten.]

I searched the web for

"HITACHI DF600F" select hp-ux platform


and found a manual that says you need to set the platform on the array to hp-ux.

This sounds reasonable.

Please check this - this may solve your problem.

[Paul Thomson_2]

Steven

Oops and I have just sent a email to my storage chaps to blaming them ! Thats very bad of HP to do that, or not do that as the case were.

I may open a case and see where I get !

Thanks

[Torsten.]

"For HB storage 512 LUNS.
For the non-HP storage maximum of 8 LUNS."

Whatever "HB" stands for, non-HP array products can present much more LUNs to HP-UX.


Ask all the netapp, EMC, hitachi ... whatever users!


The most important thing is to set set the right hostmode on the array (windows, hp-ux, vms, linux ... bla bla) due to different addressing modes.



A wrong mode can really limit the number of visible LUNs to 8 (0..7)!