3 out of 8 lun paths are missing on HPUX 11.23 superdome server

[stonered]

OS: HP-UX 11.23

Issue:  luns missing paths.

(1) OS has 4 HBA connecting 4 Storage Ports  of XP Storage:

/dev/fclp1 (WWN: 500143801191224a)

/dev/fclp2 (WWN: 500143801191227c)

/dev/fclp6 (WWN: 5001438011912284)

/dev/fclp7 (WWN: 5001438011912254)

Storage Port: 5B

OS HBA:

/dev/fclp1 (WWN: 500143801191224a)       //this path is missing

/dev/fclp2 (WWN: 500143801191227c)      //this path is missing

Storage Port: 6B

OS HBA:

/dev/fclp6 (WWN: 5001438011912284)

/dev/fclp7 (WWN: 5001438011912254) )       //this path is missing

Storage Port: 7B

OS HBA:

/dev/fclp1 (WWN: 500143801191224a)

/dev/fclp2 (WWN: 500143801191227c)

Storage Port: 8B

OS HBA:

/dev/fclp6 (WWN: 5001438011912284)

/dev/fclp7 (WWN: 5001438011912254)

(2) Comparing the output of “xpinfo –i” of date 20121226 and date 20130125,  take “c28t0d1” (ldev 01:a5) for example, there are 8 physical paths in total, but we found that 3 paths are missing:

root# grep 01:a5 xpinfo-i.log.20121226

/dev/rdsk/c138t0d1           00  00  00  CL5B  01:a5  OPEN-V           00054112       //this path is missing

/dev/rdsk/c28t0d1            00  00  00  CL7B  01:a5  OPEN-V           00054112

/dev/rdsk/c200t0d1           00  00  00  CL5B  01:a5  OPEN-V           00054112       //this path is missing

/dev/rdsk/c54t0d1            00  00  00  CL7B  01:a5  OPEN-V           00054112

/dev/rdsk/c144t0d1           00  00  00  CL6B  01:a5  OPEN-V           00054112

/dev/rdsk/c110t0d1           00  00  00  CL8B  01:a5  OPEN-V           00054112

/dev/rdsk/c198t0d1           00  00  00  CL6B  01:a5  OPEN-V           00054112      //this path is missing

/dev/rdsk/c80t0d1            00  00  00  CL8B  01:a5  OPEN-V           00054112

root # grep 01:a5 xpinfo-i.log.20130125

/dev/rdsk/c28t0d1            00  00  00  CL7B  01:a5  OPEN-V           00054112

/dev/rdsk/c54t0d1            00  00  00  CL7B  01:a5  OPEN-V           00054112

/dev/rdsk/c144t0d1           00  00  00  CL6B  01:a5  OPEN-V           00054112

/dev/rdsk/c110t0d1           00  00  00  CL8B  01:a5  OPEN-V           00054112

/dev/rdsk/c80t0d1            00  00  00  CL8B  01:a5  OPEN-V           00054112

This OS is using VxVM, so we can verify that there are only 5 paths available for “c28t0d1”:

#vxdisk list c28t0d1

Device:    c28t0d1

devicetag: c28t0d1

type:      auto

hostid:    g4ah1050

disk:      name= id=1325085633.43.g4ah1050

group:     name=dg_oidmaster_data id=1325085633.45.g4ah1050

info:      format=cdsdisk,privoffset=128

flags:     online ready private autoconfig noautoimport

pubpaths:  block=/dev/vx/dmp/c28t0d1 char=/dev/vx/rdmp/c28t0d1

guid:      {7c40c368-1dd2-11b2-9ab9-00237d3e2d2f}

udid:      HITACHI%5FOPEN-V%5F0D360%5F01A5

site:      -

version:   3.1

iosize:    min=512 (bytes) max=1024 (blocks)

public:    slice=0 offset=32896 len=272585872 disk_offset=0

private:   slice=0 offset=128 len=32768 disk_offset=0

update:    time=1325782025 seqno=0.28

ssb:       actual_seqno=0.0

headers:   0 120

configs:   count=1 len=24072

logs:      count=1 len=3648

Defined regions:

config   priv 000024-000119[000096]: copy=01 offset=000000 enabled

config   priv 000128-024103[023976]: copy=01 offset=000096 enabled

log      priv 024104-027751[003648]: copy=01 offset=000000 enabled

lockrgn  priv 027752-027823[000072]: part=00 offset=000000

Multipathing information:

numpaths:   5

c28t0d1           state=enabled

c54t0d1           state=enabled

c80t0d1           state=enabled

c110t0d1         state=enabled

c144t0d1         state=enabled

(3) I've check the output of "ioscan -fnCdisk", the 3 missing H/W paths is not shown at all. 

------------------------------------------------------------------------------------

 We've checked the storage ports and san zoning, all works well. And the revision of HBA driver is the recent one.

Any idea what's the problem?

Thanks for your help !!!

[Patrick Wallek]

I ran into an issue like this recently and there were several different issues that came to light.

1) We replaced a fibre card in the server.  This changed the world wide name  which meant LUNs had to be presented from the disk array again and, I believe the zone had to be changed as well.

2) We were still shor 2 paths and the SAN Administrator finally found that there were some issues with some ports being disabled on the disk array.  

None of the problems were on the server.

If you run an 'ioscan' command and cannot see the disk drives then the problem likely isn't on the server.

Once we had everything presented correctly, and visible in ioscan, there were a couple of VxVM commands that had to be run in order for VxVM to see all the paths.  Unfortunately I don't remember those commands at the moment.

[chris huys_4]

Hi,

hitachi xp diskarray I suppose. (vs hp xp diskarray)

Try to do a 

# ioscan -fnk > /var/tmp/ioscan_fnk_before.out

# fclpdiag > /var/tmp/fclpdiag_before.out

# fcmsutil /dev/fclpX -f reset

(if fcmsutil has the reset option on hp-ux 11.23)

of every emulex fc hba of the hp-ux 11.23 server.

And then a ioscan -fnk.

# ioscan -fnk > /var/tmp/ioscan_fnk_after.out

See if the fcmsutil reset, brings back on a OS level, the disappeared luns.

If not or if it does, log a support call with hp.

Sent them the above output, together with additional sysinfo (getsysinfo.sh) and VRTSexplorer output.

Greetz,

Chris