vgchange error

[Scottt]

Hello everybody,

I have timefinder implimented on our EMC symmetrix. After doing establish and split on production system, I have done vgimport on a test system to have data available for testing. But when I try to activate the volume group with vgchange -a y /dev/vgxx /dev/dsk/cXtXdX I am getting following error.
vgchange: Activation mode requested for the volume group "/dev/vgxx" conflicts with configured mode.

I have tried vgchange -a n /dev/vgxx and that runs successfully.

Also under /dev/vgxx dir I can see all the lvols too. So I am assuming that vgimport also worked fine.

Thanks,

[A. Clay Stephenson]

Hi Scott:

Was this volume part of an MC/SG cluster or a Shared Volume Group.

You need to do a vgchange -a n
then
vgchange -c n (to disable cluster mode)
or
vgchange -S n (to disable shared mode)

You should then be able to vgchange -a y

[James R. Ferguson]

Hi Scott:

You need to use 'vgchgid' to change the VGID of the disk begore the 'vgimport' in this case. See the man pages for 'vgchgid' for the steps to handle this EMC/Timefinder situation.

...JRF...

[Scottt]

Hi there
thanks
Clay,
No this disk was not part of any MC/SG.

James,
As per EMC tech support, vgchgid is neccessary only if you are mounting the disk on the same system under some different vgxx. I am mounting disk on to a different system for testing perposes.

[A. Clay Stephenson]

Hi Scott,

When I saw you were trying to mount on a different system, I considered the probability duplicated VGID's. near zero. However, I can think of one very non-zero probability scenario. When you created your group file for vgxx, did you make certain that the minor device number was unique and not also assigned to some other volume group on this same test box? I'm not sure what the results would be be I know they would not be good.

Hope this helps, Clay

[James R. Ferguson]

Hi (again) Scott:

TWO QUESTIONS, PLEASE:

1. Did you use the 'vgchgid' at all? [I understand that you said EMC support said it was necessary].

2. If you *did* use the 'vgchgid' did you issue the command with *all* physical volumes specified in one command string?

...JRF...

[A. Clay Stephenson]

Hi Scott,

One other thought, when you vgexported and vgimported did you specify the -s option so that it went out and picked up all the disks
in the original volume group rather than specifying the new disks by physical device. That would also cause problems. For whatever reason, vgchange thinks at least some of the disks it is seeing are part of a shared volume group or a cluster.

Clay

[Scottt]

Hello,

Clay,

Minor device no. is uniqyue on the test system.
I did not have to do vgexport since sync. of the disk happens at EMC level and not at HP-UX level.

James,

As per EMC I Don't have to run vgchgid since I am mounting this disk on to a different system than the one syncd with.

I didn't run that command at all

[John Poff]

Hello,

From your original question, you said,

"...when I try to activate the volume group with vgchange -a y /dev/vgxx /dev/dsk/cXtXdX I am getting following error.
vgchange: Activation mode requested for the volume group "/dev/vgxx" conflicts with configured mode."

Are you doing this:

vgchange -a y /dev/vgxx /dev/dsk/cXtXdX

Or are you doing this:

vgchange -a y /dev/vgxx

The vgchange command doesn't take a disk device as an argument. Maybe I just didn't read your post correctly, so I thought I would ask.

Just so I can understand your problem, is this what you did?

1. EMC sync
2. EMC split
3. (on second box), create vg and vgimport
4. vgchange (which fails with noted error message)



JP

[Scottt]

JP,

My mistake I am using
vgchange -a y /dev/vgxx

Also your chronology is correct. But I am doing
mkdir /dev/vgxx and
mknod /dev/vgxx/group c 64 0xxx0000
before doing EMC sync. and EMC split

Clay,

My mistake, The disk on the production system is a part of MS/SG. Also I am using same vgxx and minor device no. for production system and test system. May be that is the problem. I will try to change the name and device no. on vg and see if that makes any difference. I will let you know.

thanks

[John Poff]

Being in an MC/ServiceGuard cluster makes a difference.

As James mentioned earlier, you will need to do the vgchgid command, and you will have to do it on all the PVs in the volume group.

JP

[A. Clay Stephenson · Accepted solution]

Hi Scott,

You bet MC/SG does make a difference. Although,
you say you did not do a vgexport - it is very normal in this situation to do this especially if you use lvol's other than lvol1, lvol2, ...
. One typically does a vgexport -p -m /tmp/mymapfile /dev/vg04 and that creates a mapfile but only does a preview so that the original data remains. If you added a -s option it would have added the VGID to the mapfile and when you imported that would cause
problems if you then imported using the -s option. The system would scan all disk devices looking for that VGID and would get the original production disks plus the copies.

In any event, it looks like you are close to success.

Clay

[Scottt]

Hi There again,

First of all thanks to all who has try to help me.

Clay, You are right. I had to do
vgchange -c n /dev/vgxx before I was able to do
vgchange -a y /dev/vgxx.

Well also I was going to ask you about the situation you had just mentioned on the subject of lvol1, lvol2 .

We are using different logical volume names than lvol1, lvol2 etc. when I did vgimport it imported all the logical volumes with default names ( lvol1, lvol2..etc) instead of original names. I guess I have to create a map file with -m and -p options. then do vgimport with -m mapfile. so that I can also get original logical volume group names.

Thanks again.