The command "vxdisk updateudid <device>" modifies the DISK_ID value of the device as well as updating the Unique Device ID value in the disk private region, causing a disk group to be corruption and unable to import.
If the "vxdisk updateudid <device>" command has already been executed on the system software level is below Storage Foundation 5.0 MP1 RP5 then the disk group is corrupted and support assistance will be required in order to perform recovery.
Before beginning identify the current version of Storage Foundation:
Solaris: # modinfo | grep vxdmp
Linux: # rpm -qa | grep vxvm
HPUX: # swlist | grep vxvm
AIX: # lslpp -l | grep vxvm
If the product level reported is below 184.108.40.206 (or 5.0 MP1 RP5) then the system MUST be patched before continuing. Identify the necessary patches for your environment on the Symantec Operations Readiness Tools website:
Symantec Operations Readiness Tools : Patch Matrix
Following confirmation that the system is at the appropriate patch levels, please review the following knowledge base document explaining what the "udid_mismatch" flag indicates to assist you in determining if continuing with the following procedure to remove that flag is necessary or desired:
Explanation of what the udid_mismatch flag indicates in vxdisk list output
Additionally, note that if the LUNs displaying the "udid_mismatch" flag are the result of a BCV or other LUN duplication process then this is a normal and expected result and the following command should be used to import the disk group:
# vxdg -o useclonedev=on import <diskgroup>
Following import with this command the disks will be relabeled as "clone_disk" and usage can proceed without requiring further action.
Procedure to correct UDID flag using "vxdisk updateudid <device>"
The first step before continuing with this procedure is to save some basic device information in the event disk group recovery is necessary. Import the disk group and run the following commands:
# vxdg import <diskgroup>
# vxdisk list | grep <diskgroup> > /var/tmp/save.<diskgroup>.device_dm_list
# vxprint -mg <diskgroup> > /var/tmp/save.<diskgroup>.vxprint_m
Once the above data is saved the disk group should be deported:
# vxdg deport <diskgroup>
The above commands should be repeated for any affected disk groups. Only proceed once data has been saved for all disk groups with devices indicating a "udid_mismatch" flag.
Once the disk group is deported affected disks can have their UDID values updated:
# vxdisk -o alldgs list | grep udid_mismatch
ams_wms0_4 auto:cdsdisk - (testdg) online udid_mismatch
ams_wms0_5 auto:cdsdisk - (testdg) online udid_mismatch
ams_wms0_6 auto:cdsdisk - (testdg) online udid_mismatch
ams_wms0_7 auto:cdsdisk - (testdg) online udid_mismatch
ams_wms0_8 auto:cdsdisk - - online udid_mismatch
# vxdisk updateudid <device>
# vxdisk updateudid ams_wms0_4
# vxdisk updateudid ams_wms0_5
Once all disks have had their UDID values updated using the "vxdisk updateudid" command the disk group can be reported and verified as working:
# vxdg import <diskgroup>
# vxdg -g <diskgroup> startall
Do not run "vxdisk updateudid" on system with Storage Foundation 5.0 MP1 RP4 patch level or lower.
This issue affects the following Storage Foundation product levels (applicable to ALL OS platforms):
- VxVM 5.0 Base
- VxVM 5.0 Maintenance Pack 1
- VxVM 5.0 Maintenance Pack 1 Rolling Patch 1
- VxVM 5.0 Maintenance Pack 1 Rolling Patch 2
- VxVM 5.0 Maintenance Pack 1 Rolling Patch 3
- VxVM 5.0 Maintenance Pack 1 Rolling Patch 4
The bare minimum level to utilize the "vxdisk updateudid" functionality is VxVM 5.0 Maintenance Pack 1 Rolling Patch 5 or above.