Storage Foundation for Windows DMP Device Specific Module returns a bogus path during a path failover operation
Problem
Storage Foundation for Windows (SFW) Dynamic Multi-Pathing (DMP) Device Specific Module (DSM) returns a bogus path during a path failover operation
If a path fails or is removed during I/O, DMP DSM may return a bogus path which causes IO to the Volume to fail.
Error Message
Log Name: System
Source: mpio
Date: DD/MM/YYYY HH:MM:SS
Event ID: 33
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: HOSTNAME
Description:
DSM NAME returned a bogus Path to \Device\MPIODisk5.
Cause
DMP DSM uses the DsmInvalidatePath API from the Microsoft MPIO framework. In the event of a path failure, a surviving path is returned without knowledge of which specific disks have a path that is being removed. If the disks therefore share some paths and not other paths, there is a possibility that a disk may be given a path that does not belong to it.
Solution
- If a disk shares any paths with another disk in the same array, they must share exactly the same paths.
- If a disk does not share a path with a disk in the same array, then they must not share any paths.
That is, they must either share all paths, or share no paths. This is known as a share-all or share-nothing configuration.
Harddisks1-5: Paths 1-5
Harddisks6-10: Paths 6-10
For vemcsymm: This fix has been included in the latest DDI packages for 5.1 Sp1 and all later versions. Please see the related articles for details on how to find the latest DDI packages.
For vhdsaa: A private fix has been created which addresses this problem for version 6.0 and higher. Please contact support and a support representative will further assist in obtaining the private fix. For a complete list of Veritas Enterprise Technical Support contact numbers, go to https://www.veritas.com/enterprise/support/index.jsp
Disclaimer: This fix specifically addresses the problem identified above. It has not been fully tested and should be applied in a test environment before placing into production. If the systems are not critically impaired, it is recommended to delay the installation of this private fix until the next scheduled maintenance release. Before applying this private fix, systems may be required to be upgraded to the latest code base. The support representative will help in determining the best course of action.
Note:
The above fixes do not remove the requirement for shared-all or shared-none pathing for non-control devices.
Applies To
SFW with DMP
- There are disks within the same array which have a different number of paths.
- There are disks within the same array which have some paths in common, but not all paths in common.
For example:
* Harddisk1 has 2 paths to the array, denoted 1-0-0, 2-0-0.
* Harddisk2 has 4 paths to the array, denoted 1-0-0, 2-0-0, 1-0-1, 2-0-1.
In this case, Harddisk1 and Harddisk2 share two paths, but Harddisk2 also has two paths that are not shared with Harddisk1.
References
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.