Identify LUN ID with SCSIMGR

[Torsten.]

Dear all,

I currently have a server running 11.31 release version 11.03 with around 100 LUNs presented from EVA HSV300 (XCS 09534000) and P2000.

Now I try to find an easy way to identify the relation between persistant DSF and LUN ID.

I try

# scsimgr -p get_attr all_lun  -a lunid

but this delivers me around 100 empty lines on the screen.

The command

# scsimgr -p get_attr all_lun -a device_file -a lunid

delivers for example

/dev/rdisk/disk145:
/dev/rdisk/disk146:
...

there is the device file, but NO LUN ID.

A command like this

# scsimgr  get_attr -C lunpath -I 27 -a lunid

works and delivers

current =0x400f000000000000 (LUN # 15, Flat Space Addressing)

This is what I want to have, but I don't want to run the command for each path one by one, I want to have a command for all LUNs at once.

Any ideas?

[donna hofmeister]

the scsimgr manul shows this for displaying the hardware path, device file, WWID and serial number for all devices, in scriptable output:

# scsimgr -p get_attr all_lun -a hw_path -a device_file -a wwid -a serial_number
64000/0xfa00/0x0:/dev/rdisk/disk15:0x0004cffffebbf737:3FD1M2SW
64000/0xfa00/0x1:/dev/rdisk/disk16:0x0004cffffebbe43e:3FD1LZ0S
64000/0xfa00/0x2:/dev/rdisk/disk17::
64000/0xfa00/0x3:/dev/rdisk/disk18:0x20000020371972ee:LS255190000010080N0V
64000/0xfa00/0x4:/dev/rdisk/disk19:0x20000020371972e3:LS271211000010080N1H
64000/0xfa00/0x5:/dev/rdisk/disk20:0x20000020371972eb:LS24603100001008K74M
64000/0xfa00/0x6:/dev/rdisk/disk21:0x200000203726a3af:LJS87900000029491GWF
64000/0xfa00/0x7:/dev/rdisk/disk22:0x20000020370fe8c8:LJ67387800002916H9A9
64000/0xfa00/0x8:/dev/rdisk/disk23:0x200000203726d3b9:LJT4848400002950H0R4
64000/0xfa00/0x9:/dev/pt/pt2::USSO08016323
64000/0xfa00/0xa:/dev/pt/pt3::USSO08016323

does that help?

[Torsten.]

I have read the manual up and down and NO, this does not help!

It gives the hw_path, the device file, the serial and the WWID, but not the LUN ID!

Matching the serial# or WWID to the device file is exactly what I don't want to do!

[Robert_Jewell]

What about simply:  # ioscan -m lun

For example:

disk     17  64000/0xfa00/0x11   esdisk  CLAIMED     DEVICE       online   DGC     CX3-20cWDR5
             0/4/2/0.0x5006016041e07841.0x4000000000000000
             0/5/1/0.0x5006016841e07841.0x4000000000000000
                      /dev/disk/disk17   /dev/rdisk/disk17
disk     18  64000/0xfa00/0x12   esdisk  CLAIMED     DEVICE       online   DGC     CX3-20cWDR5
             0/4/2/0.0x5006016041e07841.0x4001000000000000
             0/5/1/0.0x5006016841e07841.0x4001000000000000
                      /dev/disk/disk18   /dev/rdisk/disk18
disk     19  64000/0xfa00/0x13   esdisk  CLAIMED     DEVICE       online   DGC     CX3-20cWDR5
             0/4/2/0.0x5006016041e07841.0x4002000000000000
             0/5/1/0.0x5006016841e07841.0x4002000000000000
                      /dev/disk/disk19   /dev/rdisk/disk19

You get the LUNID as seen by the disk array and the psf.  What I dont know is if the format of the LUNID is consistent across storage vendors.  I only have the Clariion on 11.31 so I cant compare.

-Bob

[Torsten.]

This is probably not a bad idea.

The first part is known (0/4/2/0), it's the path to the FC HBA.

The next part (0x5006016041e07841) identifies the array.

The last part (0x4001000000000000)identifies the LUN.

I found this:

"Since the LUN address is printed in hexadecimal, the first hexadecimal digit contains both the addressing method and the start of the LUN number. For example, the first 16 bits of the LUN address 0x400f000000000000 is binary 0100000000001111. The leading 01 is the addressing method (Flat Space Addressing) and the remaining bits represent the LUN number (15). Thus, the LUN address 0x400f000000000000 represents LUN number 15 using the Flat Space Addressing method."

So in this example (0x4001000000000000) it is LUN 1 (001hex) in Flat Space Addressing method (0x4).

The scsimgr promises to tell the LUN in decimal!

This would be great and simple, but it looks like it doesn't work.

Is it a problem of scsimgr or the array firmware?

Robert, if you could try the command above you could clarify this question.

# scsimgr -p get_attr all_lun -a device_file -a lunid

[Robert_Jewell]

I had the same results you did:

# scsimgr -p get_attr all_lun -a device_file -a lunid
/dev/rdisk/disk15:
/dev/rdisk/disk16:
...etc

# scsimgr -p get_attr all_lun -a lunid

 (blank lines for each LUN it appears)

-Bob

[Duncan Edmonstone]

Torsten,

I see the same thing too - yet something like:

#scsimgr -p get_attr all_lun -a device_file -a max_q_depth

or

#scsimgr -p get_attr all_lun -a device_file -a hw_path

works as expected... I can't see a reason why this shouldn't work - I'd be tempted to report that as a bug and see where you get

[Arunabha Banerjee]

You can simply get the LUN ID executing following command.

I have attached a sample output.

# scsimgr lun_map | egrep '(disk|WWID)'

[Torsten.]

Sorry, this is NOT what I was looking for.

[Arunabha Banerjee]

What about the below command ?

# scsimgr lun_map | egrep '(disk|Hardware path)'

Sample output attached