I have two specific questions about setting up multiple STONITH resources that are capable of killing the same node. I'm running Pacemaker 1.1.6-3 on Red Hat Enterprise Linux 6.2 with a cluster of two nodes, both KVM VMs.
My intent is to actually have three stonith resources for each node/VM: - one using fence_virsh that reaches the VM's hypervisor via network A; - one using fence_virsh that reaches the VM's hypervisor via network B; and - one that uses fence_ilo to power off the VM's hypervisor via a direct connection to its ILO (lights out) controller. I set each of the above with increasing values for their meta 'priority' attributes. The idea was that each would be used in turn until one succeeded, in the order as listed above. However I find that, in multiple tests, the third (fence_ilo) is being called, every time. Which is a pain, because there are other VMs on the hypervisor which I'd like to keep running. That's why that stonith resource has the lowest effective priority (with the highest priority value), so the others would be called first. I've reversed the order of priority values, thinking that maybe the documentation is wrong, that maybe higher priority values mean a higher overall priority, but nothing changed. So my questions are: 1. Does stonith actually take any notice of the 'priority' meta attribute? Is there any way I can set things up to ensure a particular order for the execution of stonith agents? 2. If, in a fencing operation, the first stonith resource is used - and fails to fence the device - will pacemaker then proceed to try with the second stonith resource? Or will it just try the first one again? (I'm wondering if I have to setup failure counts/thresholds or the like to prod pacemaker into moving onto the next one). If there's any documentation out there about ordering stonith agents I'd really appreciate some pointers. As it stands I don't see any way I can implement an ordered list of stonith resources as per my list above. :-( Many thanks for any help. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
