[Pacemaker] Manging Virtual Machine's resource

[Andrew Beekhof]

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 127.0.0.1" 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).

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!


>>   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.

>>
>
> 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