Knowledge Base

The path to the LUN may change after a reboot if cos-rescan.sh did not discover the canonical path. This happens if you did not run cos-rescan.sh on the lowest numbered host bus adapter (HBA) that has a path to the LUN.

When you add a LUN, or restore a failed path to a LUN, you need to run cos-rescan.sh to make the LUN available to the VMware Service Console without rebooting the system. When you run cos-rescan.sh, you supply an HBA name as an argument to the script. The script scans for LUNs connected to that HBA.

If the system has more than one HBA with a path to the new or restored LUN, you need to run cos-rescan.sh for each HBA that has a path to the LUN. The first HBA on which you run cos-rescan.sh becomes the primary path to the LUN.

The canonical path always comprises the lowest-numbered HBA and the target ID to access the LUN. If you run cos-rescan.sh on some other HBA first, the primary path is not the same as the canonical path — until the next reboot. When you reboot the system, all the paths are discovered, and the canonical path becomes the primary path.

When you run cos-rescan.sh, always start with the lowest-numbered HBA and proceed to the highest. That way, the first path on which a LUN is discovered is always the canonical path.

For more information, see www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1352, which describes using cos-rescan.sh and vmkfstools -s to add a new LUN in a single-path configuration.

Note: With ESX Server 2.5 and later, you do not need to run vmkfstools -s separately. The cos-rescan.sh command includes a step to scan for new LUNs.