[Pacemaker] recourse dos not start with one active node

hi, I have build a 2 node test cluster on debian 6 withe an IP recourse. If I start both nodes the IP recourse starts up properly. If i put one node on standby the recourse migrates to the other, but if one node gos down the recourse doesn't migrate. Also the resource doesn't start if just one nod

Re: [Pacemaker] recourse dos not start with one active node

Am 09.03.2013 um 18:15 schrieb "jonas" : > > hi, > I have build a 2 node test cluster on debian 6 withe an IP recourse. If > I start both nodes the IP recourse starts up properly. If i put one node > on standby the recourse migrates to the other, but if one node gos down > the recourse doesn't mig

[Pacemaker] A couple of queries regarding the behaviour of ocf:heartbeat:ManageVE

Hi, It looks to me like ocf:heartbeat:ManageVE might do the wrong thing in a couple of places, so I'd thought I'd check. The resource agent manages openvz containers (i.e. lightweight virtual machines AKA "VEs", think chroot++). The principle potential problem is the stop operation: The metad

[Pacemaker] A couple of SendArp resource changes

Hi, I've been using the ocf:heartbeat:SendArp script and notice a couple of issues - some problems with starting and monitoring the service, and also a file descriptor leak in the binary (which would cause it to terminate). I've detailed the problems and supplied some patches: http://bugs.debian

[Pacemaker] Ordering Constraint: Difference Between Stop and Migrate?

Dear all, Is it possible with ordering constraints to distinguish stopping a resource from migrating it to another node? I think it is not possible since the resource manager would need to know the "migration downtime" in advance but anyways I will give it a try: Given two resources A and B