wrong lock disk in vg

[Norbert Binder]

Hi!
We've got a bit of a mess in our cluster configuration. After changing the switch configuration in our SAN, our FIRST_CLUSTER_LOCK_PV /dev/dsk/c9t0d1 previously in vg510, ended up in vg530. We tried to change the cluster config file and assigned a new vg and a new lock disk to it. Both commands (cmcheckconf and cmapplyconf) seemed to lock up and we stopped them after 30 minutes. Some more information: we can see ca 1000 disks (including alternate paths).Has anybody got an idea how to deal with such a problem?

[Ross Zubritski]

Changed the switch meaning zoning or what? Can you give a little more overview of the SAN environment?

Thanks

RZ

[Frederic Sevestre]

Hi,

Did you keep your old cmclconfig ?
You should try to move cmclconfig file to an other directory from both nodes and try again the cmcheckconf and cmapplyconf.

Regards,
Fr??d??ric

[Ricardo Rocha]

Hi

When you changed your SAN config, did the device files of the disks changed? Maybe there's a not a problem with the lock disk, but with the entire disk paths.

[Norbert Binder]

Hi!

We changed our switches from open loop to fabric. This generated new device files. Unfortunately the new device files reside in different volume groups then before.

[Ricardo Rocha]

Well, do you know what is the new device file for the cluster lock disk? I guess you'll have to resctructure all the cluster, doing imports of the vg's.

[Sridhar Bhaskarla]

Hi,

I would make sure the volume group configurations are correct in the first place by taking them out of cluster. Do a "vgchange -a y" on each of them following by vgdisplay and make sure they are clean and there are no issues.

Do the same on the secondary node. Once you are sure that the VGs are properly imported without any errors, then modify your cluster config file to point to correct LOCK VG and LOCK DISK and then apply the configuration. Since you are applying the configuration anyway, it does not hurt to delete the cluster configuration and re-apply it. Otherwise, it will spend time in figuring out the differences between existing cmclconfig and the current system configuration.

Looks like you still have issues with one or more volume groups. On systems with these many disks, I do not blame cmclconfd taking this long.

-Sri

[Sridhar Bhaskarla]

Hi (Again) Norbert,

I assumed you had ServiceGuard knowledge as your message indicates. So, I didn't give you much technical details like vgchange -c n before vgchange -a y etc.,

-Sri