Symantec Support of Solaris MPxIO in conjunction with Symantec Dynamic Multi-Pathing (DMP)
|Article:TECH204060|||||Created: 2013-03-19|||||Updated: 2014-03-27|||||Article URL http://www.symantec.com/docs/TECH204060|
This article describes Symantec Support of Solaris MPxIO in conjunction with Symantec Dynamic Multi-Pathing (DMP).
This article is provided as formal documentation that MPxIO interoperability with DMP is supported for the Storage Foundation 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 MPxIO with SF 5.1 SP1, Symantec strongly recommends that 5.1 SP1 RP3 or higher be deployed. A special customized post-install script has been developed for SF 5.1 SP1 RP3 and SF 5.1 SP1 RP3 P2 installations. Please refer to the following article for details:
- Installation of Veritas Volume Manager (VxVM) 5.1 SP1 RP3 patch and above in Alternate Boot Environment (ABE) are susceptible to corruption when used with Third Party Drivers (TPD) like MPxIO
- A Symantec TechAlert ( AL1440 ) has also been published highlighting the interoperability impact
Symantec provides support if you run Solaris MPxIO in conjunction with Symantec 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 listed in the Symantec Hardware Compatibility List (HCL). Check the HCL to confirm the supportability standpoint for a given array.
Things to be considered before deploying MPxIO in relation to Storage Foundation:
Sun/Oracle only tested the interoperability of MPxIO functionality with Sun/Oracle branded storage arrays during the Veritas Storage Foundation (SF) 5.1 releases. Other specific array certification should be verified with Sun/Oracle prior to using MPxIO. Non Sun/Oracle branded storage arrays have not been tested with the Veritas Storage Foundation (SF) 5.1 releases.
When considering to deploy MPxIO in relation to Storage Foundation (SF) 6.0.1 onwards, please kindly note that Symantec only validated the MPxIO solution in relation to simple coexistence and basic functionality testing with some common array types. In the event that interoperability issues should arise in relation to the coexistence between DMP and MPxIO, Symantec will assist Sun/Oracle with troubleshooting such events. If Symantec identifies the issue as being out of Symantec's control, Symantec will provide the necessary information to reproduce the error to the appropriate third party. In the situation where interoperability issues arise that require code modification or patches to third party products, it is at the third party's discretion to implement any such recommendations or required changes.
To determine the source of any defect, you might be requested/required to recreate any issue without MPxIO in the stack to confirm that the issue occurs independent of MPxIO interoperability. Symantec will provide commercially reasonable effort to support such implementations which may be encountered by MPxIO related deployments, but assumes no liability for any user data impacted by the use of MPxIO.
This statement of support is applicable only to Storage Foundation and Storage Foundation High Availability (SFHA).
- SCSI-3 Persistent Reservation fencing is supported only with DMP and the vxfen driver.
- SCSI-3 Persistent Reservation fencing is not supported when MPxIO is operating beneath DMP, and SCSI-3 reservations created outside the vxfen driver are not supported.
- Storage Foundation for Oracle RAC is not supported due to fencing limitations.
- The DMP dmp_fast_recovery tunable must be disabled with DMP and MPxIO.
- The DMP dmp_monitor_osevent tunable must be disabled with DMP and MPxIO.
- Turn off persistent naming when using MPxIO (vxddladm set namingscheme=osn persistence=no)
- The Thin Reclamation feature in Storage Foundation is not supported with MPxIO
- Advanced Reporting is only supported with DMP (See TECH51507)
- DMP Array Volume Identifier (AVID) naming is only supported with DMP when no other third party multipathing (TPD) manages the disk.
- SF 5.1 SP1 RP3 (P2 recommended) is required to minimize data corruption interoperability events surrounding Dynamic LUN add/remove operations (See TECH180703 and TECH158119)
- Volume Manager configurations involving Third Party Drivers (TPD) like MPxIO are susceptible to corruption on executing "vxddladm assign names".
- LUN addition followed by a "vxdctl enable" operation can cause data corruption when Volume Manager's (VxVM) configuration daemon, vxconfigd, is migrating disk-access names (DANAME) with simultaneous active I/O on the devices
- On Solaris configurations affected by Sun Bug ID 6680575, Storage Foundation High Availability on MPxIO devices with Sun/Oracle Active/Passive storage hardware is not supported.
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 MPxIO was based on the fact that MPxIO is different from EMC PowerPath (PP) as MPxIO integrates with the SUN SCSI driver (ssd) 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 MPxIO 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 MPxIO and EMC PowerPath. Symantec previously advised customers to disable the eventsource daemon (vxesd) in connection with TPD environments. This is no longer required as long as both DMP tunables are disabled in TPD environments.
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 MPxIO 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
MPxIO managed devices will default to enclosure based naming as the OSN name exceeds 31 characters.
Article URL http://www.symantec.com/docs/TECH204060