Concept and mechanism
DM Multipath creates a logical device above component paths. The application or upper layer should use the appropriate device in the design instead of becoming tied to an isolated sdX. Otherwise, it can bypass the mechanism selecting alternatives when a path fails. Do not assume mpatha means the same LUN on different hosts: friendly names and aliases require explicit consistency confirmed through WWID. The multipath -ll command presents group and path states that need contextual interpretation. A single field does not summarize availability, optimization, and whole-device state. Maintain a reference for expected state per LUN.
Guided application
In an ONTAP local-active design, active-non-optimized does not mean failed. Configuration and version determine the role of those paths. The specific support matrix should guide the runbook because broad statements about LIF failover have exceptions. If every path fails, queue_if_no_path can keep I/O pending. This does not establish write persistence. A numeric no_path_retry value represents failed-check counts, not guaranteed seconds. Coordinate these policies with application timeouts and recovery. After editing multipath.conf, validate configuration and confirm effective state following controlled application; saving the file does not establish that the daemon has loaded the change.
no_path_retry=5 is not a guarantee of an error returned after five seconds.
Common pitfalls
Global alias by default; non-optimized as faulty; waiting as success; edited file as active configuration.
Related topics: Topology and identity · Fibre Channel and LUN access · iSCSI: sessions and security
Interpret state and policy according to implementation and required application behavior.
Reference: RHEL 9 DM Multipath: topology, identity, queue policy, resize and safe removal · DR SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior