[Pacemaker] Manging Virtual Machine's resource

Andrew Beekhof beekhof at gmail.com
Wed May 21 11:31:53 EDT 2008

On May 21, 2008, at 5:20 PM, Serge Dubrouski wrote:

>>>> 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 depend on what you are building. In case of cluster of Dom0s (like
> one discussed here) you are right. In this case VMs themselves are
> resources of the cluster and in most cases they don't run
> Herabeat/Pcaemaker at all. But if you are building a cluster of DomUs
> (no Pacemaker on Dom0s), and this case is widely used too, there is a
> lot of sense to have a STONITH plugin on those DomUs and use Dom0s as
> a STONITH device.

Right. Thats what the vmware plugin does/assumes.
An earlier comment made me think that the dom0's were going to be part  
of the cluster.

>> 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.
> -- 
> Serge Dubrouski.
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker

More information about the Pacemaker mailing list