How can static names be assigned for SCSI devices using udev in Red Hat Enterprise Linux 6?
Environment
- Red Hat Enterprise Linux 6
- udev
- FC and SCSI storage device
Issue
- How can I assign static /dev/sdN names to device to prevent them from changing across boots?
- How can static names be assigned for SCSI devices using udev in Red Hat Enterprise Linux 6?
- How can I assign static names for SCSI devices using udev in Red Hat Enterprise Linux 6?
Resolution
NOTE: The operating system provides several non-persistent name spaces to represent the access paths to storage devices. One is these is the /dev/sdN name space. You cannot assign nor change sdN names as these are owned and assigned by the kernel. These names can and will change across reboots. See the "Persistent Naming" section in the Red Hat Enterprise Linux 6 "Storage Administration Guide" for further details.The design of the linux kernel architecture is focused on using self-identification of data, disks, partitions, and filesystems (targets) for accessing and mounting of same. This is done via the use of unique names provided by the storage device (WWIDs) or by the data there on (UUIDs). The correct method of accessing a target is via the unique names provided by the target itself rather than trying to depend on device name ordering which is not designed, and thus not guaranteed, to be the same across boots.
There are some ways to workaround the architecture of using self-identification directly. One such method is to use udev rules to create symbolic links using the target supplied self-identification information as outlined below. Only the use of symbolic links is supported.
The udev rules in this article will only work on Red Hat Enterprise Linux 6. The udev rule syntax has changed slightly between the versions of udev on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 5. A related kbase article that applies to Red Hat Enterprise Linux 5 can be found here: [How can I assign static names for SCSI devices using udev in Red Hat Enterprise Linux 5?](/site/solutions/7318). Additionally, the article for Red Hat Enterprise Linux 7 can be found here: [How are custom persistant names assigned for SCSI devices using udev in Red Hat Enterprise Linux 7 and later kernels?](https://access.redhat.com/solutions/2975361).
1. The first step is to acquire the SCSI identifier of the SCSI device. Typically, this will be a WWID. The following command must be run as root, otherwise no output is generated as privileged access is needed to access the raw device. To get the identifier of say, /dev/sda, run this command:
```
# scsi_id --whitelisted --replace-whitespace --device=/dev/sda
```
The output will look something like the following:
```
# scsi_id --whitelisted --replace-whitespace --device=/dev/sda
3500000e012d5ede0
```
The scsi_id command issues a SCSI INQUIRY command to the device to access the vital product data (VPD) page 0x83 data, if available. That page includes the device WWID along with other information. Or if a WWID is not available then an id based upon the serial number from VPD page 0x80 is output. Since nominally a WWID (World Wide IDentifier) should be available, the device identifier will be referred to as WWID within this document. The following is an example of an SCSI identifier based on serial number:
```
# scsi_id --whitelisted --replace-whitespace --device=/dev/sda
1ATA_ST3250310AS_9RY3GS4M
```
The result of the `scsi_id` command (the long string of characters) is the WWID of the device that is currently mapped to /dev/sda. This WWID will be the same for each path to the device and for each partition on the device. The WWID is persistent and will not change even if other devices are added to or removed from the system. It will remain the same WWID across all reboots. However the mapping of the device to /dev/sda could change. This is why there is a need to create a static device name for legacy software use. The WWID is what the udev device names will be keying off of.
The `udevadm` command can be used to find the same WWID information:
```
# udevadm info --query all --name=/dev/sdd | grep WWN
E: ID_WWN=0x500000e012d5ede0
E: ID_WWN_WITH_EXTENSION=0x500000e012d5ede0
```
The WWN (World Wide Name, another name for a World Wide IDentifier) and other information is available from `udevadm` and is usually the preferred basis for writing udev rules as it is a more efficient manner for looking up device identifiers rather than having to spawn programs.
-
We could also use the command below to get the SERIAL ID of SCSI device.
# udevadm info --query all --name=/dev/sda | grep ID_SERIAL E: ID_SERIAL=ST3250310AS_9RY3GS4M E: ID_SERIAL_SHORT=9RY3GS4M -
Rules need to be created for naming the device. Create the
/etc/udev/rules.d/20-names.rulesfile. Within this file, the naming rule will be added. Rules will have the following format:ACTION=="add|change", KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=%N", RESULT=="WWID", SYMLINK+="devicename%n" or using udev ENV syntax: ACTION=="add|change", KERNEL=="sd*", ENV{ID_WWN}=="WWID", SYMLINK="devicename%n"Replace the strings
WWIDanddevicenamein the above template with the actual WWID retrieved in step 1 above and the desired name for the device. Do not attempt to use kernel non-persistent enumerated names such assd* dm* st* nt* eth*etcetera as the target of theSYMLINK. Doing so is not supported. The specified name value for theSYMLINKmust be unique across all rules.In our example, if we wanted the disk to be named
mydiskname, then the actual rule would look like the following:ACTION=="add|change", KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=%N", RESULT=="3500000e012d5ede0", SYMLINK+="mydiskname%n" or using udev ENV syntax: ACTION=="add|change", KERNEL=="sd*", ENV{ID_WWN}=="500000e012d5ede0", SYMLINK="mydiskname%n"This will cause the system to check all SCSI devices which match
/dev/sd*and to be checked for the given WWID500000e012d5ede0. When it finds a matching device, it will create a symbolic link named/dev/mydisknamethat points to/dev/sda-- at least within the current boot cycle. If there are any partitions on the device additional symbolic links will be created:/dev/mydiskname1for the first partition (/dev/sda1),/dev/mydiskname2for the second partition (/dev/sda2), and so on. -
To test the rule, use the
udevadm testcommand like so:# udevadm test /block/sda 2>&1 | grep mydisknameIf /dev/sda has partitions on it, run this command to test a device will be created for /dev/sda1:
# udevadm test /block/sda 2>&1 | grep mydiskname udev_rules_apply_to_event: LINK 'mydiskname' /etc/udev/rules.d/20-names.rules:1 link_find_prioritized: found '/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/host0/port-0:0/end_device-0:0/target0:0:0/0:0:0:0/block/sda' claiming '/dev/.udev/links/mydiskname' link_update: creating link '/dev/mydiskname' to '/dev/sda' node_symlink: creating symlink '/dev/mydiskname' to 'sda' udevadm_test: DEVLINKS=/dev/mydiskname /dev/block/8:0 /dev/disk/by-id/scsi-3500000e012d5ede0 /dev/disk/by-id/wwn-0x500000e012d5ede0 -
Finally, trigger udev. This action is further explained in the following article:
-
Verify that the device(s)
/dev/mydiskname*have been created and are symbolic links to to /dev/sda*.# ls -l /dev/mydiskname* lrwxrwxrwx. 1 root root 3 Feb 20 21:52 /dev/mydiskname -> sda lrwxrwxrwx. 1 root root 3 Feb 20 21:52 /dev/mydiskname1 -> sda1 :As long as the device with WWID
3500000e012d5ede0is attached/visible to Red Hat Enterprise Linux, it will always be statically bound to the name/dev/mydisknameby udev. Even if the sdN changes after a reboot, the symbolic name will change to point to the new sdN device name as the udev rule is based upon persistent device identifiers.
Related Articles:
How are persistant names assigned for SCSI devices using udev in Red Hat Enterprise Linux 7?
How can static names be assigned for SCSI devices using udev in Red Hat Enterprise Linux 5?
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.