[Pacemaker] Manging Virtual Machine's resource

Xinwei Hu hxinwei at gmail.com
Wed May 21 06:31:04 EDT 2008

2008/5/21 Andrew Beekhof <beekhof at gmail.com>:
> On May 21, 2008, at 8:10 AM, Nitin wrote:
>> On Wed, 2008-05-21 at 11:13 +0800, Xinwei Hu wrote:
>>> We had a deployment of this kind running for more then a half year.
>>> 2 lessons we had so far:
>>> 1. Start a "standalone" heartbeat inside VM is the best option so far.
>>>  i.e "ucast lo" in ha.cf
>>>  It's the simplest way to have monitoring and restarting inside VM.
>> Yes. we thought of that but want to use it as the last resort.
>>> 2. Manage VMs as Xen resources in a cluster of all dom0.
>>>  However,
>>>  a. VMs might be migrated between dom0s anytime, so set dom0 as a
>>> parameter to STONITH plugin is not ideal in practice. (The same
>>> problem applies to VMware ESX server also.)
> Why even set a dom0 name?
> Just have a clone that only runs on physical machines (use a node attribute)
> and have the STONITH plugin examine its own list of nodes it can fence (the
> vmware STONITH plugin does something like this).
> It makes no sense for VMs to run a STONITH resource (assuming they're part
> of the cluster - I'm not 100% sure what you're proposing), since the only
> method of communication to the STONITH device (dom0) is inherently
> unreliable (ie. ssh/telnet).

I'm not talking about a mixed cluster of VM and physical servers. ;)
So yes, you still have to set dom0 name for STONITH.
Plus, I didn't managed to run pacemaker on VMware ESX server. :P

> Sidenote: Yes, I have been known to advocate using ssh-based STONITH plugins
> - but only in cases where there is no alternative.
> In this case there is a viable alternative, the dom0 hosts.
> Writing a STONITH plugin is not the hard part of having a mixed physical+VM
> cluster... it gets "interesting" when you start thinking about cases like:
> what happens when a cluster split happens and a minority of the physical
> nodes are able to shoot the larger set of physical nodes because they have
> enough VMs to steal quorum, or: Can VMs shoot physical machines?  How does
> it know not to shoot the one it's running on!
Yes, and that's why I switch back to the simplest solution :)

>>>  b. VM is a typical example that we'd better support "inheritance"
>>> for RA. VM's RA can only tell whether it's running, but there're
>>> different ways to tell if the OS (Linux, BSD, Windows, Netware) inside
>>> is health.
> I don't understand how attribute inheritance could possibly hide the
> differences between operating systems.
I mean function inheritance and override.
>> If this "inheritance" implementation can bring proportionate value then
>> let us implement it. Lon Hohberger has already shown interest in this.
>> May I request to Andrew Beekhof and other veterans :) to advise on
>> implementation complexity versus use of this feature.
>> Thanks for sharing your valuable experience.
>>> My .2c
>>> 2008/5/19 Andrew Beekhof <beekhof at gmail.com>:
>>>> On May 19, 2008, at 7:14 AM, Nitin wrote:
>>>>> On Fri, 2008-05-16 at 15:08 +0200, Andrew Beekhof wrote:
>>>>>> On May 16, 2008, at 3:04 PM, Nitin wrote:
>>>>>>> Hello,
>>>>>>> I would like to make my virtual machines (DomUs) resources to
>>>>>>> participate in the HA cluster. Dom0 (Physical Host) may or may not
>>>>>>> have
>>>>>>> resources.
>>>>>>> To do this I would like to treat DomUs as *resource* in the cluster
>>>>>>> as
>>>>>>> opposed to treating them as *nodes*. I am planning to write OCF
>>>>>>> resource
>>>>>>> agents for virtual machines. But I am not very sure about how to
>>>>>>> make a
>>>>>>> resource's resource to participate in the cluster.
>>>>>>> Is there any configuration in existing structure to achieve this??
>>>>>>> If no
>>>>>>> then please tell me how to go about creating a "container" resource
>>>>>>> in
>>>>>>> CRM.
>>>>>> Why not just use the Xen agent if you don't want them to be cluster
>>>>>> nodes?
>>>>>> Or do you mean that you want them to both be resources and to run
>>>>>> other resources too?
>>>>> Yes. Please advise me how to go about it.
>>>>> Thanks a lot for reply.
>>>> We don't have a clean way to do that yet
>>>> Possible options:
>>>> a) start the services at VM boot (you don't get monitoring)
>>>> b) start the services at VM boot and modify the Xen agent to monitor the
>>>> services inside the VM (ugly)
>>>> c) add a proxy resource to start/stop/monitor the services inside the VM
>>>> (complex)
>>>> d) implement a generic version of c)
>>>> e) have the VM join the cluster (makes stonith and quorum "interesting")
>>>> f) wait for us to implement clusters-of-clusters which also solves this
>>>> scenario "for free"
>>>> g) something else i've not thought of
>>> _______________________________________________
>>> Pacemaker mailing list
>>> Pacemaker at clusterlabs.org
>>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>> _______________________________________________
>> Pacemaker mailing list
>> Pacemaker at clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker

More information about the Pacemaker mailing list