Home / server / Questions / 342819
Accepted
Kendall
Asked: 2011-12-21 09:08:45 +0800 CST

Pacemaker behavior colocation Xen domU resources, is this expected?

  • 772

I am using Pacemaker+OpenAIS+Corosync on OpenSuSE 11.3 running Xen, and am trying to determine if the behavior I see when colocating Xen domU resources is expected or not.

Cluster nodes / dom0: xen01-primary xen01-secondary

Xen domUs / Pacemaker resources: xen-db01 xen-db02

xen-db01 and xen-db02 should not run on the same dom0. Pacemaker configuration can be seen at http://pastebin.com/5NnPExkm but I have the following colocation rule: colocation xen-db -inf: xen-db01 xen-db02

The output of crm_mon after starting each Xen resource is at http://pastebin.com/vX85TLTP. Below is a brief description of the observed Pacemaker behavior.

edit: Since the full cibadmin output may be helpful, I have made it available at: http://pastebin.com/h38xCYby

After starting the first domU resource, it seems that when the second domU resource is started, Pacemaker tries to start them both on the same dom0, and then migrates one away. Notice how xen-db01 is originally located on xen01-primary, and when xen-db02 is started, xen-db01 is moved to xen01-secondary, and then it tries to move back to xen01-primary, which fails. Also, I am curious if the errors displayed in the output of crm_mon after starting the second domU are normal.

I sort of suspect that this is how it is supposed to work, but I want to be sure before getting too far with it.

Thanks,

Kendall

xen linux cluster pacemaker openais

1 Answers

  1. Best Answer

    Well, this is what happens when you don't read the manual carefully. The colo constraint

    colocation xen-db -inf: xen-db01 xen-db02

    means that xen-db01 will be placed relative to xen-db02. So really I should have been starting xen-db02, and THEN xen-db01. Doing

    crm resource start xen-db02
crm resource start xen-db01

    starts the resources normally, places them on opposite nodes, and does so without any migration back and forth.

    Thanks to Florian Haas for pointing this out.

    • 2