<p>Thanks for the info. I am committed to help on this, but I don&#39;t know where to start... Can you point me on the right direction? </p>
<p>Thanks, </p>
<p>Jode</p>
<div class="gmail_quote">El 04/11/2011 17:11, &quot;Perry Myers&quot; &lt;<a href="mailto:pmyers@redhat.com">pmyers@redhat.com</a>&gt; escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; As one of my priorities on a virtualization platform is to offer HA, I<br>
&gt; wanted to know how does it work on the ovirt architecture. I mean, I my<br>
&gt; management node fails, is HA still running on the ovirt-nodes (is<br>
&gt; distributed ) or is it manager dependent?<br>
<br>
Right now if the oVirt Engine server fails, HA of the guests running on<br>
oVirt Nodes will not work.  This is because the oVirt Engine is what<br>
coordinates monitoring and restart of the guests marked as HA.<br>
<br>
Today, the best way to protect against that double-failure is to provide<br>
HA for the oVirt Engine itself.  This can be done by setting up a 2 node<br>
HA cluster via a HA stack like Pacemaker or RHEL Clustering.  Pacemaker<br>
is in lots of distributions, so this is a fairly ubiquitous way of<br>
providing HA for non-HA aware services.<br>
<br>
In the future, the goal is to make the oVirt Engine HA aware via<br>
something similar to JBoss clustering combined with database<br>
replication/clustering.  This will remove the need for a separate HA stack.<br>
<br>
Also, my understanding is that the roadmap for vdsm is to provide it<br>
with more intelligence/policies so that it can take care of some of the<br>
HA features even in the absence of the oVirt Engine running.<br>
<br>
The enhanced vdsm for policy/HA is a roadmap item, as is making the<br>
Engine HA aware.  We could certainly use help implementing those items :)<br>
</blockquote></div>