"Disk group has no valid configuration copies" appears due to mixed matching, and mismatching, UDID values, resulting in a disk group import failure, following an upgrade to 5.1, or above

"Disk group has no valid configuration copies" appears due to mixed matching, and mismatching, UDID values, resulting in a disk group import failure, following an upgrade to 5.1, or above

Article: 100026167
Last Published: 2014-10-21
Ratings: 0 1
Product(s): InfoScale & Storage Foundation

Problem

Disk group fails to import and returns an error.
 

Error Message

#vxdg import testdg
VxVM vxdg ERROR V-5-1-10978 Disk group testdg: import failed:
Disk group has no valid configuration copies

Cause

This behavior may occur if the udid and the udid_asl are mismatched. In some cases, this occurs due to changes that are made to the udids during storage upgrades.

Note: This error has many possible causes, including disk read, or write, failures and private region corruption. This article is specific to the conditions caused by UDIDs.

Storage Foundation 5.x and 6.x checks the unique disk identifier (UDID) value that is known to the Device Discovery Layer (DDL) against the UDID value that is set in the private region of the disk.

The udid_mismatch flag is set on the disk if the values differ.
 

Example 1 - A disk that does not have the udid_mismatch flag set


#vxdisk -v list c3t50060E80004372C0d0s2

Device: c3t50060E80004372C0d0s2
devicetag: c3t50060E80004372C0d0....
udid: HITACHI%5FDF600F%5FD600101C%5F00EF
.....Annotations:
tag udid_asl=HITACHI%5FDF600F%5FD600101C%5F00EF
Multipathing information:
numpaths: 1
c3t50060E80004372C0d0s2 state=enabled type=primary
 

 

Example 2 - A disk that has the udid_mismatch flag set


#vxdisk -v list c2t50060E800543CB21d0s2

Device: c2t50060E800543CB21d0s2
devicetag: c2t50060E800543CB21d0
....
udid: HITACHI%5FOPEN-V%20%20%20%20%20%20-SUN%5F043CB%5F1300 .....
Annotations:
tag udid_asl=HITACHI%5FOPEN-V%20%20%20%20%20%20-SUN%5F04458%5F3800
 

 

Use this command to check the UDID for all of the disks in the system.

#vxdisk -q list | awk '{print $1}' | xargs -i vxdisk -v list {} | egrep '^Device|^disk:|^udid:|udid_asl' | sed 's/^udid: *//' | sed 's/.*udid_asl=//' | uniq -c
 

Example 3 - Using vxdisk to check for UDID mismatches


Syntax:

#vxdisk -q list | awk '{print $1}' | xargs -i vxdisk -v list {} | egrep '^Device|^disk:|^udid:|udid_asl' | sed 's/^udid: *//' | sed 's/.*udid_asl=//' | uniq -c


Example 1 (the UDIDs match):

#vxdisk -q list |awk '{print $1}'| xargs -i vxdisk -v list {} | egrep '^Device|^disk:|^udid:|udid_asl' | sed 's/^udid: *//' | sed 's/.*udid_asl=//' | uniq -c
1 Device: c3t50060E80004372C0d0s2
1 disk: name= id=1170304512.108.srini-v240
2 HITACHI%5FDF600F%5FD600101C%5F00EF <==== The UDIDs match


Example 2 (the UDIDs do not match):

#vxdisk -q list |awk '{print $1}'| xargs -i vxdisk -v list {} | egrep '^Device|^disk:|^udid:|udid_asl' | sed 's/^udid: *//' | sed 's/.*udid_asl=//' | uniq -c

1 Device: c2t50060E800543CB21d0s2
1 disk: name= id=1254413623.47.ut81223
1 HITACHI%5FOPEN-V%20%20%20%20%20%20-SUN%5F043CB%5F1300 ==== All UDID does not match
1 HITACHI%5FOPEN-V%20%20%20%20%20%20-SUN%5F04458%5F3800 ==== All UDID does not match
 

 

Solution

Table 1 - Version specific documentation about clearing the udid_mismatch flag for 6.1 and 6.0.1

6.1
AIX https://sort.Veritas.com/public/documents/sfha/6.1/aix/
productguides/html/sfhas_tshoot/ch09s01.htm
Linux https://sort.Veritas.com/public/documents/sfha/6.1/linux
/productguides/html/sfhas_tshoot/ch09s01.htm
Solaris https://sort.Veritas.com/public/documents/sfha/6.1/solaris
/productguides/html/sfhas_tshoot/ch09s01.htm
   
6.0.1
AIX https://sort.Veritas.com/public/documents/sfha/6.0.1/aix
/productguides/html/sfhas_tshoot/ch08s01.htm
HP https://sort.Veritas.com/public/documents/sfha/6.0.1/hp-ux
/productguides/html/sfhas_tshoot/ch08s01.htm
Linux https://sort.Veritas.com/public/documents/sfha/6.0.1/linux
/productguides/html/sfhas_tshoot/ch08s01.htm
Solaris https://sort.Veritas.com/public/documents/sfha/6.0.1/solaris
/productguides/html/sfhas_tshoot/ch08s01.htm




Additional information:

1. Verify that the disks are not actually duplicates. This may occur if cloned disks are presented to the same server as the original disks. 

2. Save the current diskgroup configuration, as a precaution, by following the steps in this article:

Using vxconfigbackup and vxprivutil to back up up the disk group configuration of the Veritas private region
https://www.veritas.com/docs/000087431


3. Use vxdisk to update the UDID:

#vxdisk <-f> updateudid <device>

This uses the current value of the UDID which is stored in the Device Discovery Layer (DDL) database to correct the value in private region. The "-f" option may be specified if Storage Foundation has not raised the udid_mismatch flag for a disk.

Note: Storage Foundation 5.0 MP3 RP3, or above, is required to update the unique disk identifier (UDID).


4. Use vxdisk to set the "clone" flag to "off":

#vxdisk set <dmpnode name> clone=off

 
5. User vxdg to import the diskgroup:

#vxdg import <disk group name >

 


Note: For a disk group with a large number of disks, the following syntax may be used to process multiple disks at once.

 

Use vxdisk to collect a list of disks that belong the "problem" disk group into a temporary file:

#vxdisk -o alldgs list | grep <diskgroup name> | awk '{print $1}' > /tmp/list

Check the content of this file to ensure that it only contains disks that belong the "problem" disk group.

Correct the UDID, and turn-off the clone flag, using updateudid and vxdisk:

#for i in `cat /tmp/list`; do vxdisk updateudid $i; vxdisk set $i clone=off ; done


 

 


Was this content helpful?