VA7110 - problem seeing both paths

[Robert_Jewell]

A recently installed system and I have a problem in seeing the alternate paths for a VA7110 Disk Array.

The disk array has dual controller and is up to the latest available firmware.  This is attached to an L2000 running HP-UX 11.00 (old stuff I know...) and has CommandVIew SDM installed (latest available online).


VA7110 with dual controllers is connected to one host via two HBAs.  These show up good in ioscan:

fcp         0  0/4/0/0.8               fcp       CLAIMED     INTERFACE    FCP Protocol Adapter
ext_bus     4  0/4/0/0.8.0.110.0       fcparray  CLAIMED     INTERFACE    FCP Array Interface
target      8  0/4/0/0.8.0.110.0.0     tgt       CLAIMED     DEVICE
disk        4  0/4/0/0.8.0.110.0.0.0   sdisk     CLAIMED     DEVICE       HP      A6189B
                                      /dev/dsk/c4t0d0   /dev/rdsk/c4t0d0
disk        6  0/4/0/0.8.0.110.0.0.1   sdisk     CLAIMED     DEVICE       HP      A6189B
ext_bus     5  0/4/0/0.8.0.255.6       fcpdev    CLAIMED     INTERFACE    FCP Device Interface
target      9  0/4/0/0.8.0.255.6.14    tgt       CLAIMED     DEVICE
ctl         4  0/4/0/0.8.0.255.6.14.0  sctl      CLAIMED     DEVICE       HP      A6189B
                                      /dev/rscsi/c5t14d0

                                      
fcp         1  0/7/0/0.8               fcp       CLAIMED     INTERFACE    FCP Protocol Adapter
ext_bus     6  0/7/0/0.8.0.108.0       fcparray  CLAIMED     INTERFACE    FCP Array Interface
target     10  0/7/0/0.8.0.108.0.0     tgt       CLAIMED     DEVICE
disk        5  0/7/0/0.8.0.108.0.0.0   sdisk     CLAIMED     DEVICE       HP      A6189B
                                      /dev/dsk/c6t0d0   /dev/rdsk/c6t0d0
ext_bus     7  0/7/0/0.8.0.255.6       fcpdev    CLAIMED     INTERFACE    FCP Device Interface
target     11  0/7/0/0.8.0.255.6.12    tgt       CLAIMED     DEVICE
ctl         5  0/7/0/0.8.0.255.6.12.0  sctl      CLAIMED     DEVICE       HP      A6189B
                                      /dev/rscsi/c7t12d0

Lun 0 is shown under both paths:

disk        4  0/4/0/0.8.0.110.0.0.0   sdisk     CLAIMED     DEVICE       HP      A6189B
                                      /dev/dsk/c4t0d0   /dev/rdsk/c4t0d0
                                      
disk        5  0/7/0/0.8.0.108.0.0.0   sdisk     CLAIMED     DEVICE       HP      A6189B
                                      /dev/dsk/c6t0d0   /dev/rdsk/c6t0d0


However, after creating further LUNs, only one path is displaying the new LUNs:

target      8  0/4/0/0.8.0.110.0.0     tgt       CLAIMED     DEVICE
disk        4  0/4/0/0.8.0.110.0.0.0   sdisk     CLAIMED     DEVICE       HP      A6189B
                                      /dev/dsk/c4t0d0   /dev/rdsk/c4t0d0
disk        6  0/4/0/0.8.0.110.0.0.1   sdisk     CLAIMED     DEVICE       HP      A6189B   <----
disk        7  0/4/0/0.8.0.110.0.0.2   sdisk     CLAIMED     DEVICE       HP      A6189B   <----
ext_bus     5  0/4/0/0.8.0.255.6       fcpdev    CLAIMED     INTERFACE    FCP Device Interface
.
.
target     10  0/7/0/0.8.0.108.0.0     tgt       CLAIMED     DEVICE
disk        5  0/7/0/0.8.0.108.0.0.0   sdisk     CLAIMED     DEVICE       HP      A6189B
                                      /dev/dsk/c6t0d0   /dev/rdsk/c6t0d0
ext_bus     7  0/7/0/0.8.0.255.6       fcpdev    CLAIMED     INTERFACE    FCP Device Interface


The path where the LUNs are showing is the path attached to Controller 1, however all LUNs should be present on both paths should they not?


Something else I find interesting is that the management path is reporting off of the secondary controller:

armdsp -i shows:

 Product ID:        HP-A6189B
   Device Type:     Virtual Disk Array
   Alias:           va-1
   World Wide Name: 50060b000014e7ba
   Unique ID:       HPA6189B00USR00002AN
   Serial Number:   00USR00002AN
   Management Path: hpdev50:/dev/dsk/c6t0d0

Thinking this may be an issue, I forced the management path to the primary controller by disabling the HBA on the secondary controller and then running the 'armdiscover' command again.  The results were the same (after enabling the HBA again of course).

I am curious if anyone has seen this behavior in the past?

-Bob

[Robert_Jewell]

Something else I just tried....

I failed the primary controller in the array (by removing it) and then the LUNs were seen on the alternate path.  I re-installed the controller and those new devices were no longer seen.

It seems that the array is configured to use its controllers in an Active/Passive mode, rather than Active/Active.

Should I not be able to use alternate pathing on a VA7110?   Is there a command to set the controller mode that I cannot find documented?

Thanks in advance!

Bob

[Robert_Jewell · Accepted solution]

...and seeing this I looked further at the man pages and found this in the one for "armmgr":

  -S {on|off|true|false}
           Controls whether the array will make the non-optimal (secondary)
           path to LUNs visible to the hosts. A value of on (true) enables
           the secondary path. A value of off (false) disables it.

In all actuality the command should be run as follows to enable both paths:

# armmfg -S off va-1
Disable Secondary Path Presentation set to : off.

So it appears that man page info is reversed from the actual command.

All good now!

-Bob