How to correct udid mismatch on vxdisk list command output

From Wiki-UX.info
Jump to: navigation, search

Abstract

On Veritas Volume Manager 5.x, the Unique Disk Identifier (udid) has been introduced to handle the situation where two or more disks has their private areas duplicated. This is a common situation using SAN based tools to clone LUNs.

This feature tries to prevent the situation where two or more disk contains the same private area, and VxVM may use the first available disk or other undefine behaviors. When this situation occurs, volumes groups can be imported tagging those disk a clone devices, or updating the udid values.

There is a uncommon situation where this can occur: VxVM product 5.01 is rollback to the previous 5.0 version. Under this task, removing 5.01 and installing 5.0 can change the state of the DDL database. Several disk may incorrectly report do have duplicate udids.

Example:

# vxdisk -o alldgs list 
DEVICE       TYPE            DISK         GROUP        STATUS 
disk1        auto:LVM        -            -            LVM 
disk2        auto:LVM        -            -            LVM 
disk3        auto:LVM        -            -            LVM 
disk4        auto:cdsdisk    -            (cvm01dg)    online shared udid_mismatch 
disk5        auto:cdsdisk    -            (cvm02dg)    online shared udid_mismatch 
disk6        auto:cdsdisk    -            (cvm03dg)    online shared udid_mismatch 
disk7        auto:cdsdisk    -            (cvm04dg)    online shared udid_mismatch 
disk8        auto:cdsdisk    -            (cvm05dg)    online shared udid_mismatch 
disk9        auto:cdsdisk    -            -            online 
disk10       auto:LVM        -            -            LVM 
disk11       auto:LVM        -            -            LVM 
disk12       auto:LVM        -            -            LVM 
disk13       auto:LVM        -            -            LVM 
disk14       auto:LVM        -            -            LVM 
disk15       auto:LVM        -            -            LVM 
disk16       auto:LVM        -            -            LVM 
disk17       auto:cdsdisk    -            -            online 
disk18       auto:LVM        -            -            LVM 
disk19_p2    auto:LVM        -            -            LVM 
disk20_p2    auto:LVM        -            -            LVM

In most cases, just deporting the disk group and using vxdisk updateudid command to sync the DDL with the disk private area will correct the problem. IF that does not correct the problem, the following procedure can be use to clean the state.

Update UDID Procedure

1 . Stop any file system access.

2. Deport the disk groups

# vxdg deport <diskgroup>

3. Clear the locks on the disk, using device name:

# vxdisk clearimport <disk_access> ...

4. Change / update the clear udid on the disk.

# vxdisk updateudid <disk_access> ...

5. Import diskgroup again.

# vxdg -o updateid import <diskgroup>

Example:

# vxdg deport cvm01dg
# vxdg deport cvm02dg
# vxdg deport cvm03dg
# vxdg deport cvm04dg
# vxdg deport cvm05dg
# vxdisk clearimport disk4 dik5 disk6 disk7
# vxdisk updateudid disk4 disk5 disk6 disk7
# vxdg -o updateid import cvm01dg
# vxdg -o updateid import cvm02dg
# vxdg -o updateid import cvm03dg
# vxdg -o updateid import cvm04dg
# vxdg -o updateid import cvm05dg

Reference

Authors

How to correct udid mismatch on vxdisk list command output

Abstract 

On Veritas Volume Manager 5.x, the Unique Disk Identifier (udid) has been introduced to handle the situation where two or more disks has their private areas duplicated. This is a common situation using SAN based tools to clone LUNs. 

This feature tries to prevent the situation where two or more disk contains the same private area, and VxVM may use the first available disk or other undefine behaviors. When this situation occurs, volumes groups can be imported tagging those disk a clone devices, or updating the udid values. 

There is a uncommon situation where this can occur, when VxVM 5.01 is rollback to the previous 5.0 version. Under this task, removing 5.01 and installing 5.0 can change the state of the DDL database. Several disk may incorrectly report do have duplicate udids. 

Example: 

# vxdisk -o alldgs list 
DEVICE       TYPE            DISK         GROUP        STATUS 
disk1        auto:LVM        -            -            LVM 
disk2        auto:LVM        -            -            LVM 
disk3        auto:LVM        -            -            LVM 
disk4        auto:cdsdisk    -            (cvm01dg)    online shared udid_mismatch 
disk5        auto:cdsdisk    -            (cvm02dg)    online shared udid_mismatch 
disk6        auto:cdsdisk    -            (cvm03dg)    online shared udid_mismatch 
disk7        auto:cdsdisk    -            (cvm04dg)    online shared udid_mismatch 
disk8        auto:cdsdisk    -            (cvm05dg)    online shared udid_mismatch 
disk9        auto:cdsdisk    -            -            online 
disk10       auto:LVM        -            -            LVM 
disk11       auto:LVM        -            -            LVM 
disk12       auto:LVM        -            -            LVM 
disk13       auto:LVM        -            -            LVM 
disk14       auto:LVM        -            -            LVM 
disk15       auto:LVM        -            -            LVM 
disk16       auto:LVM        -            -            LVM 
disk17       auto:cdsdisk    -            -            online 
disk18       auto:LVM        -            -            LVM 
disk19_p2    auto:LVM        -            -            LVM 
disk20_p2    auto:LVM        -            -            LVM

In most cases, just deporting the disk group and using vxdisk updateudid command to sync the DDL with the disk private area will correct the problem. IF that does not correct the problem, the following procedure can be use to clean the state. 

Update UDID Procedure 

1 . Stop any file system access. 

2. Deport the disk groups 

# vxdg deport <diskgroup>

3. Clear the locks on the disk, using device name: 

# vxdisk clearimport <disk_access> ...

4. Change / update the clear udid on the disk. 

# vxdisk updateudid <disk_access> ...

5. Import diskgroup again. 

# vxdg -o updateid import <diskgroup>

Example: 

# vxdg deport cvm01dg
# vxdg deport cvm02dg
# vxdg deport cvm03dg
# vxdg deport cvm04dg
# vxdg deport cvm05dg

# vxdisk clearimport disk4 dik5 disk6 disk7

# vxdisk updateudid disk4 disk5 disk6 disk7

# vxdg -o updateid import cvm01dg
# vxdg -o updateid import cvm02dg
# vxdg -o updateid import cvm03dg
# vxdg -o updateid import cvm04dg
# vxdg -o updateid import cvm05dg

Reference 
* Veritas Volume Manager 5.0 for HP-UX Software - Handling Disks with Duplicated Identifiers in Veritas Volume Manager (VxVM) 5.0 - http://sawpro.atlanta.hp.com/km/saw/view.do?docId=emr_na-c01937172
* HP ServiceGuard for HP-UX - VxVM 5.0.1: Problem with Importing Cloned LUN on the Same Host - http://sawpro.atlanta.hp.com/km/saw/view.do?docId=emr_na-c01992306
* HP-UX 11i v2 - VxVM 5.0: Diskgroup Import Fails with "Disk group has no valid configuration copies" - http://sawpro.atlanta.hp.com/km/saw/view.do?docId=emr_na-c02075533