Just in time, when i was about to implement STNITH on myself. :-)
Oh and thank you Lars for doing the bug report!
Meanwhile i noticed that with store 0 on ordering it didn't restart (i
see you noticed that too in your bug report).
Now i just need to wait for repo i'm using to get new versions:
clusterlabs High
Availability/Clustering server technologies
(epel-5) enabled: 69
Regards,
M.
Lars Ellenberg wrote:
On Sun, Jan 03, 2010 at 09:12:28PM -0700, hj lee wrote:
On Sun, Jan 3, 2010 at 11:14 AM, Martin Gombač <mar...@isg.si> wrote:
Hi,
i removed colocation constraint per your suggestion.
Please find other requested information attached.
As logs show ibm1 restarted resource Hosting, when ibm2 was shut down,
while leaving underlying drbd resource promoted. I wish the restart
would never happen, as there is no need for it.
Please let me know if i should provide any additional info.
Thank you.
I think the order constraint caused the restarting of XEN Hosting resource.
You can prove my assessment by removing order constraint. After removing
order constraint, try the same test. XEN Hosting resource should be OK.
Please see this document
http://www.clusterlabs.org/mediawiki/images/a/ae/Ordering_Explained_-_White.pdf.
I think you have two choices.
1. Try to use uni-directional ordering constraint by setting
symmetrical=false as explained in the above document. I never done this, so
not sure how to set it or it will work or not.
2. Remove all drbd resources and start drbd by service. Configure drbd dual
primary in drbd.conf(I think you done this already) and enable drbd service
by chkconfig. So drbd will be started when the system is booting. Please
make sure drbd is started before heartbeat service.
lf#2153 seems to be relevant, and has been fixed today.
http://developerbugs.linux-foundation.org/show_bug.cgi?id=2153
_______________________________________________
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
