Multipath Blacklisting Local Disks

This document (3970086) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 10
SUSE Linux Enterprise Server 9
 

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.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:3970086
  • Creation Date: 05-Oct-2007
  • Modified Date:15-Mar-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center