How to Configure DM-Multipath on SLES 15: A Practical Guide

Choose the right multipathing stack first

On SUSE Linux Enterprise Server 15, Device Mapper Multipath (DM-Multipath) is the standard choice for SCSI and DASD storage presented through multiple paths. It combines matching paths to one logical block device, monitors path health, and can fail over between path groups. It protects the connection to a storage volume; it does not protect against a failed volume, controller data loss, or a damaged filesystem.

NVMe uses a different default: SLES 15 enables native NVMe multipathing in the kernel. For NVMe over Fabrics, confirm that native NVMe multipathing is the intended stack for your subsystem before following a DM-Multipath procedure. SUSE recommends native NVMe multipathing and says using DM-Multipath for NVMe is not recommended. See SUSE’s SLES 15 SP7 multipath guide and its NVMe over Fabrics guide.

Before you change the host

• Confirm that the storage array, HBA or network transport, and SLES release are supported together. Follow the array vendor’s Linux multipathing settings where they differ from generic defaults.
• Have the storage administrator present the LUN to the host through the intended fabrics and confirm zoning and LUN masking.
• Record the current boot and storage layout. Identify whether the root filesystem, swap, or an LVM physical volume is on SAN storage.
• Do not mount, format, add to LVM, or write to each individual path device. The same LUN must be used through its multipath map only; using the raw paths at the same time can corrupt data.
• Arrange console or out-of-band access before changing a SAN boot configuration. A mismatch between the running system and initramfs can leave a host in emergency mode.

1. Confirm that Linux sees the storage paths

First confirm that the HBA or iSCSI transport has logged in and that SLES sees the expected block devices. For SCSI storage, inspect the devices and their identifiers:

sudo lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL

This inventory confirms whether the expected LUN-sized block devices are visible. At this stage, do not assume separate device names prove separate storage volumes: the next steps check their WWIDs and group matching paths.

If the expected paths are absent, stop here and resolve discovery first. Check HBA visibility, iSCSI sessions or Fibre Channel login, SAN zoning, LUN masking, and the storage vendor’s rescan procedure. Multipath cannot create paths that the transport layer does not expose.

2. Install and start the multipath service

Install the SUSE package if it is not already present, then enable the daemon so maps are assembled at boot:

sudo zypper install multipath-tools
sudo systemctl enable --now multipathd
sudo systemctl status multipathd

The multipath-tools package supplies the multipath command-line tools and the multipathd service. SUSE recommends keeping the service enabled and running on systems with multipath hardware; relying only on systemd socket activation can leave maps unset during boot. Once the daemon is active, compare the WWIDs and path identities:

sudo multipathd show paths format "%i %d %w %s"
sudo multipath -ll

Paths to the same LUN must report the same WWID. Different WWIDs represent different devices and must not be merged into one map.

For many arrays, the built-in hardware defaults are sufficient. Do not create a large configuration file merely to turn on multipathing.

3. Add only a needed configuration override

Use /etc/multipath.conf only when you have a concrete requirement, such as a stable friendly alias or a vendor-directed setting. The multipath tools identify paths by WWID; a map alias is a separate, configurable name. A per-device alias can be configured like this:

multipaths {
    multipath {
        wwid 3600EXAMPLE_REPLACE_WITH_THE_REAL_WWID
        alias appdata01
    }
}

Replace the sample WWID with the exact identifier reported for the LUN. Do not copy the placeholder or invent a vendor/product rule. SUSE advises keeping the configuration minimal, and the storage vendor should supply any array-specific tuning. Built-in device properties can take precedence over generic values in the defaults section, so a generic default may not change the behavior of a particular array.

If you need a full reference template, SUSE documents the multipath -T generator. For example, a root shell can save it with sudo sh -c 'multipath -T > /etc/multipath.conf'. That template contains many directives; review it and retain only settings you intend to manage.

4. Test and apply the configuration

Before changing live maps, ask multipath to show the topology it would create with the proposed settings:

sudo multipath -d -v2

Review the WWID and path grouping before proceeding. This dry run shows proposed maps, but it does not show every map that might be removed or flushed. If the daemon is already running, apply configuration through the daemon rather than using the standalone multipath command to apply new settings:

sudo multipathd reconfigure

Then inspect the live result with sudo multipath -ll or sudo multipathd show topology. The SUSE guide notes that these views normally show the same topology; one reads kernel state and the other daemon state.

5. Keep initramfs in sync

After changing /etc/multipath.conf, the WWIDs or bindings files, related configuration, or udev rules that affect device identification, rebuild initramfs:

sudo dracut -f

SUSE requires the booted system and initramfs to behave consistently with respect to multipathing. This is especially important when the root filesystem is on a SAN multipath device. Before rebooting a SAN-booted host, verify that the intended map is visible and that the configuration includes the necessary storage support. If rebuilding initramfs from a rescue environment or after booting with multipath disabled, follow SUSE’s explicit dracut --add multipath or --omit multipath procedure rather than assuming autodetection will match the normal boot.

6. Verify the map before using it

A healthy map should show the expected WWID, vendor/product identity, path groups, and individual paths. In the path status columns, active indicates the kernel path state, ready indicates a healthy multipath path, and running is the SCSI device state. Arrays with active/passive controllers can also show passive paths as ghost; interpret that state using the array’s path policy rather than treating it automatically as a fault.

Use the multipath map or a persistent by-id reference in later storage configuration. Do not place filesystems, LVM, or application data on an individual /dev/sdX path. A stable reference can be based on the map WWID under /dev/mapper or the corresponding /dev/disk/by-id/dm-uuid-mpath-WWID link. Avoid assuming an alias such as mpatha will remain assigned unless you deliberately configure it.

Quick reference

Troubleshooting when a map is missing or unhealthy

• No paths appear: confirm the transport login, HBA discovery, zoning, LUN masking, and kernel device discovery before editing multipath rules.
• A LUN appears as separate disks: compare WWIDs. If they differ, confirm that the storage has presented the intended same LUN through each path. If they match but no map appears, check daemon status and the device-selection policy.
• One path is faulty or offline: check the cable or fabric, HBA port, switch port, target controller, and array event logs. Do not tune polling or failure timers without the storage vendor’s guidance.
• The host enters emergency mode after a boot change: investigate inconsistent multipath selection and device references, then use the SUSE recovery procedure for the root device and initramfs.
• I/O stalls when all paths fail: queued I/O can keep applications waiting. Treat queueing policy as an operational decision with the storage and application owners; changing it can turn waiting writes into reported I/O errors.

Do not test failover by disconnecting a production path without a maintenance plan and vendor-approved procedure. Confirm recovery through supported monitoring and a controlled test window. For array-specific defaults and recovery steps, use the hardware vendor’s current documentation alongside SUSE’s multipath configuration, verification, and troubleshooting reference.