Using UDIDs and Disk IDs to manually restore a disk group configuration

Article:TECH201367  |  Created: 2013-01-04  |  Updated: 2014-10-31  |  Article URL http://www.symantec.com/docs/TECH201367
Article Type
Technical Solution


Issue



If using vxconfigrestore is not possible, another method for recovering the disks is to compare the attributes of the disks with the records that are contained with the private region configuration database.


Error



Disk group has no valid configuration copies


Solution



 

This article is a part of a set on troubleshooting failed, or failing, disks. Click here to start at the beginning: http://www.symantec.com/docs/TECH200618

 


Table of Contents


Introduction
Matching disks using UDIDs
Matching disks using Disk IDs

Reinitializing the disk while preserving existing data
Adding the disk back to the diskgroup with vxdg





Introduction
(Back to top)

If using vxconfigrestore is not possible, another method for recovering the disks is to compare the attributes of the disks with the records that are contained with the private region configuration database. In most cases, matching these disk attributes with records that are contained within the private region configuration database confirms whether or not the disk shown in vxdisk list (under the "DEVICES" column) is really the same disk that is reported in the "failed was" record.




Matching disks using UDIDs

(Back to top)

Using UDIDs is usually preferred over using Disk IDs because the Disk ID is contained within the Veritas private region and it may change if a disk is reinitialized, while the UDID remains the same.

Match the UDID that is recorded in the private region configuration database with the UDID that is found within the disk headers of any disks that need to be added back into the disk group. In most cases, a match confirms that the disk shown in vxdisk list (under the "DEVICES" column) is really the same disk that is reported in the "failed was" record.

1. Use vxdisk list to find the UDID from the disk header of a disk that needs to be added back into the disk group (Figure 1).


Figure 1 - Using vxdisk and grep to find the UDID for a disk in the disk header

 
Syntax:

vxdisk -o alldgs list

vxdisk list <device_name>


Example, with typical output:

# vxdisk -o alldgs list

DEVICE       TYPE           DISK        GROUP        STATUS
disk_0       auto:cdsdisk   -            (vxfendg)   online
disk_1       auto:cdsdisk   -            (vxfendg)   online
disk_2       auto:cdsdisk   -            (vxfendg)   online
disk_3       auto:cdsdisk   datadg01     datadg      online
disk_4       auto           -            -           error
disk_5       auto:cdsdisk   datadg03     datadg      online
disk_6       auto:cdsdisk   datadg04     datadg      online
disk_7       auto:cdsdisk   -            (sambadg)   online
disk_8       auto:cdsdisk   -            -           online
disk_9       auto:cdsdisk   -            -           online
sda          auto:none      -            -           online invalid
-            -         datadg02     datadg       failed was:disk_4


# vxdisk list disk_4 | grep -i udid

udid:      VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8

 





2. Determine if there is a record of this UDID in the backup copy of the private region configuration database (Figure 2).

By default, Volume Manager stores automatic backups of the private region configuration database to /etc/vx/cbr/bk/<disk_group>/*.diskinfo. If a backup was taken manually, using with vxconfigbackup or privutil, the UDID may also be found there. If the UDID is found, note the value of the "Device" record to which it is associated. If this matches the UDID found in Step 1, then the disks are probably the same.


Note: Only use an enabled copy of the private region configuration database. Notice that in the output shown in Figure 2, the "config" has a status of "enabled."

 


 
Figure 2 - Searching for the UDID record in the backup of an enabled copy of the configuration database

Example, with typical output:
# less /etc/vx/cbr/bk/datadg.1336573086.38.Server101/1336573086.38.Server101.diskinfo

(excerpt from output)

Device:    disk_4
devicetag: disk_4
type:      auto
hostid:    Server101
disk:      name=datadg02 id=1356732184.45.Server101
group:     name=datadg id=1336573086.38.Server101
info:      format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags:     online ready private autoconfig autoimport imported
pubpaths:  block=/dev/vx/dmp/disk_4s3 char=/dev/vx/rdmp/disk_4s3
guid:      {59b46d24-513a-11e2-a6ec-fa9f812341a3}
udid:      MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8
site:      -
version:   3.1
iosize:    min=512 (bytes) max=1024 (blocks)
public:    slice=3 offset=65792 len=2027264 disk_offset=0
private:   slice=3 offset=256 len=65536 disk_offset=0
update:    time=1356732621 seqno=0.13
ssb:       actual_seqno=0.0
headers:   0 240
configs:   count=1 len=51360
logs:      count=1 len=4096
Defined regions:
 config   priv 000048-000239[000192]: copy=01 offset=000000 enabled
 config   priv 000256-051423[051168]: copy=01 offset=000192 enabled
 log      priv 051424-055519[004096]: copy=01 offset=000000 enabled
 lockrgn  priv 055520-055663[000144]: part=00 offset=000000
Multipathing information:
numpaths:   2
sdi             state=enabled
sdl             state=enabled
UUID=MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A99F54D1D5D2A12F

 




If no copies of the private region configuration database are available, disk.info may be used as an alternative (Figure 3). Disk.info only exists if disk persistence is enabled in dmppolicy.info. By default, both of these files are found under /etc/vx.


Figure 3 - Searching for the UDID record within disk.info

# cat /etc/vx/disk.info

VMware%5FVirtual%20disk%5FOTHER%5FDISKS%5FServer101%5F%2Fdev%2Fsda sda 0xc910 0x1 sda OTHER_DISKS OTHER_DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E38117220C5146E231 sdh 0xc990 0x2 disk_0 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3B0C237E3EE2B7225 sdg 0xc9b0 0x2 disk_6 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E381C85115F19A43F5 sdb 0xc970 0x2 disk_1 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3BBEC25236524B486 sde 0xc930 0x2 disk_8 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8 sdf 0xc9a0 0x2 disk_4 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3B53E871031307665 sdk 0xc960 0x2 disk_7 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3BF4B07325D4BE56F sdi 0xc940 0x2 disk_9 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E39848AE44D4AA3DB0 sdc 0xc950 0x2 disk_3 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E38CDDDB09DEB90282 sdj 0xc920 0x2 disk_2 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A99F54D1D5D2A12F sdd 0xc980 0x2 disk_5 Disk DISKS

 





Matching disks using disk IDs
(Back to top)

It is also possible to match disks using Disk IDs. However, because the Disk ID is contained within the Veritas private region, it may change if a disk has been reinitialized, while the UDID will remain the same. For this reason, do not attempt to use Disk IDs to match disks if a disk has already been reinitialized, such as with vxdisksetup or vxdisk init. When a disk is reinitialized, the existing private region is replaced. This results in a new Disk ID that is different from the original.

1. Use vxdisk list to find the Disk ID from the disk header of a disk that needs to be added back into the disk group (Figure 4).


Figure 4 - Using vxdisk to find the Disk ID in the header of a disk


Syntax:

vxdisk -o alldgs list

vxdisk list <device_name>


Example, with typical output:

# vxdisk -o alldgs list

DEVICE       TYPE           DISK        GROUP        STATUS
disk_0       auto:cdsdisk   -            (vxfendg)   online
disk_1       auto:cdsdisk   -            (vxfendg)   online
disk_2       auto:cdsdisk   -            (vxfendg)   online
disk_3       auto:cdsdisk   datadg01     datadg      online
disk_4       auto           -            -           error
disk_5       auto:cdsdisk   datadg03     datadg      online
disk_6       auto:cdsdisk   datadg04     datadg      online
disk_7       auto:cdsdisk   -            (sambadg)   online
disk_8       auto:cdsdisk   -            -           online
disk_9       auto:cdsdisk   -            -           online
sda          auto:none      -            -           online invalid
-            -         datadg02     datadg       failed was:disk_4




# vxdisk list disk_4 | grep -i disk:

disk:      name=datadg02 id=1356732184.45.Server101

 





2. Determine if there is a record of this Disk ID in the backup copy of the private region configuration database (Figure 5).

By default, Veritas stores automatic backups of the private region configuration database to /etc/vx/cbr/bk/<disk_group>/*.diskinfo. If a backup was taken manually, using with vxconfigbackup or privutil, the UDID may also be found there.

If the Disk ID is found, note the value of the "Device" record to which it is associated. If this matches the UDID found in Step 1, then the disks are probably the same.


Note: Only use an enabled copy of the private region configuration database. Notice that in the output from the example below, the "config" has a status of "enabled."




Figure 5 - Finding the Disk ID within the backup of an enabled copy of the configuration database

Example, with typical output:
 
# less /etc/vx/cbr/bk/datadg.1336573086.38.Server101/1336573086.38.Server101.diskinfo

(excerpt from output)

Device:    disk_4
devicetag: disk_4
type:      auto
hostid:    Server101
disk:      name=datadg02 id=1356732184.45.Server101
group:     name=datadg id=1336573086.38.Server101
info:      format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags:     online ready private autoconfig autoimport imported
pubpaths:  block=/dev/vx/dmp/disk_4s3 char=/dev/vx/rdmp/disk_4s3
guid:      {59b46d24-513a-11e2-a6ec-fa9f812341a3}
udid:      MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8
site:      -
version:   3.1
iosize:    min=512 (bytes) max=1024 (blocks)
public:    slice=3 offset=65792 len=2027264 disk_offset=0
private:   slice=3 offset=256 len=65536 disk_offset=0
update:    time=1356732621 seqno=0.13
ssb:       actual_seqno=0.0
headers:   0 240
configs:   count=1 len=51360
logs:      count=1 len=4096
Defined regions:
 config   priv 000048-000239[000192]: copy=01 offset=000000 enabled
 config   priv 000256-051423[051168]: copy=01 offset=000192 enabled
 log      priv 051424-055519[004096]: copy=01 offset=000000 enabled
 lockrgn  priv 055520-055663[000144]: part=00 offset=000000
Multipathing information:
numpaths:   2
sdi             state=enabled
sdl             state=enabled
UUID=MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A99F54D1D5D2A12F

 





Reinitializing the disk while preserving existing data
(Back to top)

Determine the offset and length of the public region. Then, reinitialize the disk using vxdisksetup. Specifying the public region offset and length allows Veritas to preserve the existing data while allowing flexibility for changes to the private region.
 


More details about reinitializing a disk, while preserving the existing data, can be found in this article:

"Reinitializing a disk while preserving existing data"
http://www.symantec.com/docs/TECH202416

 

 



Adding the disk back to the diskgroup with vxdg
(Back to top)

After the disk has been reinitialized, and the status is "online," use vxdg to add it back to the disk group


Figure 6 - Using vxdg to add the disk back to the disk group


Syntax:

vxdg -g <disk group> -k adddisk <disk media name>=<device access name>


Example, with typical output:

# vxdg -g datadg -k adddisk datadg02=disk_4

Vxdisk now shows that datadg02 is back in the disk group. Additionally, the "failed was" message is gone.

# vxdisk -o alldgs list

DEVICE       TYPE            DISK         GROUP        STATUS
disk_0       auto:cdsdisk    -            (vxfendg)    online
disk_1       auto:cdsdisk    -            (vxfendg)    online
disk_2       auto:cdsdisk    -            (vxfendg)    online
disk_3       auto:cdsdisk    datadg01     datadg       online
disk_4       auto:cdsdisk    datadg02     datadg       online
disk_5       auto:cdsdisk    datadg03     datadg       online
disk_6       auto:cdsdisk    datadg04     datadg       online
disk_7       auto:cdsdisk    -            (sambadg)    online
disk_8       auto:cdsdisk    -            -            online
disk_9       auto:cdsdisk    -            -            online
sda          auto:none       -            -            online invalid

 

 




Article URL http://www.symantec.com/docs/TECH201367


Terms of use for this information are found in Legal Notices