old cluster config fails due to different SG versions

[Steve Post]

A while ago, we had a mc/service guard cluster (cluster1), with 2 nodes: node1 and node2. More recently, node2 had it's mc/service guard software upgraded.
So right now MC service guard both nodes is off. But the computers are running their production jobs.
Node1 is A.11.04 version of MC/Service Guard running HPUX11 on HP9000 K570.
Node2 is A.11.09 version of MC/Service Guard.running HPUX11 on HP9000 V2500.
From SAM, on node1, I try to remove node2 from cluster1. It fails because the two versions are different.
From SAM, on node2, I try to remove node1 from cluster1. It fails because the two versions are different.

I cannot easily upgrade node1's version of serviceguard. I want the old cluster1 removed because node2 is going to be part of a different, uncreated cluster. I tried make a new cluster1 with just node1 on node1. It still failed because it says "maximum packages is set to 5, but you have 3 packages." To my knowledge I have NO packages. But I USED to have two packages and lock volume groups.

I have not seen any documentation on destroying OLD mc service guard clusters. Just on making new clusters from scratch. I cannot afford to go into this blind. So, I am asking advice:
How do I trash the old cluster without losing volume groups, lan cards etc? or to put in another way???.
How do get the bone (node2) from the pit bull (cluster1), without getting bit (losing data, crashing, rebooting etc)?

[melvyn burnard]

quite simple, really.
edit your cluster ascii file, remove all reference to the unwanted node.
Do the same for all package config files.
use the cmdeleteconf command to remove the cluster binary.
cmcheckconf, cmapplyconf.
B.T.W. make sure you have SG patch installed to prevent any unwanted issues.
HTH

[Sanjay_6]

Hi Steve,

Just create a new cluster with only node1 as part of the cluster configuration. This will overwrite the current cluster cluster configuration on the node1. you don't have to remove the node2 from the cluster. Just assume that there is no cluster at present and proceed to configure a single node cluster with node1.

Hope this helps.

Regds

[Steve Post]

I did this. I'll try it again.
Perhaps there is something wrong with the way I ran it before. If I ran
"cmquery -c cluster1 -C /etc/cmcluster/cluster1.ascii -n node1"
It would die. If I ran cmcheckconf on the file it would say the number of arguments for the package size is incorrect.
I would retry it as long as it did not force a reboot, disable a lan card, export a volumegroup, unmount a filesystem, send spam to users, ....ie. fight back.

But creating and checking an unused file should not (ahem), hurt anything.
I'll let you know.

[Steve Post]

Yeah it died again. Here's what I did.
1. copied /etc/cmcluster to /etc/cmcluster.orig
2. removed pkg files and subdirectories
3. edited cmclconf.ascii file to remove node2.
4. ran cmdeleteconf (this worked)
5. cmcheckconf -v -C /etc/cmcluster/cmclconf.ascii
And I got....
Cluster cluster1 is an existing cluster
Error: package xyz.pkg requires a node that is not configured in the cluster
Error: invalid subnet 43.77.1.0 in package xyz.pkg.
Error: invalid subnet 43.77.1.0 in package 123.pkg
Maximum configured packages parameter is 5.
Configuring 2 package(s).
3 package(s) can be added to this cluster.
cmcheckconf: unable to verify cluster file:/etc/cmcluster/cmclconf.ascii. Invalid argument.

Where is it getting this package info from? It's not in the cmcluster directory or in the cmclconf.ascii file.
Any idea where it is????

[Steve Post]

Aha! Even though I do not want node2 as part of cluster1 anymore it IS STILL SEEN. As a result I can clear out the old pkg files on node1 and it will get this info from node2!

So.....
I log into node2.
cd /etc
mv cmcluster cmclister.EVIL

I log into node1 again. Now cmcheckconf works on node1.
cmapplyconf -C ./cmclconf.ascii worked too.
cmviewcl -v shows cluster1 is now devoid of packages and node2.
Thanks.

[melvyn burnard]

You got it! The reason you were getting the issue was that you were calling the new cluster by the same name, and hence the cmquerycl went out on th enetwork and found a node that belonged to a cluster of the same name.