vg config inconsistent on 2 SG nodes..

[Mark Henry_1]

All,

After adding a 2nd instance of a physical volume to a volume group (alternate link) and exporting the vg map, the map was transferred to and imported into another system that can accept the package containing the volume group.
When cmcheckconf was run (for other cluster changes), an error was displayed saying that the volume group configuration was different on the 2 machines in question.
When I move the registry package to the other host, vgdisplay doesn't show the alternate link on the 2nd machine (no surprises considering the error message).
How can I get them to be the same? I assumed updating and importing the vg map file on the 2nd would have the desired effect - it's not possible to add the alt link on the 2nd machine because the volume group is inactive on that machine (and I've completed this step successfully with other vg's).
Could it be the fact that the scsi controllers have different target ID's on the different machines?

Any ideas?

Thanks,

Mark

[Animesh Chakraborty]

Hi,
Run insf -e on 2nd node.
Is lvmtab of 2nd node showing alternate link ?


Animesh

[Mark Henry_1]

Animesh,

Thanks for the reply.

I re-ran 'insf -e' just to be sure and after a cmcheckconf still the same error..
"Error: Volume group /dev/vg_rgy is configured differently on node node_1 than on node node_2"

Not sure I understand your second suggestion - lvmtab is a binary file, correct?

Thx,

Mark

[Frederic Sevestre]

Hi,
In fact the vgmap only specified the lv names (and the vg id with the option -s of the vgexport)
You should export the vg on the second machine. It is possible if it is inactive, then reimport it using the mapfile and the list of the disks :
mkdir /dev/vgxx
mknod /dev/vgxx/group c 64 0x....
vgimport -v -m mapfile vgxx /dev/vgxx/cxtyd1 /de/dsk/cxtyd2 ...
where cxtyd1 is the primary path and cxtyd2 the alternate.
You'll have the alt links on the second machine.

[Animesh Chakraborty]

Hi,
Do #strings /etc/lvmtab to check.
If alternate link is not there then you can do vgextend for adding alternate links.
Normally vgimport -s options takes care of alternate path.
make sure you are using vgimport -v -s -m /tmp/vgxx.map /dev/vgxx

Animesh

[Animesh Chakraborty]

Hi,
Please read vgexport -s
Sorry

Animesh

[Mark Henry_1]

Guys,

Thanks for all the help.

Animesh, yes, I was using the '-s' option on the export and import and no, a strings on lvmtab didn't show up the alt link.

Frederic, I'll give it a shot - I wasn't specifying the PV's on the import. Is there an easy way to know precisely which PV's on node2 correspond to the PV's on node1 given they could be on different controller #'s?

Thx,

Mark

[Animesh Chakraborty · Accepted solution]

Hi
Normally it is not required to give pv name
while importing vg if you exported with -s option.
In your case I guess 2nd node can not see the alternate path.
Can you do a ioscan -kfnC disk
and make sure that you can see both the path.
Tip. Total number of disks(except internal disks)will be double as per actual number.
If you are using EMC disk it is very easy to identify the disk with inq command.
Regards
Animesh

[Mark Henry_1]

Animesh,

You got it - I'm not seeing anything through the other controller on ioscan - check the hardware first!

Guys, sorry for wasting your time,

Thanks,

Mark

[Frederic Sevestre]

Hi,

Using the -s doesn't require the pv names. The problems is that you can't choose which path will be the primary and which one will be the alternate.
Giving the pv names allow you to choose. So you can use the cx as primary and cy as alternate for the first disk and cy as primary and cx for the second.
It can be usefull sometime.
Fr??d??ric

[Animesh Chakraborty]

Hi
As our peer stated :---John Bolene


October 26, 2001 12:49 PM GMT [ N/A ]

--------------------------------------------------------------------------------
And remember to assign points if this info has helped.

We only work for peanuts, throw a few.

Thanks

[Sanjay_6]

Hi Mark,

The Cxtydz info should be the same on both the nodes for you to export a vg from one node and import it on the other node. for this your "ioscan -fnC disk" output for the set of disk involved in this Vg should be same.

The instance of the controller matters when you define links to a VG on different systems.

hoep this helps.

Regds

[Mark Henry_1]

Frederic,

Turned out to be a bad gbic on the FC card.

The hardware path on both machines is identical, but the special files they create are different.. (on one machine /dev/dsk/c12t0d1 and /dev/dsk/c10t0d1, on the other /dev/dsk/c12t0d1 and /dev/dsk/c14t0d1)

And it works! It would appear the vg map info transfer is not dependent on the PV names?

Mark