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
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
