Problem with CMAN on Bootup

[ejc317]

This is turning into a serious problem and I think it's the way these servers communicate with each other - it's so buggy - maybe should implement an agent like cloudstack ...

1 of 4 servers in our node will ALWAYS fail starting cman on bootup - it will then say

dlm: no local IP address has been set
dlm: cannot start dlm lowcomms

Then we have to manually restart cman then RGManager

Also,

the HA doesn't work right. We've taken off lanplus which made no difference although it was less buggy but basically the nodes won't move to other servers and just clump all onto 1 server

 

[dietmar]

Seems you start new threads for the same problem? Is this the same problem?

http://forum.proxmox.com/threads/11945-HA-Fencing-Issue

If so, please can you try to use one thread for one problem.

 

[ChuckSpaeth]

I found some interesting information regarding this very issue. I have this problem on my systems while using qdisk. It is related to not being able to establish quorum and has been fixed in a RHEL5.1 release. I hope Dietmar can get this into the code as soon as possible. I would like to get my quorum stable as I am sure all others using a quorum disk.

<SNIP>
Lon Hohberger 2008-03-06 16:36:10 EST
Actually, it's not exactly as described: the quorum forms, but clvmd fails to set up LVs because a quorum hasn't formed before clvmd comes up, which then causes GFS volumes to be inaccessible when the 'gfs' init script is started. We employed a fix on a test cluster which simply involves reversing the start order of cman and qdiskd. Because fenced waits up to 5 minutes (by default) for a quorum to form, qdiskd can actually cause quorum formation while fenced is waiting. This of course allows clvmd to start correctly (the first time!), which, in turn allows gfs file systems to be mounted immediately. The original reason qdiskd was started after cman was two-fold: (a) cman was required for qdiskd to run, and (b) qdiskd might need clvmd, so it should start after it In RHEL5, clvmd is started at level 24 while qdiskd is started at 22. Therefore, (b) won't occur - and since it is not supported anyway, this is ok. As of RHEL5.1, qdiskd can start and wait indefinitely for CMAN to come up before operating in any useful capacity, so the requirement for (a) is negated. It is my belief that because the cman and qdiskd init scripts are placed in the same package, we can reverse their ordering safely.

<SNIP/>