Symptom
After a user adds initiators to and maps LUNs to a host or host group, the host can discover the LUNs. Then, the user maps a LUN with the host LUN ID being 0 to the host on DeviceManager. However, after the host scans for LUNs again, no LUNs can be discovered.
Root Cause Analysis
In this scenario, the host considers that the WWN of the LUN whose host LUN ID is 0 is different from that of the subsequently mapped LUN whose host LUN ID is also 0. As a result, the host stops scanning for LUNs. In the event of replacing a LUN, this problem also occurs.
Troubleshooting
If the tracing log contains "Run'scsimgr replace_wwid' command to validate the change", run the scsimgr replace_wwid command to rectify the fault.
For example, the /var/adm/syslog/syslog.log file contains the following information:
Oct 12 10:52:15 root vmunix: class : lunpath, instance 11Oct 12 10:52:15 root vmunix: Evpd inquiry page 83h/80h failed or the current page 83h/80h data donot match the previous known page 83h/80h data on LUN id 0x0 probed beneath the target path (class = tgtpath, instance = 5) The lun path is (class = lunpath, instance 11).Run 'scsimgr replace_wwid' command to validate the changeOct 12 10:52:15 root vmunix:Oct 12 10:52:15 root vmunix: An attempt to probe existing LUN id 0x0 failed with errno of 14.
In this case, you need to run the scsimgr replace_wwid -C lunpath –I 11 command and then the ioscan command to scan for LUNs. This ensures that the host can properly scan for and discover LUNs.
To prevent the preceding problem, map LUNs to hosts by following instructions in the Basic Storage Service Configuration Guide corresponding to your storage system and then scan LUNs on the host.
