[Pacemaker] Manging Virtual Machine's resource

[Andrew Beekhof]

On May 21, 2008, at 12:31 PM, Xinwei Hu wrote:

> 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 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).
>
> I'm not talking about a mixed cluster of VM and physical servers. ;)

Ok, i misinterpreted the bit about "a cluster of all dom0"

>
> So yes, you still have to set dom0 name for STONITH.
> Plus, I didn't managed to run pacemaker on VMware ESX server. :P

Its technically possible - I do it all the time.

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

In that case, I suggest writing something similar to the vmware  
stonith module... either one specific to Xen, or ideally one that use  
libvirt that can be used for all types of VMs.

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

I've still no idea how this helps - and I don't believe this is what  
Lon was suggesting (though I may be mistaken)