Multipath Blacklisting Local Disks

  • 3970086
  • 05-Oct-2007
  • 22-Apr-2014

Environment

Novell SUSE Linux Enterprise Server 9
Novell SUSE Linux Enterprise Server 10
Novell SUSE Linux Enterprise Server 11
Novell Open Enterprise Server (Linux based)
Novell Open Enterprise Server 2 (Linux based)

Situation

Multipath is not ignoring my local disks when it creates its multipath maps

Resolution

The default blacklist in /etc/multipath.conf is not sufficient and will look somewhat like this below

blacklist { devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][0-9]*"
devnode "^cciss!c[0-9]d[0-9].*"
}

The first line blacklists devices which should not normally be managed by multipath. This is correct for most systems and should not require modification. The second and third devnode lines commonly require modification.

The second devnode line blacklists typical IDE (PATA) disks and partitions. If the local disks are PATA (as opposed to SATA or SCSI), this entry should be kept to ensure these disks are not managed by multipath.

The third devnode line is used to blacklist HP Smart Array Controller SA5xxx or SA6xxx devices (cciss). On HP hardware using this type of controller, this blacklist is important as multipath can assume control of these devices and cause difficulty booting.  With the move to libudev the cciss device links have changed .  Please use devnode "^cciss.c[0-9]d[0-9].*" for blacklisting.  And if anything the blacklist is wrong, even for SP2. cciss device nodes (and that is what the 'devnode' property matches on)  always  has been of the form /dev/cciss/cXdYpZ.  The '!' syntax is only to be found in sysfs, so it would only work if matching  against the sysfs path.

In the event that the server has a local SATA or SCSI controller, the local disks will typically be named 'sda' or 'sdb'. In this case, the naming of these devices matches the names normally assigned to LUNs on a SAN - which multipath should manage. In order to distinguish between local 'sd*' devices and 'sd*' devices on a SAN, the blacklist syntax is important:

devnode "sd[a-b]$"

In the above example, a regular expression is used to blacklist all devices that end in 'sda' or 'sdb'. This will effectively blacklist only /dev/sda and /dev/sdb. Importantly, this syntax will NOT blacklist /dev/sdaa, /dev/sdab, etc., which could be valid disk devices if the server is connected to a large number of LUNs. The above syntax can be modified to just 'sda$', or include additional local disks if they exist. Please note that using the syntax of 'sd[a-b]' or 'sd[a-b][0-9]' can still result in 'sdaa' type of devices being blacklisted. The '$' ensures only devices ending with the specified name will be blacklisted.

In addition to the above examples, a final method of blacklisting device is by specifying the appropriate vendor and product, as in the following example:

blacklist { device {
vendor DELL
product Perc*
}
}

The correct vendor and product names can be found in the output of `lsscsi`.

Before restarting the server, or multipath daemon, verify the blacklist using `multipath -v3 -d`. The output shows which devices are blacklisted and the layout which will be used for the MPIO maps. Once the output is verified, the multipath daemon can be restarted and the blacklisting should take effect. If existing MPIO maps are in use, the server may need to be restarted. NOTE - If multipath is in the initrd (typically when booting from a SAN), the initrd should be rebuilt using `mkinitrd` to ensure the new multipath.conf is added to the initrd.

Change Log

2012-06-15 - Mike Latimer - Added additional clarifying comments, and corrected cciss blacklist syntax
2011-03-17 - Sascha Wehnert - fixed blacklist option according to storage admin guide