Operating System - HP-UX
1748019 Members
4450 Online
108757 Solutions
New Discussion юеВ

Re: HP-UX 11.31: how to rescan the new LUNs?

 
Tuan Nguyen_2
Frequent Advisor

Re: HP-UX 11.31: how to rescan the new LUNs?

Same problem with my rx6600 (or bl860C etc), 11.31 on EMC clariion. Reboot needed first time the array assign the LUNs to the server. (only first time).
Is there a way (please don't mention ioscan, insf) I can see the new luns (on a new Clariion array) without reboot the server?

We don't use powerpath but the Naviagent 6.29.0.6.1 is install on the server .

Thanks
Tuan
Turgay Cavdar
Honored Contributor

Re: HP-UX 11.31: how to rescan the new LUNs?

Hi Tuan,
I remembered i faced with the same problem. (Hp-ux 11.31 and vlarion array. When the storage guy first assign the disk, i couldn't see the disks, but see 4 devices(which are not the disks i think they are the controller(CX4-960WDUNB):
#ioscan -funC disk
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
disk 18 8/0/5/1/0.53.0.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDUNB
/dev/dsk/c15t0d0 /dev/rdsk/c15t0d0
disk 19 8/0/5/1/0.53.1.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDUNB
/dev/dsk/c16t0d0 /dev/rdsk/c16t0d0
disk 21 8/0/6/1/0.63.0.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDUNB
/dev/dsk/c13t0d0 /dev/rdsk/c13t0d0
disk 22 8/0/6/1/0.63.1.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDUNB
/dev/dsk/c14t0d0 /dev/rdsk/c14t0d0

After removing the device files attached to the card:
# rmsf -H 8/0/5/1/0
# rmsf -H 8/0/6/1/0
# ioscan -fnC disk

Then i could see the disks(CX4-960WDR5) without reboot.

#ioscan -funC disk
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
disk 18 8/0/5/1/0.53.0.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDR5
/dev/dsk/c15t0d0 /dev/rdsk/c15t0d0
disk 19 8/0/5/1/0.53.1.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDR5
/dev/dsk/c16t0d0 /dev/rdsk/c16t0d0
disk 21 8/0/6/1/0.63.0.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDR5
/dev/dsk/c13t0d0 /dev/rdsk/c13t0d0
disk 22 8/0/6/1/0.63.1.239.0.0.0 sdisk CLAIMED DEVICE DGC CX4-960WDR5
/dev/dsk/c14t0d0 /dev/rdsk/c14t0d0


Rita C Workman
Honored Contributor

Re: HP-UX 11.31: how to rescan the new LUNs?

When luns are presented and you can't 'see' them at all - sometimes you need to stop thinking like a UNIX Admin only.

There can be alot of reasons, and at that point if I knew I did what I should on the HPUX side, I'd be looking at the SAN side. I'd check that the right luns were properly mapped and masked to the right host!!!

If your disks are not present correctly, then all the ioscan and insf and reboots are not going to change a thing.

I can see the point about clearing out old paths, but even that shouldn't be necessary.

My guess is there was or is something else going on. I wonder how many UNIX folks above, raised a flag about not seeing disks, went about wasting time rebooting....when the SAN person went back and had a "Aha...oops....fix the problem and keep my mouth shut moment" Think back...did you go talk to the SAN person?

There is no need to reboot to see new disk and those folks that said you should at HP Support should be fired!! Plan and simple - they are idiots and a disgrace to HP.

Kindest regards,
Rita
dev44
Regular Advisor

Re: HP-UX 11.31: how to rescan the new LUNs?

Hi Rita,

The thing is that the reboot did solve my problem. I agree, that should NOT have been the solution but it was. Therefore no issue on the SAN end, only the HP-UX end.
whatever
Rita C Workman
Honored Contributor

Re: HP-UX 11.31: how to rescan the new LUNs?

Oscar,

I am still with Duncan on this. I work on all kinds of flavors of HPUX and the only time I reboot on new disk setups, is because I'm migrating from old arrays to new arrays. Not because of the box not seeing the new disk - but because after major operations you should always reboot to confirm/test server integrity.

Glad your working!
Rgrds,
Rita

chris huys_4
Honored Contributor

Re: HP-UX 11.31: how to rescan the new LUNs?

> The thing is that the reboot did solve my
> problem. I agree, that should NOT have been
> the solution but it was. Therefore no issue
> on the SAN end, only the HP-UX end.

No way.

Was/is the emc support matrix/hp spock checked/allready checked, if all necessary prerequisites were installed on the hp-ux hosts/necessary flags set on the emc clariion array "corresponding with the hp-ux host version), before presenting the emc clariion array to the hp-ux host(s) ?

If that was done and still the luns would not be "discovered" on the hp-ux host, then the call to hp support should have been escalated to at least lvl2 to check what is going on.

I never/ever on any hp-ux version, needed to get a system booted to have hp-ux see some luns. (its almost always a problem with the diskarray/san//emc multipathing software problem )

And the advise from probably l1 was "half true".. in some very rare cases, especially with the more "exotic", i.e. rubbish ;), diskarrays (so not emc/hp diskarrays), the diskarrays need a reboot to get everything presented correctly.. and if the diskarray needs a reboot probably the hp-ux system also.. )

Greetz,
Chris
Tuan Nguyen_2
Frequent Advisor

Re: HP-UX 11.31: how to rescan the new LUNs?

Hi Turgay, Rita, dev44 and all

Please see my test at the attachment, many details.

Turgay, thanks for the hint, yes I see "some" of the new luns in "ioscan -fnN" and "ioscan -fnCdisk". They all are "NO_HW". I rmsf the HW path for "LUN disk109" (see attachment; not disk111, because some errors, see below), after a "ioscan/insf" nothing happens (and that lun remain lost from "ioscan -fnN"). Interesting I can see the device as "lunpath" (the driver eslpt).

Rita: hahah, I wish you were here. It is a lady name I think the Storage team will listen to you :-). And I wish you were here so you can also see the problem as I and dev44 and other had seen.

We have seen the problem "everytime we get a new 11.31 server" (on different model at different location. Each location (4) has their own array HP/EMC). Just to mention you it is EMC Clariion, which we had trouble with (never with HP XP24000). And the reboot is only necessary at the first time the server get EMC disks, after this no more complain.

When digging into the problem I see some other problems (only show 7 luns (eslpt) and the number of HW path are not equal (4 & 8); see attachment). I will have a talk with the Storage team about this issue and let hope they can "find" the issue in the setup.

dev44, great you are still active :-)

I will get back with more news, in the mean time all new hints are welcomed.

Notice, the attachment shows one good lun (disk204) from an existence array and a new one from a new EMC array (disk111)
What are we doing: we want to pvmove LUNs from one array to another EMC array. All the new 24 LUNs are zoning by the Storage Team with failover mode 4 (ALUA).

Thanks.
Tuan

PS: sorry I can't give point since it is a following up. I use this thread because I think it is useful if another get the same problem. Maybe Oscar the thread owner will help, you decide the points.

Turgay Cavdar
Honored Contributor

Re: HP-UX 11.31: how to rescan the new LUNs?

Hi Tuan,

[nubia:root]/nnit/data/sys/doc/nubia/current # scsimgr lun_map -C disk -I 111

LUN PATH INFORMATION FOR LUN : disk111

Total number of LUN paths = 8
World Wide Identifier(WWID) = 0x50060160bb20445750060160bb204457

LUN path : lunpath168
Class = lunpath
Instance = 168
Hardware path = 0/7/1/1.0x500601683b204457.0x0
SCSI transport protocol = fibre_channel
State = UNOPEN
Last Open or Close state = AUTH_FAILED


As your Lunpaths are seen as "AUTH_FAILED" you should see some errors in /var/adm/syslog/syslog.log about LUN id mismatch. You can correct this errors by using:

# scsimgr -f replace_wwid -C lunpath -I

Or just remove all device files by using:
# rmsf -H 0/7/1/1
# rmsf -H 0/3/1/0
Tuan Nguyen_2
Frequent Advisor

Re: HP-UX 11.31: how to rescan the new LUNs?

Hi Turgay, and all

I had found the solution, thanks to the hint from you, HP Support and our Storage Team. It took a little time to find the trick, but all your efforts/suggestions (incl Rita) had pushed me further. Thanks.

nb: by the way, I don't think the Stoarge Team had changed anything on the array setup.

Please see the attachment for the whole solution. Now all the 24 LUNs we ordered on the new array are become visible and usable :-). Take also a look at the attachment on the previous post to get the whole picture.

Yes the "scmgr replace_wwid -D ..." does the trick, but you need to find the correct "special one LUN" (see the attachment) to solve the problem. If doing on a "wrong" LUN you get nothing.

NB: I had check the other 11.31 servers syslog, they got the "scsimgr replace_wwid" too after a new lun assign, and after the reboot the warning was gone (and then all disks become visible).

Answer from HP Support: I have checked our knowledge base this is a known issue, what happens is that if zoning changes "softchange" HP-UX reuses the path id and until scsimgr replace_wwid is run on the lunpath(you can specify individual lunpaths or disks see the previus attached pdf) that path will remain unactive. It somehow seams to affect EMC storage a lot more often then other vendors.
--finish--

The Note from EMC, it is on the right track, but it didn't give you the solution. If you are looking for the "sdisk", you will get nowhere (see my attachment on the previous post)

The following is a Primus(R) eServer solution:
ID: emc187655
Domain: EMC1
Solution Class: 3.X Compatibility

Fact OS: HP-UX 11i v3

Fact Product: CLARiiON CX Series

Fact EMC Firmware: FLARE Release 26

Symptom HP-UX 11iv3 host cannot see a LUN presented to the host.

Symptom Cannot see any of the LUNs presented to an HP-UX 11iv3 host that were visible.

Symptom vmunix: An attempt to probe existing LUN id 0x0 failed with errno of 14.

Symptom vmunix: Evpd inquiry page 83h/80h failed or the current page 83h/80h data do not match the previous known page 83h/80h data on LUN id 0x0 probed beneath the target path (class = tgtpath, instance = 1) The lun path is (class = lunpath, instance 1). Run 'scsimgr replace_wwid' command to validate the change.

Change Removed a LUN from the Storage Group, and presented a new LUN with the same HLU as a previous LUN assigned to Storage Group.

Change Removed LUN 0 (HLU 0) from the Storage Group.

Cause To prevent accidental data corruption, the SCSI stack implements an authentication mechanism based on the LUN WorldWide Identifier (WWID). When a LUN with a different WWID is discovered through a previously discovered LUN path, further access to the device through that LUN path is prevented. The LUN path is put in an "Authentication Failure" state.

Fix Run scsimgr replace_wwid to correct the problem:

scsimgr [-f] replace_wwid identifier [dsf]

Where the identifier identifies a LUN, LUN path, or a target path. In case of a LUN replacement (that is, the identifier is a LUN), the keyword dsf directs replace_wwid to also assign the device file name of the replaced LUN to the new LUN. If the identifier is a LUN path, or target path, dsf is just ignored.

Note HP-UX logs a message in syslog that informs the user that the replace_wwid operation must be performed when this problem occurs.

Thanks and Best regards,
Tuan

ps: by the way it is not a question about patches, even with the lastest bundle B11.31 Sept 2010 (3 months ago) there are problem to see the new luns on a new array. If anyone told you "patch!", please send him this thread :-)

Tuan Nguyen_2
Frequent Advisor

Re: HP-UX 11.31: how to rescan the new LUNs?

Hi all

it seems my solution was not 100% good...just after removing the old array, all the sdisk on the NEW array (ioscan -fCdisk) got "NO_HW", even the bdf, oracle, apps are OK.

A lot of 'scsimgr replace_wwid' were in syslog, I tried ioscan, replace_wwid.. stills "NO_HW" and the "fcmsutil /dev/fcd0 get remote all" shows invalid/Delay. The output must show "DSM_READY"

To avoid more hidden problem (more suprises) on the running kernel, I rebooted the server. After the reboot all sdisk becomes claimed and all apps run again without any involve from me or the SToraige folks.

NB: today I try to use my procedure on a brand new 11.31. The trick works (the last command was: scsimgr lun_map -C disk -I 13) , all SAN disks become visible and claimed, but I didn't glad for the NO_HW (see below; notice disk13) and the attachment from "smh" with the 0MB disk ...and maybe there are other hidden "problems" I didn't see. I try to reboot the server to see if there are any changes. After the reboot, no more NO_HW and no more 0MB disk on smh.

[merapi:root]/var/adm/syslog # ioscan -fuNCdisk|more
Class I H/W Path Driver S/W State H/W Type Description
===================================================================
disk 7 64000/0xfa00/0x3 esdisk CLAIMED DEVICE HP DG0300FAMWN
disk 10 64000/0xfa00/0xe esdisk CLAIMED DEVICE HP EG0300FAWHV
disk 13 64000/0xfa00/0xf esdisk NO_HW DEVICE DGC LUNZ
...and more disks

My conclusion is: From now on I will always reboot a 11.31 server for getting a new SAN LUN for the first time, by doing this I will avoid all the hidden problems, which can arise (by some combinations) late on...

BR Tuan