LUN detection in a mixed SAN environment

[FERRARI MARCO]

Hi everyone.
WE are running a few HP clustered rp8400 with HP-UX 11i.
When connected to an HP XP128, we can get a unique mapping of CU:LDEV via xpinfo.
Now we also have a few servers connected to a SUN 9970, which is the same hardware with different firmware.
SUN does not provide us with an utility capable of mapping HP-UX special files (/dev/dsk/c.t.d.) with the corresponding CU:LDEV on the remote device, so that it is undocumented how to distinguish different LUNs the same size.
Useful info is that my colleagues set up zoning and we're not directly connected to a couple of switches but in a fabric.
The in-house procedure we devised is as follows:
1) my colleague create a new LUN in a zone
2) he/she gives me the hex sequential number as
creation progresses ( not the CU:LDEV pair )
3) I run ioscan on my HP_UX server
4) examining the HW path I find a corresponding OCTAL number and that's it
Obviously, there's not much variance between the CUs and LDEVs involved, so I do not really know what would happen with another LUN in another CU.
At the same time pvcreate is always run with some stress under this undocumented scenario.
I hope I provided all the needed info; thanks in advance
Marco

[RAC_1]

echo "0x2008?4D" |adb /dev/dsk/cxtxdx -- disk1

Run that through different systems and can check if ids differ or not.

Do not know how it works on Solaris. Might be something to do with prtdiag and drvconfig.

Anil

[TwoProc]

You should be able to get a copy of "xpinfo" for Solaris (and you should already have it for the HP system). This tells you pretty much what you need to know. The XP system is sold and supported for HP,Sun, and IBM, so getting the xpinfo toolset should not be a big deal. This would give you the CU LDEV mappings on both systems that should match up.

[FERRARI MARCO]

HI Anil.
Thanks for your help.
May be I am not familiar with adb, but on the XP128 being idle at the moment, I got as follows:

echo "0x2008?4D" |adb /dev/dsk/c12t5d6
2008: 642329372 1090252605 642329372 1090252686
I am unable to read it and to map it to:

grep c12t5d6 xpinfo.ITRC
/dev/rdsk/c12t5d6 cd 05 06 CL2A 00:1a OPEN-9

Thanks again, Marco

[FERRARI MARCO]

Well, I actually ran it on the wrong OS version, sorry! My colleague was too afraid of running it on a production system and we both forgot of the OS release difference.
Anyway, on am 11i box, on the Alternate Link,
I got as follows:

echo "0x2008?4D" |adb /dev/dsk/c6t1d2
2008: -797644092 1114095452 -797644092 1114095507

which is still quite difficult for me to read.

Marco

[RAC_1]

The command that I gave is for hp-ux systems. Say you have two systems and both can see a disk (from SAN) and you want to know it is the same disk.
From box1 - /dev/dsk/c12t8d2
From box2 - /dev/dsk/c13t8d2

Now if you run command on both disks, they will report same output, if it is same disk from SAN being seen from both boxes.

Now if you run the command, you will get output from both systems. Same applies to alternate links.

As told earlier, with Sun it might be combination of prtdiag and drvconfig. I never used it though.

Anil

[FERRARI MARCO]

Hi Anil.
Thank you again but I'd like to have a SUN utility or some XPINFO-like command to precisely identify the LUN.
Before pvcreate-ing I believe I wouldn't get enough info from the command you have suggested; at the same time the octal termination of the hardware path looks fine enough and easier to adopt.
Best regards,
Marco

[Alzhy]

MARCO,

On Solaris systems, I use a tool called "lunstat" which works similar to xpinfo but works only with Hitachi or Sun rebranded Hitachi arrays. I am not aware though if there is a "lunstat" version for HP-UX.

You can try using the following IF you have VxVM 3.5 (even just the base and not actually used) installed:

Use vxdmpinq to get the serial number of the LUN. The serial number's last 4 digits will give you the CU:LDEV i.e:

# /etc/vx/diag.d/vxdmpinq /dev/rdsk/c92t0d0

Inquiry for /dev/rdsk/c92t0d0, evpd 0x0, page code 0x0
Vendor id : HP
Product id : OPEN-V
Revision Number : 5001
Serial Number : 50 0753F0B66
xpinfo -f /dev/rdsk/c92t0d0

Device File : /dev/rdsk/c92t0d0 Model : XP???
Port : CL1C Serial # : 00030015
Target : 00 Code Rev : 5001
LUN : 00 Subsystem : 000f
CU:LDev : 0b:66 CT Group : ---
Type : OPEN-V CA Volume : SMPL
Size : 53248 MB BC0 (MU#0) : SMPL
ALPA : 00 BC1 (MU#1) : SMPL
Loop Id : 7e BC2 (MU#2) : SMPL
SCSI Id : --- RAID Level : RAID5
FC-LUN : 0000753f00000b66 RAID Group : 11-6
Port WWN : 60060e8004753f00 ACP Pair : 3
Disk Mechs : R149 R159 R169 R179



As you can see in the above example on an XP LUN - the serial number reported by vxdmpinq is: "50 0753F0B66" - therefore, the CU:LDEV is "0B:66" the last 4 digits. We can check indeed that it is so via xpinfo.

So try this apporach on a LUN that belongs to the storedge and see if the same is true. since xpinfo will not work -- ask your Storesge admin if this indeed is true.

[Victor BERRIDGE]

The HDS utilitie you are looking for is HDVM
but I dont know if it is a separate package or if included with HiCommand

The command you use is:
/opt/HDVM/util/bin/hldutil

example of the output:
/dev/rdsk/c4t1d3 /opt/sas/9.1.3 HITACHI OPEN-E CL2-A 1 3 01:3B 274F R450 1-10 50060B000023F04E
50060B000023F04F
/sas9wks

/dev/rdsk/c4t1d4 HITACHI OPEN-E CL2-A 1 4 01:8C 274F R450 1-12 50060B000023F04E
50060B000023F04F
/dev/rdsk/c4t1d5 HITACHI OPEN-E CL2-A 1 5 01:8D 274F R450 1-12 50060B000023F04E
50060B000023F04F
...

All the best
Victor

[Alzhy]

Marco, can you try and do a :

/etc/vx/diag.d/vxdmpinq /dev/rdsk/cXtYdZ

on a LUN that belongs to the Sun FLavour of the Hitachi Array (the 9970)?

I am pretty confident this will be your key in getting the CU:LDEV to HP-UX Device mapping you need sans the need for xpinfo or similar tool.

[Victor BERRIDGE]

just in case...
This is what I found with swlist...
HDVMAgent 4.0 HiCommand Device Manager - Agent (Build 0400-05)



All the best
Victor

[FERRARI MARCO]

Hi.

I ran

/etc/vx/diag.d/vxdmpinq /dev/rdsk/c_t_d_

where underscores are for 0-9 digits

and I got for our LUN 00:b6

Inquiry for /dev/rdsk/c4t0d1, evpd 0x0, page code 0x0
Peripheral Qualifier/Device Type : 0
Removable bit : 0
Device type modifier : 0
ISO Version : 0
ECMA Version : 0
ANSI Version : 2
Additional Length : 77
Vendor id : HITACHI
Product id : OPEN-E
Revision Number : 2101
Serial Number : ______B6
Raw data:
Byte 0 : 0x0
Byte 1 : 0x0
Byte 2 : 0x2
Byte 3 : 0x2
Byte 4 : 0x77 w
Byte 5 : 0x0
Byte 6 : 0x0
Byte 7 : 0x2
Byte 8 : 0x48 H
Byte 9 : 0x49 I
Byte 10 : 0x54 T
Byte 11 : 0x41 A
Byte 12 : 0x43 C
Byte 13 : 0x48 H
Byte 14 : 0x49 I
Byte 15 : 0x20
Byte 16 : 0x4f O
Byte 17 : 0x50 P
Byte 18 : 0x45 E
Byte 19 : 0x4e N
Byte 20 : 0x2d -
Byte 21 : 0x45 E
Byte 22 : 0x20
Byte 23 : 0x20
Byte 24 : 0x20
Byte 25 : 0x20
Byte 26 : 0x20
Byte 27 : 0x20
Byte 28 : 0x20
Byte 29 : 0x20
( .... )

Byte 46 : 0x42 B
Byte 47 : 0x36 6
Byte 48 : 0x20
Byte 49 : 0x31 1
Byte 50 : 0x44 D
Byte 51 : 0x20
Byte 52 : 0x1
Byte 53 : 0x1
Byte 54 : 0x1
Byte 55 : 0x1
Byte 56 : 0x0
Byte 57 : 0x0
Byte 58 : 0x0
Byte 59 : 0x0
Byte 60 : 0x0
Byte 61 : 0x0
Byte 62 : 0x0
Byte 63 : 0x0
Byte 64 : 0x0
Byte 65 : 0x0
Byte 66 : 0x0
Byte 67 : 0x0
Byte 68 : 0x0
Byte 69 : 0x0
Byte 70 : 0x0
Byte 71 : 0x0
Byte 72 : 0x0
Byte 73 : 0x0
Byte 74 : 0x0
Byte 75 : 0x0
Byte 76 : 0x0
Byte 77 : 0x0
Byte 78 : 0x0
Byte 79 : 0x0
Byte 80 : 0x0
Byte 81 : 0x0
Byte 82 : 0x0
Byte 83 : 0x0
Byte 84 : 0x0
Byte 85 : 0x0
Byte 86 : 0x0
Byte 87 : 0x0
Byte 88 : 0x0
Byte 89 : 0x0
Byte 90 : 0x0
Byte 91 : 0x0
Byte 92 : 0x0
Byte 93 : 0x0

( ... )

Byte 123 : 0x2


As soon as I'll be able to run the command against production PVs, I'll testify if it really works as it seems.

I have removed extra info to avoid a precise detection of my Company.

Thank you very much Nelson !

Marco

[FERRARI MARCO]

Add-on:

there was also a promising:

Byte 105 : 0x6
Byte 106 : 0xb

I cut off in an iconoclastic fever.

Regards,

Marco