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?
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
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:
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.
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:
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?