Veritas Support of AIX MPIO in conjunction with Veritas Dynamic Multi-Pathing (DMP)

  • Modified Date:
  • Article ID:000088380


This article describes Veritas Support of AIX MPIO in conjunction with Veritas Dynamic Multi-Pathing (DMP).


This article is provided as formal documentation that MPIO interoperability for IBM branded arrays with DMP is supported for the Storage Foundation (SF) and Storage Foundation High Availability (SFHA) 5.1 SP1 releases, as well as 6.0.1 and subsequent releases in relation to specific key requirements being implemented.

In an effort to reduce the interoperability impact and prevent potential data corruption when using MPIO with SF 5.1 SP, Veritas strongly recommends that 5.1 SP1 RP4 or higher be deployed.

Volume Manager (VxVM) configuration and DMP kernel configuration may become corrupt, after device paths are disconnected and reconnected, leading to the possibility of user data corruption



TechAlert (ALERT1490) has also been published highlighting the impact:

NOTE: For SF and SFHA 6.0.x based releases, a minimum of is required for Veritas Volume Manager.

Veritas do not support the same enclosure being claimed by MPIO as well as DMP.
This means you cannot have a subset of devices in the array being controlled by MPIO, and the remainder of the devices from the same array being controlled by DMP.
The entire array should be controlled by a single multi-pathing driver, either by DMP or by MPIO (if an IBM branded array).

If the array is controlled by MPIO, then DMP will work in pass through mode.
With MPIO, DMP sees just one path, whilst MPIO is solely responsible for managing and controlling the underlying paths to the LUN.

Since MPIO works at a "storage model" granularity level (Product ID), specific IBM limitations need to be explained:

- Even where there are separate enclosures with the same array model, the user needs to choose a single multi-pathing solution, DMP or MPIO.
- Even if the same enclosure models are presented by the same HBA or different HBAs, the user still needs to choose a single mult-pathing solution, DMP or MPIO.

NOTE: Due to IBM limitations, MPIO can only be disabled at a Product ID (PID) level.

Veritas provides support if you run AIX MPIO in conjunction with Veritas Dynamic multi-pathing (DMP) as outlined in the configuration requirements above. DMP is included with Storage Foundation and is the preferred multi-pathing solution for device presentation. DMP is thoroughly tested with all arrays in the Hardware Compatibility List (HCL). Check the HCL to confirm the supportability standpoint for a given array.

Things to be considered when deploying MPIO in relation to Storage Foundation:

IBM only tested interoperability of MPIO functionality with IBM branded storage and the Veritas product stack. Simple co-existence and basic functionality testing has been validated by Veritas in relation to MPIO with IBM branded storage arrays only.

All other non-branded IBM arrays are NOT qualified by Veritas in connection with MPIO as the multi-pathing driver with the SF and SFHA product stack.

Veritas strongly recommends using DMP for multi-pathing whenever possible because a system running the full Storage Foundation stack is inherently simpler to configure, manage, and troubleshoot than a system running Storage Foundation and a third party multi-pathing driver.

Software Limitations:

- Storage Foundation and Storage Foundation HA on AIX with MPIO managed IBM storage only is supported, however, not with SCSI-3 Persistent Reservation fencing.

- SCSI-3 Persistent Reservation fencing is NOT supported when MPIO is operating beneath DMP.

- SCSI-3 reservations created outside the vxfen driver are NOT supported.

- The Thin Reclamation feature in Storage Foundation is NOT supported with MPIO.

- SCSI-3 Persistent Reservation fencing is ONLY supported with DMP and the vxfen driver (EMC PowerPath exception listed below).

- SCSI-3 Persistent Reservation fencing is ONLY supported with EMC PowerPath and the vxfen driver when used in connection with EMC storage arrays.

- Storage Foundation for Oracle RAC is NOT supported with MPIO due to fencing limitations.

- The DMP dmp_monitor_osevent tunable be disabled with DMP and MPIO (where MPIO is managing SAN data disks).

- The DMP dmp_fast_recovery tunable must be disabled with DMP and MPIO (where MPIO is managing SAN data disks).

- DMP extended (advanced) device attributes are NOT exposed when using MPIO or any other Third-Party multi-pathing driver.

- Turn off persistent naming when using MPIO (where MPIO is managing SAN data disks).

# vxddladm set namingscheme=osn persistence=no


DMP tunables:

The DMP dmp_fast_recovery tunable controls whether DMP should attempt to obtain SCSI error information directly from the HBA interface (whereby DMP will bypass the sd/scsi stack and send path inquiry/status CDBs directly from the HBA in order to bypass long SCSI queues and recover paths faster) . Setting the value to "on" can potentially provide faster error recovery, provided that the HBA interface supports the error enquiry feature. If set to off, the HBA interface is not used. The default setting is on.

The recommendation to turn off the DMP dmp_fast_recovery tunable in configurations involving MPIO was based on the fact that MPIO is different from EMC PowerPath (PP) as MPIO integrates with the AIX related drivers and exposes only a single OS device path for DMP to operate on.

EMC PowerPath (PP) is a path non-suppressing  multipathing driver whereby the OS and DMP will see the special PP (emcpower#) pseudo device and the corresponding OS device paths (handles). DMP operates on the PP managed "pseudo" device which then in turn operates on the OS device paths. When DMP detects the presence of a PP managed device, it automatically turns off the "dmp_fast_recovery" tunable. This is not the case for MPIO managed devices.

Veritas Volume Manager (VxVM) 5.1 SP1 introduced a new DMP tunable named  "dmp_monitor_osevent" to reduce past interoperability issues with the SF stack and Third Party Drivers (TPD) such as MPIO, MPxIO and EMC PowerPath.

Veritas previously advised customers to disable the eventsource daemon (vxesd) in connection with TPD environments. The eventsource daemon should no longer be disabled as both DMP tunables should be disabled when Third Party Drivers are managing SAN related storage devices.

The DMP "dmp_monitor_osevent" tunable determines whether the eventsource daemon (vxesd) monitors operating system events such as reconfiguration operations.

- If the DMP tunable is set to on, vxesd monitors operations such as attaching operating system devices.
- If the DMP tunable is set to off, vxesd does not monitor operating system operations.

Symantec strongly recommends disabling the "dmp_monitor_osevent" tunable to avoid known interoperability issues with MPIO and EMC PowerPath.

To disable the DMP tunables "dmp_fast_recovery" and "dmp_monitor_osevent", type:
# vxdmpadm settune dmp_fast_recovery=off
# vxdmpadm settune dmp_monitor_osevent=off

The DMP tunable settings can be displayed by using the vxdmpadm CLI interface:

# vxdmpadm gettune all


How to disable persistence naming

# vxddladm set namingscheme=osn persistence=no

# vxddladm get namingscheme

OS Native           No             Yes            Yes

Note: Veritas strongly recommends IO fencing for Storage Foundation Cluster File System to guard against the risk of data corruption.

Terms of use for this information are found in Legal Notices.



Did this article answer your question or resolve your issue?


Did this article save you the trouble of contacting technical support?


How can we make this article more helpful?

Email Address (Optional)