scsimgr replace_wwid messages

[mjos]

Hi,
I am getting multiple 'csimgr replace_wwid' messages in our Unix servers which have external storage assgined. There are many class : lunpath, instance ids.
Is there any way I can get rid of these instance IDs in one shot or do I have run the 'csimgr replace_wwid' commands for each of the Lun instances.

[mjos]

The dmesg messages that I am recieving are

class : lunpath, instance 1794
Evpd inquiry page 83h/80h failed or the current page 83h/80h data do not match the previous known page 83h/80h data on LUN id 0x0 probed beneath
the target path (class = tgtpath, instance = 56) The lun path is (class = lunpath, instance 1794).Run 'scsimgr replace_wwid' command to validat
e the change

Due to this the server is not ablet to detect the newly assigned LUN.
There are hundreads of such messages. Is there any way I can successfully bind all the Lun Instances using the scsimgr replace_wwid command or do I have to run the command individualy for each lun instance ids

[mjos]

Gurus - any ideas please?

[Michael Leu]

AFAIK there is no 'one shot' command, you have to do this for each instance with 'scsi_mgr replace_wwid'.

[Raj D. · Accepted solution]

mjos,

Please check out this doc :
To validate replaement of lunpath and to bind lunpath:

http://docs.hp.com/en/scsimgr/scsimgr_whp_AR0709.pdf

Hth,
Raj.

[Raj D.]

mjos,

During lun assignment , zoning , mappng you may may see the error messages in syslog or dmesg,
You can check the status if they arestill disabled or ok with :# scsimgr -D get_info /dev/rdisk/diskxxx

if disabled you can try enabling it with enable command or binding the lunpath.

[Duncan Edmonstone]

The white paper that Raj D pointed you at has the info, and yes there is a "one shot" method to do this, as you can apply the replace_wwid to a complete target path... this is described in the WP starting at the bottom of p29 in the section entitled "Validating disk replacement for all lunpaths under a target path".

You can easily identify what target path instances your LUNs are associated with by running "ioscan -fN" and you will see what lunpaths are under which target path instance numbers (to just see the target path instances try "ioscan -fNC tgtpath")

HTH

Duncan

[mjos]

Thank you Guys, the doc was very usefull.

[mjos]

I validated the replacedment for the lunpath for the disk3546 using the scsimgr command
#scsimgr -f replace_wwid -D /dev/rdisk/disk3546
scsimgr: Successfully validated binding of LUN paths with new LUN.

But again in ioscan output the disks shows up as no_hw. Once the validation is done, shouldnt this no_hw disappear from the ioscan output.
#ioscan -N -n -f |grep -i no_hw |grep disk3546
lunpath 3972 0/0/6/1/0.0x50001fe15012a269.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3761 0/0/6/1/0.0x50001fe15012a26b.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3977 0/0/6/1/0.0x50001fe15012a26d.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3978 0/0/6/1/0.0x50001fe15012a26f.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3759 0/0/14/1/0.0x50001fe15012a268.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3760 0/0/14/1/0.0x50001fe15012a26a.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3980 0/0/14/1/0.0x50001fe15012a26c.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3979 0/0/14/1/0.0x50001fe15012a26e.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3762 1/0/4/1/0.0x50001fe15012a269.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3971 1/0/4/1/0.0x50001fe15012a26b.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3973 1/0/4/1/0.0x50001fe15012a26d.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3975 1/0/4/1/0.0x50001fe15012a26f.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3764 1/0/6/1/0.0x50001fe15012a268.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3763 1/0/6/1/0.0x50001fe15012a26a.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3974 1/0/6/1/0.0x50001fe15012a26c.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546
lunpath 3976 1/0/6/1/0.0x50001fe15012a26e.0x4061000000000000 eslpt NO_HW LUN_PATH LUN path for disk3546

[Duncan Edmonstone]

Your LUN is working and servicing IOs though isn't it?

Generally NO_HW entries in ioscan don't go away until the next time you reboot... shouldn't be a problem though.

HTH

Duncan