Simpler Navigation coming for Servers and Operating Systems
Coming soon: a much simpler Servers and Operating Systems section of the Community. We will combine many of the older boards, and you won't have to click through so many levels to get at the information you need. If you are looking for an older board and do not find it, check the consolidated boards, as the posts are still there.
System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Sean M.
Advisor

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

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.

6 REPLIES
Robert_Jewell
Honored Contributor

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

Show the following:

 

  # ioscan -fn

  # ioscan -m dsf

 

 

 

-Bob

----------------
Was this helpful? Like this post by giving me a thumbs up below!
Sean M.
Advisor

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

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

Robert_Jewell
Honored Contributor

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

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

 

 

----------------
Was this helpful? Like this post by giving me a thumbs up below!
Sean M.
Advisor

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

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
Honored Contributor

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

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

----------------
Was this helpful? Like this post by giving me a thumbs up below!
P Arumugavel
Respected Contributor

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

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

#rmsf -L

then

#insf -L

Rgds...
Vel