Understanding find_multipaths in OpenStack

In OpenStack deployments, block storage is the foundation for running virtual machines reliably. Whether using iSCSI, Fibre Channel, or NVMe-backed arrays, consistent device identity is critical. Misconfigured multipathing can cause transient device names, failed volume attachments, and confusion across compute nodes.

One Linux multipathing setting often misunderstood in this context is find_multipaths. It controls how the multipath daemon detects and maps storage devices, with significant implications for OpenStack operations.

What is find_multipaths?

The find_multipaths option in /etc/multipath.conf determines how multipath responds when new block devices are discovered:

Option	Behavior in OpenStack	Recommended Use
strict / false	Only maps devices explicitly defined in multipath.conf. `/dev/mapper/mpathX` is stable from first detection.	✅ Production – deterministic, predictable failover, aligns with vendor best practices.
greedy	All non-blacklisted devices treated as multipath paths. `/dev/sdX` may appear briefly before `/dev/mapper/mpathX`. Device names may flip during failures.	⚠️ Avoid in production – timing-dependent, can break volume attachments.
on	Device mapped if ≥2 paths exist or if a multipath device existed before. Heuristic behavior.	⚠️ Lab environments only – better than greedy but still non-deterministic.
smart	Maps all non-blacklisted devices initially. Releases device if a second path doesn’t appear within `find_multipaths_timeout`.	⚠️ Lab/test only – can cause transient identity exposure.
off	Static mapping like `strict`, but multipathd may attempt dynamic discovery for previously seen devices.	⚠️ Rarely used; generally unnecessary.

OpenStack relies on stable /dev/mapper/mpathX names for volume attach/detach operations. Choosing the right find_multipaths value ensures predictable behavior during boot, path discovery, and failure events.

Heuristic vs Deterministic Multipathing

Multipath Timeline by Option

Timeline showing behavior of find_multipaths options (greedy, on, smart, strict, off) during boot, path discovery, and path failure/recovery for a single external LUN with two paths. Solid lines represent stable /dev/mapper/mpathX devices; dashed lines represent transient /dev/sdX exposure. Arrows indicate path discovery, failures, and recovery events. Color-coded: green = stable, yellow = temporary, red = risky.

Description:

This timeline compares all find_multipaths options:

Greedy: All non-blacklisted devices are treated as multipath paths. /dev/sdX may appear before /dev/mapper/mpathX, and device names can flip during failures.
On: Maps devices if ≥2 paths exist or if the device was previously mapped. Timing-dependent.
Smart: Maps all non-blacklisted devices initially; releases device if a second path doesn’t appear within timeout. Transient identity exposure possible.
Strict / False: Only explicitly defined devices are mapped. /dev/mapper/mpathX is stable immediately. Recommended for OpenStack production.
Off: Like strict for static mapping, but multipathd may attempt dynamic discovery. Rarely used.

Takeaway: Only strict/false guarantees deterministic device names and predictable failover.

Conceptual Multipath Flow

Abstract illustration showing multiple servers connected to a central multipath device representing an external storage array. Green lines = stable mapped paths, yellow/red lines = transient or unstable paths. Arrows indicate path discovery, failures, and recovery events. Background shows cloud to represent OpenStack context.

Description:

This abstract featured image conveys multipath flow in a data center:

Multiple servers connect to a central multipath device representing the storage array.
Green paths indicate stable, fully mapped connections (aligned with strict/false).
Orange/red paths show transient or potentially unstable paths, which occur under heuristic discovery (greedy/on/smart).
Arrows illustrate flow direction, and warning symbols highlight potential path failures.
The cloud in the background reinforces the OpenStack context.

Do You Need to Define Every WWID?

While defining WWIDs in multipath.conf guarantees stable /dev/mapper/mpathX names, in a real OpenStack deployment this is rarely practical.

Why:

Volumes are dynamic – Cinder creates and attaches new LUNs on-demand. These external LUNs appear in an ad-hoc fashion across compute nodes. Attempting to predefine every WWID would be operationally impossible.
Automation handles mapping – With find_multipaths false / strict and proper blacklisting, multipath automatically maps new LUNs reliably. OpenStack attaches volumes by WWID or Cinder ID, so manual configuration is unnecessary.
Safety net via blacklisting – Local disks and irrelevant devices are ignored, preventing accidental mapping conflicts.

Key takeaway:

Explicit WWID definitions are ideal only in tightly controlled or regulatory environments.
For practical OpenStack operations, relying on multipath defaults with blacklisting ensures deterministic, reliable device mapping without manual WWID management.

Why OpenStack Uses find_multipaths false / strict

Deterministic mapping: Only explicitly defined WWIDs are mapped; volumes consistently appear as /dev/mapper/mpathX.
Predictable failover: Path selection follows storage vendor ALUA recommendations.
Safe automation: Orchestration, monitoring, and volume attach/detach scripts can rely on stable devices.
Immediate error detection: Missing or misconfigured paths are immediately visible, rather than silently masked by heuristics.

TL;DR

Heuristic discovery (greedy/on/smart): Convenient but risky; transient raw devices may appear, and device names can flip.
Explicit discovery (strict/false): Deterministic, stable /dev/mapper/mpathX devices, predictable failover. Recommended for production OpenStack deployments.

Multipathing may seem minor, but it has outsized effects on cloud storage reliability. Pairing deterministic multipath configuration with OpenStack orchestration ensures volumes are stable, predictable, and aligned with enterprise storage best practices.