Unable to create legacy HW path/disk devices for one lun

[Sean M.]

I am probably missing something stupid easy, but I am unable to get the legacy disks to create correctly for a lun that has been presented.  While I can get it represented as a different lun number to fix the problem, I am trying to identify the root cause for it.  Below is what I am seeing.

Note that 0x6 is not creating legacy H/W paths

ioscan -m hwpath
Lun H/W Path      Lunpath H/W Path                 Legacy H/W Path
====================================================================
64000/0xfa00/0x0
                  0/3/0/0/0/0.0x500a098180dea6f7.0x0   0/3/0/0/0/0.1.0.255.0.15.0
                  0/3/0/0/0/1.0x500a098190dea6f7.0x0   0/3/0/0/0/1.2.0.255.0.14.0
64000/0xfa00/0x1
                  0/2/1/0.0xa09171ec5572824.0x0    0/2/1/0.0.0.0.0
64000/0xfa00/0x6
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4000000000000000
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4000000000000000
64000/0xfa00/0x7
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4001000000000000   0/3/0/0/0/0.1.0.15.0.0.1
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4001000000000000   0/3/0/0/0/1.2.0.14.0.0.1
64000/0xfa00/0x8
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4002000000000000   0/3/0/0/0/0.1.0.15.0.0.2
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4002000000000000   0/3/0/0/0/1.2.0.14.0.0.2
64000/0xfa00/0x9
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4003000000000000   0/3/0/0/0/0.1.0.15.0.0.3
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4003000000000000   0/3/0/0/0/1.2.0.14.0.0.3
64000/0xfa00/0xa
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4004000000000000   0/3/0/0/0/0.1.0.15.0.0.4
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4004000000000000   0/3/0/0/0/1.2.0.14.0.0.4
64000/0xfa00/0xb
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4005000000000000   0/3/0/0/0/0.1.0.15.0.0.5
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4005000000000000   0/3/0/0/0/1.2.0.14.0.0.5

ioscan -fNC disk

~

disk      2  64000/0xfa00/0x6  esdisk   CLAIMED     DEVICE       NETAPP  LUN

 scsimgr lun_map -C disk -I 2

~

        LUN PATH INFORMATION FOR LUN : disk2

Total number of LUN paths     = 2 World Wide Identifier(WWID)    = 0x60a98000423975682d5d4465367a6a6a

LUN path : lunpath3 Class                         = lunpath Instance                      = 3 Hardware path                 = 0/3/0/0/0/0.0x500a098180dea6f7.0x4000000000000000 SCSI transport protocol       = fibre_channel State                         = UNOPEN Last Open or Close state      = ACTIVE

LUN path : lunpath4 Class                         = lunpath Instance                      = 4 Hardware path                 = 0/3/0/0/0/1.0x500a098190dea6f7.0x4000000000000000 SCSI transport protocol       = fibre_channel State                         = UNOPEN Last Open or Close state      = STANDBY

Logs show:

Nov  8 11:21:57 testserver vmunix: registration failed because it has been
Nov  8 11:21:57 testserver vmunix: re-mapped from its original LUN (default dev 0xc000000)
Nov  8 11:21:57 testserver vmunix: to a different LUN (default dev 0xd000006).
Nov  8 11:21:57 testserver vmunix:  The administrator has to close the original LUN and
Nov  8 11:21:57 testserver vmunix: then validate this LUN re-mapping using the scsimgr
Nov  8 11:21:57 testserver vmunix: command:
Nov  8 11:21:57 testserver vmunix:        scsimgr [-f] replace_leg_dsf -D /dev/rdsk/cxtydz
Nov  8 11:21:57 testserver vmunix:
Nov  8 11:21:57 testserver vmunix: class : lunpath, instance 4
Nov  8 11:21:57 testserver vmunix: The legacy lun path (b 3 - t 0 - l 0)
Nov  8 11:21:57 testserver vmunix: registration failed because it has been
Nov  8 11:21:57 testserver vmunix: re-mapped from its original LUN (default dev 0xc000000)
Nov  8 11:21:57 testserver vmunix: to a different LUN (default dev 0xd000006).
Nov  8 11:21:57 testserver vmunix:  The administrator has to close the original LUN and
Nov  8 11:21:57 testserver vmunix: then validate this LUN re-mapping using the scsimgr
Nov  8 11:21:57 testserver vmunix: command:
Nov  8 11:21:57 testserver vmunix:        scsimgr [-f] replace_leg_dsf -D /dev/rdsk/cxtydz
Nov  8 11:21:57 testserver vmunix:

[testserver:/home/testuser] ll /dev/*/ | egrep '0xc000000|0xd000006'
[testserver:/home/testuser] ll /dev/disk/disk2
brw-r-----   1 bin        sys          1 0x000006 Nov  8 09:29 /dev/disk/disk2
[testserver:/home/testuser] ll /dev/*/ | egrep -i 'c3t0d0|c1t0d0'

Even with "rmsf -H", and doing an ioscan -fnC disk/insf -e, I am unable to create the legacy device files to even do a replace_leg_dsf.  I tried running it on disk2, but it didn't do anything:

finux136:/home/smcguire] scsimgr replace_leg_dsf -D /dev/rdisk/disk2
Do you really want to replace? (y/[n])? y

Any idea would be greatly appreciated.

[Robert_Jewell]

Show the following:

  # ioscan -fn

  # ioscan -m dsf

-Bob

[Sean M.]

I'm attaching output as my browser kept adding extra indents.

[Robert_Jewell]

OK, well I do see the original legacy HW path on 0x0:

64000/0xfa00/0x0
                  0/3/0/0/0/0.0x500a098180dea6f7.0x0   0/3/0/0/0/0.1.0.255.0.15.0
                  0/3/0/0/0/1.0x500a098190dea6f7.0x0   0/3/0/0/0/1.2.0.255.0.14.0

64000/0xfa00/0x6
                  0/3/0/0/0/0.0x500a098180dea6f7.0x4000000000000000
                  0/3/0/0/0/1.0x500a098190dea6f7.0x4000000000000000

ioscan shows those as follows:

ctl          0  0/3/0/0/0/0.1.0.255.0.15.0  sctl           CLAIMED     DEVICE       NETAPP  LUN
                              /dev/rscsi/c0t15d0

ctl          2  0/3/0/0/0/1.2.0.255.0.14.0  sctl           CLAIMED     DEVICE       NETAPP  LUN
                              /dev/rscsi/c2t14d0

I might suggest trying the following:

# scsimgr replace_wwid -D /dev/rdisk/disk<orig-id>

This will validate the LUN ID and should allow it back online (currently the status shows UNOPEN).

-Bob

[Sean M.]

I've tried running the scsimgr command on the disk, but it doesn't appear to do anything:

ioscan -m dsf /dev/rscsi/c0t15d0 Persistent DSF           Legacy DSF(s) ======================================== /dev/pt/pt4              /dev/rscsi/c0t15d0

scsimgr replace_wwid -D /dev/pt/pt4 scsimgr:WARNING: Performing replace_wwid on the resource may have some impact on system operation. Do you really want to replace? (y/[n])? y scsimgr: Successfully validated binding of LUN paths with new LUN.

scsimgr replace_wwid -D /dev/rdisk/disk2 scsimgr:WARNING: Performing replace_wwid on the resource may have some impact on system operation. Do you really want to replace? (y/[n])? y scsimgr: Successfully validated binding of LUN paths with new LUN.

then

ioscan -fnC disk

insf -e

Output still shows as:

64000/0xfa00/0x6                   0/3/0/0/0/0.0x500a098180dea6f7.0x4000000000000000                   0/3/0/0/0/1.0x500a098190dea6f7.0x4000000000000000

[Robert_Jewell]

Hmmm...usually when you run the scsmgr replace_wwid command the original device is reported as NO_HW and a new one is shown.   Then the io_redirect_dsf is used to reassign the original device name.  Perhaps by using rmsf- H earlier this is causing the problem?

Does 'scsimgr lan_map' still show the LUNs as UNOPEN?

-Bob

[P Arumugavel]

Try disabling and re-enabling legacy naming model...

#rmsf -L

then

#insf -L

Rgds...
Vel