[Pacemaker] Problem with Xen live migration

[Vladislav Bogdanov]

18.01.2011 15:41, Vadym Chepkov wrote:

...

>>>
>>> I have tried it myself, but concluded it's impossible to do it reliably with the current code.
>>> For the live migration to work you have to remove any colocation constraints (group included) with the Xen resource.
>>> drbd code includes a "helper" script - /etc/xen/scripts/block-drbd, but this script can't be used in pacemaker environment, 
>>> because it is not cluster aware. And pacemaker is not handling this scenario at the moment:
>>> When Xen on drbd is stopped - both drbd nodes are secondary - makes pacemaker "unhappy".
>>> You need to have both drbd nodes as primary during migration only, 
>>> but if you specify master-max="2", then both drbd nodes are primary all the time - disaster waiting to happen.
>>
>> Unless clustered LVM locking is enabled and working:
>> # sed -ri 's/^([ \t]+locking_type).*/    locking_type = 3/'
>> /etc/lvm/lvm.conf
>> # sed -ri 's/^([ \t]+fallback_to_local_locking).*/
>> fallback_to_local_locking = 1/' /etc/lvm/lvm.conf
>> # vgchange -cy VG_NAME
>> # service clvmd start
>> # vgs|grep VG_NAME
>>
>> Of cause, this may vary from one distro to another.
> 
> unfortunately, this is not available on Redhat 5 and this is where Xen is used, since  Redhat 6, Fedora dropped Xen support.
> But out of curiosity, how would clvmd prevent you from starting Xen VM on both nodes accidentally?

It will not. This is a job for CRM. It will just allow you to safely
operate on LVM VG on both nodes - create, delete, activate, deactivate
LVs (like ocfs2 allows you to safely operate on filesystem itself on
both nodes).
Although, you can use exclusive locks (vgchange -aey), but this will
make live migration impossible.

I also first tried to go with RHEL5, but it has number of unresolvable
problems with cluster components (mainly - DLM has no support for
userspace cluster stacks), so I switched to F13 and will probably try
RHEL6 (or CentOS6).