Hello, Since nobody paid attention to my first post, here I am again with more details...
I modified the LVM RA so it works on logical volumes instead of volume groups and made it a master/slave RA. The goal is to use heartbeat to control logical volume activation (we are using shared disks and gave up on cluster lvm) to guard ourselves against human or software error. My RA makes the logical volumes it controls available on one node only (one master, x slaves). It is working as I expect in situations involving start and stop actions, but I am scratching my head trying to figure out how to take advantage of the xen live migration feature. The following constraints don't do the job: <rsc_order id="order_xen_start" from="resource_xen" to_action="promote" to="master_lvs"/> <rsc_order id="order_xen_migrate" from="resource_xen" to_action="promote" to="master_lvs" action="migrate_to" symmetrical="false"/> <rsc_colocation id="xen_with_master_lvs" to_role="Master" from="resource_xen" to="master_lvs" from_role="Started" score="INFINITY" symmetrical="false"/> If I issue a migrate on resource_xen, I see this from pengine pengine: [13220]: notice: complex_migrate_reload: Migrating resource_xen from sss4 to sss3 which is encouraging. But at the same time, tengine says: tengine: [13219]: ERROR: te_graph_trigger: Transition failed: terminated which can't be a good sign. The master_lvs resource has clone_max = 2 clone_node_max = 1 master_max = 1 master_node_max =1 I have the feeling "master_max = 1" is not helping. If I set master_max to 2 and remove the colocation constraint above, live migration works. But this is not what I want. Is there a way to tell a master/slave resource that its master_max is 2 but only 1 will be promoted most of the time? BTW, this is with 2.1.3 and pacemaker 0.6.2. Thanks Alain Le lundi 26 mai 2008 12:44, Alain St-Denis a écrit : > Hello Linux-HA, > > I would like to set up two resources, one of which is a xen guest and the > other is a LVM2 logical volume, lets call them xenA and resB, where xenA > depends on resB. I can figure out how to set up the appopriate co-location > and order constraints for the start and stop actions, but what about > migrate_to and migrate_from? While live migration occurs, two instances of > resB must be running. The RA associated with resB only does "lvchange -a y > LV" on start and "lvchange -a n LV" on stop. > > If anyone can send pointers on how to achieve the following: > > xenA and resB are running on node1 > a live migration is initiated to node2 > resB starts on node2 but keeps running on node1 > xenA migrates to node2 > resB is stopped on node1 > xenA and resB are running on node2 > > I'd appreciate it. Any information on how the migrate_to and migrate_from > actions are implemented would also be useful. It seems to me defining those > actions for the resB RA may be the thing to do, as long as co-location and > order constraints can be set for those actions. > > Thanks in advance, > > Alain -- Alain St-Denis Supercomputing, Systems and Storage Canadian Meteorological Centre Meteorological Service of Canada Environment Canada Tel: +1 514 421 4697 _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
