Serviceguard Mission Critical problem

[Filippo_1]

Geoff,

Yes I can activate the VG manually but I can't use "vgchange -C .." because the cluster isn't UP. And all commands to delete.. apply and so on hangs on "Gathering Storage information.." because the current C_T_D_ is different from the one on the cluster's binary file.

I'am really tring to find out some kind of solution.. and if all my effords doesn't solve the problem I'll have to reinstall the OS..

Regards,

Filippo

[Jov]

Hi Flippo,

Have you verified all the disk paths shown by the OS valid?

I mean at the boot prom (Boot_Admin) are all the physical paths there and valid?


Jov

[Devender Khatana]

Hi,
You are mentioning the errorin cmapplyconf. Have you tried cmdeleteconf? Does it work or not? If not what is the error?

You can try the same even after exporting all the VG's as well.

HTH,
Devender

[Mark Nieuwboer · Accepted solution]

Filippo,

you don't need to reinstall the OS.
First activate your volumegroups with #vgchange -a y
then #cmdeleteconf on all the serviceguard nodes to remove the binary file of serviceguard.
now do #cmquerycl -v -C /etc/cmcluster/clust1.config -n -n

Now complie the configuration file.
see also http://docs.hp.com/en/B3936-90079/ch05s06.html

after you configure it correctly
do a #cmcheckconf -k -v -C /etc/cmcluster/clust1.config
transport the binary to the other nodes
cmapplyconf -k -v -C /etc/cmcluster/clust1.config

After this deactivete all serviceguard volume groups with #vgchange -a n
make the volumegroup cluster aware.
#vgchange -c y
start the cluster.

after this you can recompile your packeges.

grtz. Mark

[Stephen Doud]

You indicated that you vgimported the cluster VGs. You do not need to activate them to decluster them. Use 'vgchange -c n ' to remove the cluster identification from them. Then activate them in standard mode, (-a y). If that works, remove the cluster binary /etc/cmcluster/cmclconfig from all nodes in the cluster. Doing both declustering the VGs and removing the cluster binary effectively removes any trace of the old cluster (other than the configuration files). Activate all shared VGs (now that they are "standard" VGs) on one node, and perform a cmcheckconf on the cluster configuration file to see how far you get.

[Lolupee]

could you please, cut and paste the command and the error message.

[Harjit]

It's little late, and the situation is not exactly the same. For a new cluster build, FC cables on one of my nodes were swapped. This resulted in same device files names but different HW paths on one node. After having identical FC connections to each node from the disks (in this case we have two DS2405 daisy chained), I removed the old /dev/dsk/cxtxdx and /dev/rdsk/cxtxdx files and rebooted. After a manual 'insf -e', system created new targets and now my HW paths matched but device files did not.
After much trial and error this was the solution:
cp /etc/ioconfig /etc/ioconfig_old
cp /stand/ioconfig /stand/ioconfig_old
rm /etc/ioconfig /stand/ioconfig

shutdown -yr 0

When the system came back, issue 'insf -e.'
Both systems now have identical HW paths and disk device files.

Not sure if I had to remove /stand/ioconfig.
I should have zeroed out /etc/ioconfig instead of deleting it. System tried to run insf at reboot, but complained "insf: Unable to lock /etc/ioconfig - : /etc/ioconfig - permission denied."

But solution worked.

Two rp3440's running 11.23.