The EMC array setting called the SPC-2 bit impacts how LUN Serial Numbers (LSN) are presented on a EMC Symmetrix port.  If this setting differs between two ports on a system, VxVM will fail to multi-path the LUNs correctly.

# vxdisk -o alldgs list
DEVICE       TYPE            DISK         GROUP        STATUS
c2t50060482D530C8A7d0s2 auto:cdsdisk    -         (datadg) online udid_mismatch
c2t50060482D530C8A7d1s2 auto:cdsdisk    -         (datadg) online udid_mismatch
c2t50060482D530C8A7d2s2 auto:cdsdisk    -         (datadg) online udid_mismatch
c3t50060482D530C8A8d0s2 auto:cdsdisk    datadg01  datadg   online
c3t50060482D530C8A8d1s2 auto:cdsdisk    datadg02  datadg   online
c3t50060482D530C8A8d2s2 auto:cdsdisk    datadg03  datadg   online

The c2 and c3 paths should be pointing to the same device.  The EMC (SPC-2 bit) port setting will result in the LUN Serial Number being different for each individual path.

This results in DMP treating the individual paths and separate DMPNODEs, forcing VxVM to incorrectly display the paths as different disk access names.

Volume Manager generates a Unique Device Identification string (UDID) based on extra device information to help maintain device uniqueness. The format for this string takes the form of:

(Vendor ID)_(Product ID)_(Cabinet Serial No)_(LUN Serial No)

The LUN Serial Number used in the UDID string is drawn from the Array and is not by default the SCSI serial number seen in a standard SCSI inquiry (as demonstrated with the vxdmpinq utility below, now named vxscsiinq).

# vxdisk list c2t50060482D530C8A7d0s2 | egrep "^udid"
udid:      EMC%5FSYMMETRIX%5F104354%5F60060480000190104354533030364532

# vxdisk list c3t50060482D530C8A8d0s2 | egrep "^udid"
udid:      EMC%5FSYMMETRIX%5F104354%5F546E2000

The UDID differs for the different LUN paths for the same LUN, due to the SPC-2 bit setting difference, being off and on.

The vxdmpinq utility was available in earlier VxVM product versions and is now named /etc/vx/diag.d/vxscssinq.
 

# /etc/vx/diag.d/vxdmpinq /dev/rdsk/c2t50060482D530C8A7d0s2
Vendor id       : EMC
Product id      : SYMMETRIX
Revision        : 5772
Serial Number   : 546E2000Q

# /etc/vx/diag.d/vxdmpinq /dev/rdsk/c3t50060482D530C8A8d0s2
Vendor id       : EMC
Product id      : SYMMETRIX
Revision        : 5772
Serial Number   : 546E2000Q

This variation in the LUN Serial Number & UDID extracted by the "libvxemc.so" ASL (Array Support Library) is the reason for the failure in multi-pathing the LUN correctly.  


Further details regarding this data can be observed by collecting an ASLdebug.  

From the 'libvxemc.so' CLAIM section of the ASLdebug info file:

       scsi inquiry                           : /dev/rdsk/c2t50060482D530C8A7d0s2
       Vendor Identification                  : EMC
       Product Identification                 : SYMMETRIX
       Revision                               : 5772
       Serial Number                          : 546E2000Q^@^
       libvxemc.so:claim_device()             : CLAIMED
       CAB_SERIAL_NO                          : 104354
       LUN_SERIAL_NO                          : 60060480000190104354533030364532
       REVISION                               : 5772
       SCSI_VERSION                           : 4
       UDID                                   : EMC_SYMMETRIX_104354_60060480000190104354533030364532


       scsi inquiry                           : /dev/rdsk/c3t50060482D530C8A8d0s2
       Vendor Identification                  : EMC
       Product Identification                 : SYMMETRIX
       Revision                               : 5772
       Serial Number                          : 546E2000Q^@^
       libvxemc.so:claim_device()             : CLAIMED
       CAB_SERIAL_NO                          : 104354
       LUN_SERIAL_NO                          : 546E2000
       REVISION                               : 5772
       SCSI_VERSION                           : 2
       UDID                                   : EMC_SYMMETRIX_104354_546E2000

 

All ports should be configured to have the SPC-2 bit set to ON.  

Once this port setting has been corrected, use the Veritas "dmpdr -o refresh" utility to refresh the OS device tree and VxVM & DMP incore databases.

See article: