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.
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
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.
" If u think u can , If u think u cannot , - You are always Right . "
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")
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
