cancel
Showing results for 
Search instead for 
Did you mean: 

Disk Group Import Failure

springman
Not applicable
SAN disks which were originally in a Volume Manager 4.1disk group disappeared during a power failure.  We had to subsequently rebuild the server and we install a newer version of Volume Manager in the process(without the SAN disks present on the server at the time).  Then, after installing the latest version of volume manager, we tried to reattach the disks by importing them using the newer volume manager.  We are seeing all of the devices(disks), and a vxdisk list of the individual disks shows that their headers still contain the previously created volume manager disk group information, but the volume manager fails to import the group with an error that says that there are 'No valid disks found containing disk group' . 

Could a volume manager version mismatch between the latest software version which is currently installed on the server, and the old version used to create the disk headers cause a disk group import to fail?  Has anyone seen/experienced/heard of this before?
1 ACCEPTED SOLUTION

Accepted Solutions

Gaurav_S
Moderator
Moderator
   VIP    Certified
Other possibility here is, the disk names got changed...

for e.g if initially a disk was called Disk_0 in vxdisk list, it is now called Disk_1

This order may change depending on how OS builds its device tree... In this scenario you may need to match the diskids from old outputs under /etc/vx/cbr/bk

Gaurav

View solution in original post

6 REPLIES 6

naparse
Not applicable
Typically the "No valid disks found contian disk group" error is presented when one or more of the disks that were originally part of the disk group are not found.  The "no valid disks" part of the error is kind of a misnomer.

You can do the following to investigate/confirm this:

List of visible disks reporting disk group membership:
# vxdisk -o alldgs list | grep <diskgroup_name>

Count of those disks:
# vxdisk -o alldgs list | grep <diskgroup_name> | wc -l

EG:
# vxdisk -o alldgs list | grep testdg
Disk_6          auto:cdsdisk    -            (testdg)     online
Disk_7          auto:cdsdisk    -            (testdg)     online
Disk_8          auto:cdsdisk    -            (testdg)     online

# vxdisk -o alldgs list | grep testdg | wc -l
3


Next you need to determine how many disks the disk group configuration says should be present.  To do this you need to identify a disk in the disk group with a configuration copy on it.  Start looking at the "vxdisk list <device>" output for those disks until you identify the following:

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

If the config lines say "enabled" then take a note of the "private" slice for that disk:

# vxdisk list Disk_6 | egrep "^private"
private:   slice=3 offset=256 len=65536 disk_offset=0

Next check the following:

# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/<device>s# | egrep "^dm"
(List of disk records in the disk group)


# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/<device>s# | egrep "^dm" | wc -l
(Count of those disk records)

EG:
# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/Disk_6s3 | egrep "^dm"
dm   disk01
dm   disk02
dm   disk03
dm   disk04
 
# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/Disk_6s3 | egrep "^dm" | wc -l
4

Next compare the value from the vxprivutil command line count and the vxdisk -o alldgs list count.  As you can see in the above example, the disk group is expecting to find 4 disks, but only 3 disks are attached to the system.

You can attempt to force disk group import as well:

# vxdg -f import <diskgroup>

Afterwards perform a "vxdisk list" and not any failed or missing device statements.

GGJ
Not applicable

Assuming that all of the disks are visible, another possibility is that you need to clear the locks on the disk group. This is especially important if the the hostname was changed during the new server build. It's likely that the disk group was left in an imported state as a result of the power failure. Try importing the the disk group with the -C option:

# vxdg -C import <disk group name>


Gaurav_S
Moderator
Moderator
   VIP    Certified
Other possibility here is, the disk names got changed...

for e.g if initially a disk was called Disk_0 in vxdisk list, it is now called Disk_1

This order may change depending on how OS builds its device tree... In this scenario you may need to match the diskids from old outputs under /etc/vx/cbr/bk

Gaurav

wzis
Level 3
Employee Accredited Certified
For Solaris/Sparc platform, the dgdebug tool (http://support.veritas.com/docs/331485) will be very helpful to identify the cause of import failure.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Hopefully springman managed to import his dg by now...? (it's been 6 weeks!)
Maybe he could give us feedback and let us know if any of the advice was useful.

uid60001
Level 2

We have a system which multiple power failure in last 18 months. One of the oracle backup file system,which has it's own disk group, failed to mount in last a few power interruption. Furthe check, the disk group record in the /etc/vx/cbr/* directory hasn't been updated.  Recreate the diskgroup/volume today, then; deport and import the disk. The deport/import work OK. I am expect to see new record regarding the disk since export and import action took place. But it is not in /etc/vx/cbr/*.  For the record, this server boot up without a lot of the default system processes running[like the script in rc2.d and rc3.d haven't been run]. I start them with for loop manually, but did not trouble shoot further. Without the cbr on the newly recreated disk group on the system, I suspect the system won't able to recognize the disk group again after another power interrupted crash.

How can I forcefully create a cbr record for this disk group named orabkup?

Dean