HP 9000 rp4440 Servers - HP-UX
11.11: All EMC LUNs Are Not Visible After Replacing the SAN Switch
Issue
Description :
•
Server Model: RP7400
•
SAN Switch: DS5100
•
Storage Vendor: EMC
•
Operating System: HP UX 11.11
RP 4440 Server - All the EMC LUNs
are not visible after replacing the SAN switch.
•
End-user was migrated the SAN switch to the new SAN switch. After SAN switch
replacements the Port configurations / Mappings are done properly.
•
After presenting the LUNs to the server, It was not visible to the server.
•
It starts giving the following error in Syslog and dmesg.
fcpdev_init unsuccessful. Bus
Instance number 268 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x5240f400 name=fcpdev
fcparray_init unsuccessful. Bus
Instance number 256 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x5240e400 name=fcparray
fcparray_init unsuccessful. Bus
Instance number 257 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x52626c00 name=fcparray
fcpdev_init unsuccessful. Bus
Instance number 258 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x52626c00 name=fcpdev
fcparray_init unsuccessful. Bus
Instance number 259 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x52626c00 name=fcparray
fcpdev_init unsuccessful. Bus
Instance number 260 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x52626c00 name=fcpdev
fcparray_init unsuccessful. Bus
Instance number 261 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x52626c00 name=fcparray
ioscan Output :
fcp
0 0/6/1/0.1
fcp
NO_HW INTERFACE FCP
Domain
ext_bus 257
0/6/1/0.1.204.0.0
NO_HW UNKNOWN
FCP Array Interface
ext_bus 258
0/6/1/0.1.204.255.0
NO_HW UNKNOWN
FCP Device Interface
ext_bus 259
0/6/1/0.1.207.0.0
NO_HW UNKNOWN
FCP Array Interface
ext_bus 260
0/6/1/0.1.207.255.0
NO_HW UNKNOWN
FCP Device Interface
ext_bus 261
0/6/1/0.1.208.0.0
NO_HW UNKNOWN
FCP Array Interface
ext_bus 262
0/6/1/0.1.208.255.0
NO_HW UNKNOWN
FCP Device Interface
ext_bus 263
0/6/1/0.1.209.0.0
NO_HW UNKNOWN
FCP Array Interface
ext_bus 264
0/6/1/0.1.209.255.0
NO_HW UNKNOWN
FCP Device Interface
ext_bus 265
0/6/1/0.1.210.0.0
NO_HW UNKNOWN
FCP Array Interface
ext_bus 266
0/6/1/0.1.210.255.0
NO_HW UNKNOWN
FCP Device Interface
ext_bus 267
0/6/1/0.1.213.0.0
NO_HW UNKNOWN
FCP Array Interface
ext_bus 268
0/6/1/0.1.213.255.0
NO_HW UNKNOWN
FCP Device Interface
•
End-user tried to reboot the server and the result was the same.
•
Tried insf -e , no output.
•
Roll back to the old SAN switch, but the server still reported the devices
NO_HW and the syslog/dmesg error.
•
Even the Maximum instance did not exceeded 255 instance, error was reported
while booting also.
"fcparray_init unsuccessful.
Bus Instance number 261 exceeded the maximum allowed (255).
wsio_claim init failed
isc=0x52626c00 name=fcparray"
•
Finally, found that on HP-UX 11.11 and 11.23 does not use persistent devices
(DSF) and it's well known that changes on the SAN can change h/w paths and
therefore device files on HP-UX.
•
It's quite unusual to see the instance numbers to go > 256 though, but user
cannot control this from HP-UX, as user boots HP-UX it scans the SAN and get
H/w paths from there and builds an I/O tree with instance numbers.
Solution
Finally the issue was resolved by
recreating the ioconfig file and server reboot.
Steps followed to resolve the
issue:
•
Checked the ioscan and found the LUNs are in the Unclaimed state with below
errors in the boot up and syslog.
The UNCLAIMED devices has ext_bus
instance exceeded the limit (255) which caused the boot up error fcparray_init
unsuccessful.
•
With the help of back-line, Found Recreation of the ioconfig file will fix the
issue.
•
Moved the old ioconfig file from /etc and /stand to some other location like
/tmp. Boot up to single user mode.
•
Executed the ioinit -c command to recreate a new ioconfig file then reboot.
# /sbin/ioinit -c (or) Use
ioconfig_dump utility downloaded from Ktools:
Recommendation:
Need to look for possibility to release unsed extn_bus and reconfigure the ioconfig tree.
Need to look for possibility to release unsed extn_bus and reconfigure the ioconfig tree.
#Run the ioconfig_dump
utility
/var/adm/crash/ioconfig/ioconfig_dump.exe
/var/adm/crash/ioconfig/ioconfig_dump.exe
Create a new
ioconfig file called ioconfig.new.
## ioconfig_dump -w -o /tmp/ioconfig.new
## ioconfig_dump -w -o /tmp/ioconfig.new
Verify the instance
mappings of the newly created ioconfig file
# ioconfig_dump -r -o /tmp/io.ascii.old
# ioconfig_dump -r -o /tmp/io.ascii.old
Total number of
instances currently used:
# grep ext_bus /tmp/io.ascii.old|wc -l
# grep ext_bus /tmp/io.ascii.old|wc -l
#Backup /stand/ioconfig and /etc/ioconfig and copy ioconfig.new into both locations.
# cp /stand/ioconfig /stand/ioconfig.orig
# cp /etc/ioconfig /etc/ioconfig.orig
# cp /tmp/ioconfig.new /stand/ioconfig
# cp /tmp/ioconfig.new /etc/ioconfig
NOTE: Can be created from normal
mode also, but ensure that the /etc/ioconfig and /stand/ioconfig are same file
and size.
•
After reboot, The ext_bus instance exceeded the limit (255) error got fixed and
the server able to see all the LUNs.
•
Now the ioscan detected all the presented LUNs and the errors are stopped in
syslog/dmesg/boot log.
Latest ioscan output - After
ioconfig file recreation :
ext_bus
7 0/5/2/0.1.208.0.0
fcparray CLAIMED INTERFACE FCP
Array Interface
target
12 0/5/2/0.1.208.0.0.0
tgt CLAIMED
DEVICE
disk
7 0/5/2/0.1.208.0.0.0.0 sdisk
CLAIMED DEVICE
DGC CX4-480WDUNB
/dev/dsk/c7t0d0
/dev/rdsk/c7t0d0
disk
8 0/5/2/0.1.208.0.0.0.2 sdisk
CLAIMED DEVICE
DGC CX4-480WDR5
/dev/dsk/c7t0d2
/dev/rdsk/c7t0d2
disk
9 0/5/2/0.1.208.0.0.0.3 sdisk
CLAIMED DEVICE
DGC CX4-480WDR5
/dev/dsk/c7t0d3
/dev/rdsk/c7t0d3
disk
10 0/5/2/0.1.208.0.0.0.4 sdisk
CLAIMED DEVICE
DGC CX4-480WDR5
/dev/dsk/c7t0d4
/dev/rdsk/c7t0d4
ext_bus
8 0/5/2/0.1.208.255.0
fcpdev CLAIMED
INTERFACE FCP Device Interface
target
13 0/5/2/0.1.208.255.0.0
tgt CLAIMED
DEVICE
ctl
7 0/5/2/0.1.208.255.0.0.0 sctl
CLAIMED DEVICE
DGC CX4-480
/dev/rscsi/c8t0d0
ext_bus
9 0/5/2/0.1.210.0.0
fcparray CLAIMED INTERFACE FCP
Array Interface
target
14 0/5/2/0.1.210.0.0.0
tgt CLAIMED
DEVICE
disk
11 0/5/2/0.1.210.0.0.0.0 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d0
/dev/rdsk/c9t0d0
disk
27 0/5/2/0.1.210.0.0.0.1 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d1
/dev/rdsk/c9t0d1
disk
29 0/5/2/0.1.210.0.0.0.2 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d2
/dev/rdsk/c9t0d2
disk
31 0/5/2/0.1.210.0.0.0.3 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d3
/dev/rdsk/c9t0d3
disk
33 0/5/2/0.1.210.0.0.0.4 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d4
/dev/rdsk/c9t0d4
disk
35 0/5/2/0.1.210.0.0.0.5 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d5
/dev/rdsk/c9t0d5
disk
36 0/5/2/0.1.210.0.0.0.6 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d6
/dev/rdsk/c9t0d6
disk
38 0/5/2/0.1.210.0.0.0.7 sdisk
CLAIMED DEVICE
DGC CX4-480WDR3
/dev/dsk/c9t0d7
/dev/rdsk/c9t0d7
After recreating the ioconfig file under /etc and /stand the issue
got resolved
No comments:
Post a Comment