Explanation of what the udid_mismatch flag indicates in vxdisk list output

UDID stands for Unique Device Identification. This is a feature introduced beginning in Storage Foundation 5.0 that was designed to enable import of cloned LUNs presented on the same host as the source disks.

A UDID is generated for every device discovered by Volume Manager and is composed of the following information:

Two strings are visible in "vxdisk -v list (device)" output:

# vxdisk -v list ams_wms0_5 | grep udid
udid: HITACHI%5FDF600F%5F73061247%5F0005
 tag     udid_asl=HITACHI%5FDF600F%5F73061247%5F0005

The component parts are separated by the '_' character, encoded here as %5F, so the following can be observed in the above string:
 

VID = HITACHI
PID = DF600F
Cabinet Serial Number = 73061247
LUN Serial Number = 0005
 

The first string "udid:" is generated by the Array Support Library through the Device Discovery Layer (DDL) processing during system boot or subsequent DMP reconfiguration (e.g. vxdctl enable, vxdisk scandisks).   "udid:" can change for each system boot or DMP reconfiguration if the diskarray cabinet or LUN serial number is changed or if udid generation program code is changed in a new version of ASL.

The second string "udid_asl" (or udid_jbod if the disk is not claimed by any ASL) is a permanent on-disk record of the udid found during the disk initialization (vxdisksetup or vxdisk init).   "udid_asl" is a permanent record on the disk and will change after disk initialization until "vxdisk updateudid" is run.
 

It is important to note that Cabinet/LUN serial numbers are different than the SCSI serial number.  SCSI serial numbers are encoded differently on a frame by frame basis. For instance, the AMS/WMS frames will present the SCSI serial number as a combination for Cabinet and LUN:

# /etc/vx/diag.d/vxdmpinq /dev/rdsk/c0t50060E80104EF3F0d1s2

Inquiry for /dev/rdsk/c0t50060E80104EF3F0d1s2, evpd 0x0, page code 0x0
Vendor id : HITACHI
Product id : DF600F
Revision : 0000
Serial Number : 730612470005

(Note: In 5.1 and beyond the vxdmpinq command has been renamed vxscsiinq to reflect that DMP is not involved in the command's behavior.)

What "udid_mismatch" indicates:
 

 

The "udid_mismatch" flag is set for a disk when the following conditions are met:

# vxdisk list
DEVICE TYPE DISK GROUP STATUS
ams_wms0_4 auto:cdsdisk d01 nadg online
ams_wms0_5 auto:cdsdisk - - online udid_mismatch
disk_0 auto:none - - online invalid
disk_1 auto:none - - online invalid

In this example, the ams_wms0_5 device was created as an atomic bit-for-bit copy of the ams_wms0_4 LUN, so we will expect the ams_wms0_5 device to have a mismatch UDID.

 

# vxdisk -v list ams_wms0_5 | grep udid
udid: HITACHI%5FDF600F%5F73061247%5F0005
tag udid_asl=HITACHI%5FDF600F%5F73061247%5F0004

 

"vxdisk -v list" command is not available in older version of VxVM, vxprivutil can be used to print the "tag udid_asl"

 

# /etc/vx/diag.d/vxprivutil list /dev/rdsk/c0t50060E80104EF3F0d1s2 | grep udid
tagid priv 2016- 2031[ 16]: tag=udid_asl=HITACHI%5FDF600F%5F73061247%5F0004

Compare this UDID with the UDID above from ams_wms0_4.

This device is being labeled as 'udid_mismatch' because the current device's UDID string does not match the UDID string stored in the disk's private region and the same UDID is present on ams_wms0_4.

This is an expected condition for LUNs created through processes such as BCV, Shadow Copy, or any other LUN duplicate methods. The this is because the physical device's information is different than the original source LUNs.

In most environments this flag can be ignored as an expected result of presenting duplicated Volume Manager initialized LUNs.

For environments where this flag is undesired, the cloned disk groups can be imported with the following parameter to change the udid_mismatch flag into the 'cloned' flag:

# vxdg -o useclonedev=on import nadg
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
ams_wms0_4 auto:cdsdisk - - online
ams_wms0_5 auto:cdsdisk d01 nadg online cloned
disk_0 auto:none - - online invalid
disk_1 auto:none - - online invalid

Situations involving array configuration issues or HBA configuration problems can also cause the 'udid_mismatch' flag to appear, usually in tandem with other DMP issues.

If the environment is working normally, and you do not experience any functional issues when working with 'udid_mismatch' flagged LUNs, and the LUNs in question are create through some form of LUN duplication procedure, then there is no issue and you do not need to pursue the issue further.

For environments where you are not using cloned LUNs and you are experiencing other issues such as paths not being multipathed correctly, or other DMP issues, please contact Technical Support for further investigation. 
 

 

Please note that starting from VxVM 5.0MP3 and 5.1, the udid_mismatch flag will not be shown if the disk has a unique disk id on the whole system.   This change is done through Etrack 1164957.   Please beware that starting from VxVM 5.0Mp3 and 5.1, the UDID mismatching condition can still exist even with disks not showing udid_mismatch flag.