Use the guidelines in this section when planning your multipath I/O solution.
Multipathing is managed at the device level.
The storage array you use for the multipathed device must support multipathing. For more information, see Section 5.2.8, “Supported Storage Arrays for Multipathing”.
You need to configure multipathing only if multiple physical paths exist between host bus adapters in the server and host bus controllers for the block storage device. You configure multipath for the logical device as seen by the server.
For some storage arrays, the vendor will provide its own multipathing software to manage multipathing for the array’s physical and logical devices. In this case, you should follow the vendor’s instructions for configuring multipathing for those devices.
Perform the following disk management tasks before you attempt to configure multipathing for a physical or logical device that has multiple paths:
Use third-party tools to carve physical disks into smaller logical disks.
Use third-party tools to partition physical or logical disks. If you change the partitioning in the running system, the Device Mapper Multipath (DM-MP) module does not automatically detect and reflect these changes. DM-MP must be reinitialized, which usually requires a reboot.
Use third-party SAN array management tools to create and configure hardware RAID devices.
Use third-party SAN array management tools to create logical devices such as LUNs. Logical device types that are supported for a given array depend on the array vendor.
The Linux software RAID management software runs on top of multipathing. For each device that has multiple I/O paths and that you plan to use in a software RAID, you must configure the device for multipathing before you attempt to create the software RAID device. Automatic discovery of multipathed devices is not available. The software RAID is not aware of the multipathing management running underneath.
High-availability solutions for clustering typically run on top of the multipathing server. For example, the Distributed Replicated Block Device (DRBD) high-availability solution for mirroring devices across a LAN runs on top of multipathing. For each device that has multiple I/O paths and that you plan to use in a DRDB solution, you must configure the device for multipathing before you configure DRBD.
Volume managers such as LVM2 and EVMS run on top of multipathing. You must configure multipathing for a device before you use LVM2 or EVMS to create segment managers and file systems on it.
If you want to use the entire LUN directly (for example, if you are using the SAN features to partition your storage), you can simply use the /dev/disk/by-id/xxx names directly for mkfs, fstab, your application, etc.
If the user-friendly names option is enabled in the /etc/multipath.conf file, you can optionally use the /dev/mapper/mpathn device name because this name is aliased to the devices ID. For information, see Section 5.4.5.3, “Configuring User-Friendly Names or Alias Names in /etc/multipath.conf”.
By default, LVM2 does not recognize multipathed devices. To make LVM2 recognize the multipathed devices as possible physical volumes, you must modify /etc/lvm/lvm.conf. It is important to modify it in a way that it does not scan and use the physical paths, but only accesses the multipath I/O storage through the multipath I/O layer.
To modify /etc/lvm/lvm.conf for multipath use:
Open the /etc/lvm/lvm.conf file in a text editor.
Change the filter and types entry in /etc/lvm/lvm.conf as follows:
filter = [ "a|/dev/disk/by-id/.*|", "r|.*|" ]
This allows LVM2 to scan only the by-id paths and reject everything else.
If you are also using LVM2 on non-multipathed devices, make the necessary adjustments to suit your setup.
Save the file.
Add dm-multipath to /etc/sysconfig/kernel:INITRD_MODULES.
Make a new initrd to ensure that the Device Mapper Multipath services are loaded with the changed settings. Enter
mkinitrd -f mpath
Reboot the server to apply the changes.
The mdadm tool requires that the devices be accessed by the ID rather than by the device node path. Therefore, the DEVICE entry in /etc/mdadm.conf should be set as follows:
DEVICE /dev/disk/by-id/*
This is the default handling in SUSE Linux Enterprise Server 10 and later.
The option --noflush should always be used when running on multipath devices.
For example, in scripts where you perform a table reload, you use the --noflush option on resume to ensure that any outstanding I/O is not flushed, because you need the multipath topology information.
load resume --noflush
In SUSE Linux Enterprise Server 10, the kpartx software is used in the /etc/init.d/boot.multipath to add symlinks to the /dev/dm-* line in the multipath.conf configuration file for any newly created partitions without requiring a reboot. This triggers udevd to fill in the /dev/disk/by-* symlinks. The main benefit is that you can call kpartx with the new parameters without having to reboot the server.
In SUSE Linux Enterprise Server 9, it is not possible to partition multipath I/O devices themselves. If the underlying physical device is already partitioned, the multipath I/O device reflects those partitions and the layer provides /dev/disk/by-id/<name>p1 ... pN devices so you can access the partitions through the multipath I/O layer. As a consequence, the devices need to be partitioned prior to enabling multipath I/O. If you change the partitioning in the running system, DM-MP does not automatically detect and reflect these changes. The device must be reinitialized, which usually requires a reboot.
The multipathing drivers and tools in SUSE® Linux Enterprise Server 10 support all seven of the supported processor architectures: IA32, AMD64/EM64T, IPF/IA64, p-Series (32-bit/64-bit), z-Series (31-bit and 64-bit).
The multipathing drivers and tools in SUSE Linux Enterprise Server 10 support most storage arrays. The storage array that houses the multipathed device must support multipathing in order to use the multipathing drivers and tools. Some storage array vendors provide their own multipathing management tools. Consult the vendor’s hardware documentation to determine what settings are required.
The multipath-tools package automatically detects the following storage arrays:
| 3PARdata VV |
| Compaq* HSV110 |
| Compaq MSA1000 |
| DDN SAN MultiDirector |
| DEC* HSG80 |
| EMC* CLARiiON* CX |
| EMC Symmetrix |
| FSC CentricStor* |
| Hewlett Packard* (HP*) A6189A |
| HP HSV110 |
| HP HSV210 |
| HP Open- |
| Hitachi* DF400 |
| Hitachi DF500 |
| Hitachi DF600 |
| IBM* 3542 |
| IBM ProFibre 4000R |
| NetApp* |
| SGI* TP9100 |
| SGI TP9300 |
| SGI TP9400 |
| SGI TP9500 |
| STK OPENstorage DS280 |
| Sun* StorEdge 3510 |
| Sun T4 |
In general, most other storage arrays should work. When storage arrays are automatically detected, the default settings for multipathing apply. If you want non-default settings, you must manually create and configure the /etc/multipath.conf file. For information, see Section 5.4.5, “Creating and Configuring the /etc/multipath.conf File”.
Hardware that is not automatically detected requires an appropriate entry for configuration in the DEVICES section of the /etc/multipath.conf file. In this case, you must manually create and configure the configuration file. For information, see Section 5.4.5, “Creating and Configuring the /etc/multipath.conf File”.
Consider the following caveats:
Not all of the storage arrays that are automatically detected have been tested on SUSE Linux Enterprise Server. For information, see Section 5.2.8.2, “Tested Storage Arrays for Multipathing Support”.
Some storage arrays might require specific hardware handlers. A hardware handler is a kernel module that performs hardware-specific actions when switching path groups and dealing with I/O errors. For information, see Section 5.2.8.3, “Storage Arrays that Require Specific Hardware Handlers”.
After you modify the /etc/multipath.conf file, you must run mkinitrd to re-create the INITRD on your system, then reboot in order for the changes to take effect.
The following storage arrays have been tested with SUSE Linux Enterprise Server:
| EMC |
| Hitachi |
| Hewlett-Packard/Compaq |
| IBM |
| NetApp |
| SGI |
Most other vendors’ storage arrays should also work. Consult your vendor’s documentation for guidance. For a list of the default storage arrays recognized by the multipath-tools package, see Section 5.2.8.1, “Storage ArraysThat Are Automatically Detected for Multipathing”.
Storage arrays that require special commands on failover from one path to the other or that require special nonstandard error handling might require more extensive support. Therefore, the Device Mapper Multipath service has hooks for hardware handlers. For example, one such handler for the EMC CLARiiON CX family of arrays is already provided.
![]() | |
Consult the hardware vendor’s documentation to determine if its hardware handler must be installed for Device Mapper Multipath. | |
The multipath -t command shows an internal table of storage arrays that require special handling with specific hardware handlers. The displayed list is not an exhaustive list of supported storage arrays. It lists only those arrays that require special handling and that the multipath-tools developers had access to during the tool development.
![]() | |
Arrays with true active/active multipath support do not require special handling, so they are not listed for the multipath -t command. | |
A listing in the multipath -t table does not necessarily mean that SUSE Linux Enterprise Server was tested on that specific hardware. For a list of tested storage arrays, see Section 5.2.8.2, “Tested Storage Arrays for Multipathing Support”.