7.3. Configuring persistent storage in a Red Hat Enterprise Linux 5 environment

7.3. Configuring persistent storage in a Red Hat Enterprise Linux 5 environment

In an environment where external storage (for example, Fibre Channel or iSCSI) is used it is advised to configure persistent device names on your hosts. This will also aid in using Red Hat Virtualization's (live) migration feature to implement consistent device names across multiple systems.

Single Path Configuration

On systems not using multipath, udev is a good way to implement LUN persistence. For more information on scsi_id and its various options please consult the man page.

  1. The first step would be to acquire UUIDs. Check/Open your /etc/scsi_id.config file and verify that you have the following line commented out:

    # options=-b
  2. Add the following line to your /etc/scsi_id.config file:


    This configuration option will configure udev to assume that all attached SCSI devices will return a UUID (Unique Device Identifier)

  3. To display the UUID for a given device execute the following command: scsi_id -g -s /block/sdc. The output will look similar to the following:

    # scsi_id -g -s /block/sdc 

    The result of the command above represents the device's UUID. At this time you should verify the UUID you just retrieved is the same displayed via each path the device can be accessed through. The UUID will be used as the primary/sole key to the device. UUIDs will be persistent across reboots and as you add additional storage to your environment.

  4. The next step is to create a rule to name your device. In /etc/udev/rules.d create the file 20-names.rules. You will be adding the new rules to the file /etc/udev/rules.d/20-names.rules , any subsequent rules will be added to the same file using the same format. Rules should have the following format:

    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT=UUID, NAME=devicename

    Replace UUID and devicename with the UUID retrieved above, and the desired name for the device. In the example, the rule would look as follows:

    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="mydevice"

    This forces the system to verify all devices which correspond to a block device ( /dev/sd*) for the given UUID. When it finds a matching device, it will create a device node named /dev/devicename. In the example above, the device node is labeled /dev/mydevice.

  5. As the last step add the following line to /etc/rc.local:


Multi-path configuration

To implement LUN persistence in a multipath environment, you need to define alias names for your multipath devices. To identify a device's UUID or WWID follow the steps from the single path configuration section. The multipath devices will be created in the /dev/mpath directory. In our example below we will define 4 devices in /etc/multipath.conf:

multipaths { 
	multipath { 
	wwid		3600805f30015987000000000768a0019 
	alias		oramp1 
	multipath { 
	wwid		3600805f30015987000000000d643001a 
	alias		oramp2 
	mulitpath { 
	wwid		3600805f3001598700000000086fc001b 
	alias		oramp3 
	mulitpath { 
	wwid		3600805f300159870000000000984001c 
	alias		oramp4 

This configuration will create 4 LUNs named /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 and /dev/mpath/oramp4. Once entered, the mapping of the devices' WWIDs/UUIDs to their new names will now be persistent even after rebooting.

Note: This documentation is provided {and copyrighted} by Red Hat®, Inc. and is released via the Open Publication License. The copyright holder has added the further requirement that Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. The CentOS project redistributes these original works (in their unmodified form) as a reference for CentOS-5 because CentOS-5 is built from publicly available, open source SRPMS. The documentation is unmodified to be compliant with upstream distribution policy. Neither CentOS-5 nor the CentOS Project are in any way affiliated with or sponsored by Red Hat®, Inc.