No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Failed to Scan For LUNs After UltraPath Is Installed and the Server Is Restarted

Publication Date:  2019-04-12 Views:  47 Downloads:  0
Issue Description

A site is deployed with an image storage system, two S5500T storage devices, and 12 Dell servers, and uses Red Hat 6.8 as the operating system. Devices are directly connected by using FC switches. The 12 servers are deployed as a GPFS cluster (drive letter binding in the UUID mode is unsupported). UltraPath is installed at the site properly, the HBA cards of two servers are later configured. After the two servers are added to the host group, LUNs on servers can be scanned for properly, except the two.

Alarm Information

No alarm is generated on the storage. UltraPath is configured on servers properly but storage space mapped to servers cannot be identified.

Handling Process

1.1 Uninstall UltraPath and then install it.

1.2 Update the kernel driver information. Mapped LUNs are displayed.
Restart the server. LUN information disappears.

1.3 According to the results of the previous operations, it is estimated that this issue is related to drive letter binding or UltraPath.

       1.4 Replace UltraPath with the multipathing software provided by Linux. LUNs are displayed after the software is installed and the server is restarted. However, LUN information disappears after the server is restarted repeatedly. Based on this, it is assumed that the drive letter binding is incorrect.

1.5 Remove the configuration files of drive letters that are bond in udev mode and restart the server. Information about LUNs of the correct number is displayed.

1.6 Replace the drive letter binding mode to WWN matching by performing the following steps:

Step 1: Obtain the ID_SERIAL field of a disk.

                                     Run the udevadm monitor --env command to enable monitoring.

                                     Run the echo "add" > /sys/block/sdb/uevent command, where sdb indicates the disk to which the drive letter is specified. The command output of udevmonitor is as follows:


Step 2: Edit the UDEV rule file as follows:



1.7 Restart the server for multiple times. LUN information is displayed properly after each restart.

Root Cause

The customer uses the udev mode to bind drive letters and the configurations in the rule files are incorrect, missing %n at the end of the drive letter. This problem causes partition information failed to be generated.






Editing the rule files is not recommended, because HCTL fields, such as 2:0:0:1, are not fixed. You are advised to change the binding mode to WWN matching.


1. On storage, check host groups, LUN groups, mapping views, and initiator configurations, re-configure storage, restart the host, and scan for disks. If the problem persists, keep on performing the follow-up operations.

2. Check whether switches are configured properly, reconfigure switches, and check whether the LUN information can be identified.

3. On servers, uninstall UltraPath, restart servers and check LUN information. The LUN information is displayed properly.

After the multipathing software provided by the operating system is installed and servers are restarted, information about mapped LUNs can be viewed. However, after servers are restarted repeatedly, LUN information disappears.

4. After the operating system is reinstalled, UltraPath is reinstalled, and servers are restarted, information about mapped LUNs can be viewed. However, after servers are restarted repeatedly, LUN information disappears.

5. Delete the configuration file for drive letter binding. LUN information is always properly displayed no matter how many times the servers are restarted. It is found that the configuration is the cause. Modify the configuration file to change the binding mode to WWN matching. The problem resolved.


If a server boots from drive letters, local disk drivers must be loaded in advance of the HBA card. Otherwise, drive letters may shift. In addition, improper drive letter binding rules in complicated applications scenarios or scenarios where unconventional clustered file systems are used may also result in start failures of servers.