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

[Jdamian]

Hi

I had to reboot my rx6660 (HP-UX 11.31) to see 4 new SAN LUNs. The "ioscan -fnC disk" did not work.

I always told proudly that "HP-UX reboot is not required to configure new SAN LUNs" but it seems that has changed.

Is this true? Why?
Perhaps the "rescan" must be done by "scsimgr" command?

Thanx in advance

[Jozef_Novak]

ioscan should be sufficient. If your devices are not seen after a rescan followed by insf -e, the problem lies somewhere else, definitely not in a system-not-rebooted condition. Check LUN masking, driver availability, compatibility, etc ... standard things.

J.

[Steven E. Protter]

Shalom,

I would use insf -C disk

That will detect presented LUNS.

HP has a limited capacity to detect new LUNS without a reboot. It is very bad at detecting capacity increase. Better to present a new LUN and copy the data.

SEP

[Duncan Edmonstone]

SEP,

>> HP has a limited capacity to detect new LUNS without a reboot. It is very bad at detecting capacity increase. Better to present a new LUN and copy the data.

A pretty damning statement and I would have to disagree with you... in all my time working with HP-UX (10+ years) I can think of only one occasion when we needed to reboot to see new LUNs, and that eventually turned out to be down to the storage subsystem (EMC DMX) not being set with quite the correct parameters. As for not detecting capacity increases - well yes thats true on 11.11 and to some extent on 11.23, but as we are talking about 11.31 here, if the storage subsystem follows the correct behaviour described in the SCSI protocols about informing hosts when LUN sizes are changed, then HP-UX 11.31 will detect that change without a problem.

Oscar,

When I see these sorts of issues, my first consideration is doing a complete validation that I am on a fully supported storage stack - so check the FC HBA, the switch and the array controller, and look at the firmware and driver versions for all to confirm you are on a supported and tested configuration. If you are and you had to do a reboot, that's a bug and you should log a call with HP. There's no way you should be having to reboot to see new LUNs

Can you share some more of your environments configuration with us?

HTH

Duncan

[Torsten.]

Usually it is enough to do an ioscan to detect new devices. If this is not working, suspect configuration like presentation on the storage device or zoning on the switch.

You may get wrong results if you use other parameters with ioscan, e.g. -k or -H.

[James George_1]

Hi

The new LUNs should show up in the ioscan -fnC disk command and you don't need to reboot the server for this.

# insf -e

# ioscan -fnC disk

If you still don't see the disks, check your fibre cable connection to the server .


rgds/ James

[Torsten.]

With 11.31 you even don't need the insf command normally, ioscan should be enough.

[Michal Kapalka (mikap)]

Hi Jozef,

i don't see any reason to use insf -e.

With the -e option, insf reinstalls the special files for pseudo-drivers and existing devices. This is useful for restoring special
files when one or more have been removed.

( for example change the time stampe of all reinstalled devices )

mikap

[Sivakumar MJ._1]

Hi Oscar,

Mostly you will get with the following as suggested by others

1. insf -c
2. ioscan -fnC disk

If you still dont see the luns let me know which Storage Array you have, have u activated the config in switch, Did this server already had luns presented and the 4 luns are added newly.

what was your fcmsutil output before reboot..

[Shardha]

Dear

Run the command in following order

#ioscan
#insf -e
#ioscan -funC disk (to check the new devices)

[UVK]

insf -e and ioscan -fnc disk

commands should have done the job for you. If not there should be something wrong done from the storage side. At times we just get unlucky being one of such cases rare cases where we end up having to reboot the box.

[Jozef_Novak]

>> With the -e option, insf reinstalls the special files for pseudo-drivers and existing devices. This is useful for restoring special
files when one or more have been removed. <<

Thanks for pasting the manual excerpt here. If I needed it, I would have found it myself.

J.

[Michal Kapalka (mikap)]

Hi Jozef,

it was not personal.

Michal

[Steven E. Protter]

Shalom again,

In this context insf -e does nothing. Not a thing.

if insf -C disk or ioscan does not work then there is a configuration problem.

Also, LUN expansion might not be detected even with a reboot. Much better to present a new LUN and migrate the data.

SEP

[dev44]

Same happened here....rx6600 and 11.31 and had to reboot in order to see the disks. The ioscans would show NO_HW

ncrdb51c # ioscan -funH 0/7/1/1
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
fc 7 0/7/1/1 fcd CLAIMED INTERFACE HP AB379-60101 4Gb Dual Port PCI/PCI-X Fibre Channel Adapter (FC Port 2)

/dev/fcd7
fcp 1 0/7/1/1.11 fcd_fcp NO_HW INTERFACE FCP Domain
ext_bus 5 0/7/1/1.11.78.255.0 fcd_vbus NO_HW INTERFACE FCP Device Interface
ctl 3 0/7/1/1.11.78.255.0.0.0 sctl NO_HW DEVICE STK FLEXLINE 380
/dev/rscsi/c5t0d0
ext_bus 4 0/7/1/1.11.79.255.0 fcd_vbus NO_HW INTERFACE FCP Device Interface
ctl 2 0/7/1/1.11.79.255.0.0.0 sctl NO_HW DEVICE STK FLEXLINE 380
/dev/rscsi/c4t0d0
ncrdb51c # ioscan -funH 0/3/1/1
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
fc 3 0/3/1/1 fcd CLAIMED INTERFACE HP AB379-60101 4Gb Dual Port PCI/PCI-X Fibre Channel Adapter (FC Port 2)

/dev/fcd3
fcp 0 0/3/1/1.11 fcd_fcp NO_HW INTERFACE FCP Domain
ext_bus 3 0/3/1/1.11.78.255.0 fcd_vbus NO_HW INTERFACE FCP Device Interface
ctl 1 0/3/1/1.11.78.255.0.0.0 sctl NO_HW DEVICE STK FLEXLINE 380
/dev/rscsi/c3t0d0
ext_bus 2 0/3/1/1.11.79.255.0 fcd_vbus NO_HW INTERFACE FCP Device Interface
ctl 0 0/3/1/1.11.79.255.0.0.0 sctl NO_HW DEVICE STK FLEXLINE 380
/dev/rscsi/c2t0d0

[dev44]

I logged a call with HP and this was the response that I got, which I why I rarely call HP anymore.

"Most of the time, our customers are forced to even shutdown the array and the server and power them on again in order to help the OS to recognize the external devises."

[Johnson Punniyalingam]

Hi Devv,

<<
why are you posting , your problem in others man's thread, Doesn't it make you wired ????

if you have problem you should open new thread and post your problem,

Problems/issue may differ from person to person.

>>.had to reboot in order to see the disks<<

this absolutely wrong.

so far "As mentioned by <>
configuration problem. could make this happen,

ioscan -fnC disk -> you will be able to see "Newly assigned LUNS"

Regards,
Johnson

[dev44]

I posted here because I am having the EXACT SAME PROBLEM. So if that makes me "wired" then I'm ok with that.

[dev44]

I did an ioscan -fnC disk and we did not see the disks. This is what the problem is. We could not see the disks until after a reboot.

[Duncan Edmonstone]

>> "Most of the time, our customers are forced to even shutdown the array and the server and power them on again in order to help the OS to recognize the external devises."

I would take that statement and have the call escalated to L3 support - this is patently _not_ the case and if a L1/L2 support engineer has told you this, then he needs to be re-educated.

HTH

Duncan

[Tuan Nguyen_2]

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]

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]

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]

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.

[Rita C Workman]

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