Configuration File Devices from the Ubuntu Server Guide by OnWorks

Skip to content

4.5. Configuration File Devices‌

Table Device Attributes [p. 95] shows the attributes that you can set for each individual storage device

in the devices section of the multipath.conf configuration file. These attributes are used by DM-Multipath unless they are overwritten by the attributes specified in the multipaths section of the multipath.conf file for paths that contain the device. These attributes override the attributes set in the defaults section of the multipath.conf file.

Many devices that support multipathing are included by default in a multipath configuration. The values for the devices that are supported by default are listed in the multipath.conf.defaults file. You probably will not need to modify the values for these devices, but if you do you can overwrite the default values by including an entry in the configuration file for the device that overwrites those values. You can copy the

device configuration defaults from the multipath.conf.annotated.gz or if you wish to have a brief config file, multipath.conf.synthetic file for the device and override the values that you want to change.

To add a device to this section of the configuration file that is not configured automatically by default, you must set the vendor and product parameters. You can find these values by looking at /sys/block/

device_name/device/vendor and /sys/block/device_name/device/model where device_name is the device to be multipathed, as in the following example:

# cat /sys/block/sda/device/vendor WINSYS

# cat /sys/block/sda/device/model SF2372

The additional parameters to specify depend on your specific device. If the device is active/active, you will usually not need to set additional parameters. You may want to set path_grouping_policy to multibus.

Other parameters you may need to set are no_path_retry and rr_min_io, as described in Table Multipath Attributes [p. 93].

If the device is active/passive, but it automatically switches paths with I/O to the passive path, you need to change the checker function to one that does not send I/O to the path to test if it is working (otherwise, your device will keep failing over). This almost always means that you set the path_checker to tur; this works for all SCSI devices that support the Test Unit Ready command, which most do.

If the device needs a special command to switch paths, then configuring this device for multipath requires a hardware handler kernel module. The current available hardware handler is emc. If this is not sufficient for your device, you may not be able to configure the device for multipath.

Table 5.5. Device Attributes

Attribute	Description
vendor	Specifies the vendor name of the storage device to which the device attributes apply, for example COMPAQ.
product	Specifies the product name of the storage device to which the device attributes apply, for example HSV110 (C)COMPAQ.
revision	Specifies the product revision identifier of the storage device.
product_blacklist	Specifies a regular expression used to blacklist devices by product.
hardware_handler	Specifies a module that will be used to perform hardware specific actions when switching path groups or handling I/O errors. Possible values include: • 1 emc: hardware handler for EMC storage arrays • 1 alua: hardware handler for SCSI-3 ALUA arrays. • 1 hp_sw: hardware handler for Compaq/HP controllers. • 1 rdac: hardware handler for the LSI/Engenio RDAC controllers.

In addition, the following parameters may be overridden in this device section

• path_grouping_policy

• getuid_callout

• path_selector

• path_checker

• features

• failback

• prio

• prio_args

• no_path_retry

• rr_min_io

• rr_weight

• fast_io_fail_tmo

• dev_loss_tmo

• flush_on_last_del

Whenever a hardware_handler is specified, it is your responsibility to ensure that the appropriate kernel module is loaded to support the specified interface. These modules can be found in /lib/ modules/`uname -r`/kernel/drivers/scsi/device_handler/ . The requisite module should be integrated into the initrd to ensure the necessary discovery and failover-failback capacity is available during boot time. Example,

# echo scsi_dh_alua >> /etc/initramfs-tools/modules ## append module to file

# update-initramfs -u -k all

The following example shows a device entry in the multipath configuration file.

#devices {

# device {

# vendor "COMPAQ "

# product "MSA1000 "

# path_grouping_policy multibus

# path_checker tur

# rr_weight priorities

# }

#}

The spacing reserved in the vendor, product, and revision fields are significant as multipath is performing a direct match against these attributes, whose format is defined by the SCSI specification, specifically the Standard INQUIRY2 command. When quotes are used, the vendor, product, and revision fields will be interpreted strictly according to the spec. Regular expressions may be integrated into the quoted strings.

Should a field be defined without the requisite spacing, multipath will copy the string into the properly sized buffer and pad with the appropriate number of spaces. The specification expects the entire field to be populated by printable characters or spaces, as seen in the example above