>>> On 5/30/2008 at 11:16 AM, in message <[EMAIL PROTECTED]>, "Xinwei Hu" <[EMAIL PROTECTED]> wrote: > Hi Alain, > > For live migration, you have to make the logical volume both > available to the source > and the target server in the same time. > > So you have to use either cLVM/cEVMS or plain disk.
The volumes can be active on all nodes, so long as don't do I/O to them at the same time... which is risky... Or define a new Xen disk type, e.g. [ disk = 'lvm:/whatever' ] and instead put the logic in your RA, into /etc/xen/scripts/block-lvm Since Xen coordinates the setup/teardown of block devices; at the right time, during live migrate Hth, Robert > 2008/5/30 Alain St-Denis <[EMAIL PROTECTED]>: >> 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 >> > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
