Video Screencast Help

Solaris9/VxVM 3.5 -> Solaris10/VxVM 5.0 + SunCluster 3.2 (2 nodes)

Created: 16 Jul 2009 • Updated: 21 May 2010 | 4 comments
lne's picture
This issue has been solved. See solution.

Hello guys, im deep in trouble.. hope someone can help me :)

Im working on a migration from a Solaris9/VxVM 3.5 to a Solaris10/VxVM 5.0 running SunCluster 3.2 , the data is being replicated between the storgaes using EMCs SRDF.
When i execute the split on the replication and try to import the DG onto the Cluster Servers i get the following error message:

# vxdg import prdsapdg
VxVM vxdg ERROR V-5-1-10978 Disk group prdsapdg: import failed:
No valid disk found containing disk group

I get the same error on both nodes ...

Is seems, somehow, that vxvm is not able to locate the private region on disks.... 

If use the same replicated disks to create a *new* DG i can get it work with no problem.....

Any suggestion???

Output from vxdisk list:
------------------------------
#vxdisk -e -o alldgs list
DEVICE TYPE DISK GROUP STATUS OS_NATIVE_NAME ATTR
emc1_107a auto - (prddg) online c4t60060480000290103304533031303741d0s2 srdf-r2
emc1_107b auto - (prddg) online c4t60060480000290103304533031303742d0s2 srdf-r2
emc1_107c auto - (prddg) online c4t60060480000290103304533031303743d0s2 srdf-r2
emc1_107d auto - (prddg) online c4t60060480000290103304533031303744d0s2 srdf-r2
emc1_107e auto - (prddg) online c4t60060480000290103304533031303745d0s2 srdf-r2
emc1_107f auto - (prddg) online c4t60060480000290103304533031303746d0s2 srdf-r2

Thanks! :)

Comments 4 CommentsJump to latest comment

lne's picture

Misstyped....

the correct copy from the import:

# vxdg import prddg
VxVM vxdg ERROR V-5-1-10978 Disk group prdsapdg: import failed:
No valid disk found containing disk group

mike_root's picture

If you take a hardware snapshot/replica of an imported diskgroup, VxVM is going to think that these disks are being used in an imported diskgroup.
VxVM will skip looking at the config copies/private region of disks once it identifies it as part of an imported diskgroup.

The solution is to use -C when importing the diskgroup to clear the hostid from the private region.

The (prddg) in the -o alldgs output shows that VxVM can find the private region.  I suspect that the imported diskgroup is the issue.  This can be identified by looking at one of the disks and seeing that the hostid or clusterid is set. 

vxdisk list emc1_107a
should show a bunch of stuff and have one line that is
hostid:  <myoldhost>
or
clusterid: <myoldcluster>

If you know for sure that these are not being used, then the -C option to vxdg says to clear the hostid/clusterid from the private region and treat the disks as if they were not being used by the other host.

WARNING: This can cause data loss if the disks are still being used by the other system. -C option should only be used when you have verified that the disks are NOT already in use.

SOLUTION
ngsakaria's picture

First check GAB Port Memberships before importing diskgroup. If its available and still you encounter import fail issue than you could go for -C option but be careful the disks are not still being used by the other system.

/opt/VRTS/bin/gabconfig -a
vxdg -Cf import diskgroup

If its successful than start and mount the volume accordngly.

Naresh Sakaria

Gaurav Sangamnerkar's picture

Hello,

Is VXVM already upgraded to 5.0 ? If yes you can use option of "useclonedev=on" along with -C as suggested above so that VXVM is aware of clone copy.

Gaurav

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.