<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 20, 2020 at 11:45 AM Klaus Wenninger <<a href="mailto:kwenning@redhat.com">kwenning@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 7/20/20 10:34 AM, Andrei Borzenkov
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div style="font-family:arial,sans-serif"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The cpg-configuration sounds interesting as well. Haven't
used<br>
it or looked into the details. Would be interested to hear
about<br>
how that works.<br>
</blockquote>
<div><br>
</div>
<div>
<div style="font-family:arial,sans-serif">It maintains a registry of VM
location (each fence_virtd polls local hypervisor at
regular intervals) and forwards fencing request to
appropriate host via corosync interconnect. It is also the
only backend that can handle host failure - if it is known
that host left cluster, any VM on this host is considered
fenced by definition.</div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif">It requires that hosts are
configured in pacemaker cluster themselves (to handle host
outage it must be properly fenced).<br>
</div>
</div>
</div>
</div>
</blockquote>
That sounds definitely interesting.<br>
Are you saying that the hosts have to be pacemaker-nodes as well?<br></div></blockquote><div><br></div><div><div style="font-family:arial,sans-serif" class="gmail_default">cpg backend requires a working corosync cluster (it is using it as transport). It responds to "node joined" and "node left" events. So the question is when "node left" is generated. My understanding so far was that for unavailable node to be considered "left cluster" node must be fenced. If I am wrong, pacemaker is not needed. If fencing is required, I am not aware how it can be implemented without pacemaker.</div><div style="font-family:arial,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,sans-serif" class="gmail_default">In any case, it is a completely separate cluster, so "as well" is not applicable.<br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Otherwise we might be able to just add them to corosync and
configure<br>
them not to vote on quorum ...<br></div></blockquote><div><br></div><div><div style="font-family:arial,sans-serif" class="gmail_default">These clusters are on different levels. Consider multi-tenant deployment. Each VM cluster has separate owner, and is managed independently. There is no reason to integrate it into underlying host cluster. Host cluster is managed by provider, not by tenant.<br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
... the same knet might then even be used to connect the bridges<br>
on the hosts with each other on layer-2 ...<br></div></blockquote><div><br></div><div><div style="font-family:arial,sans-serif" class="gmail_default">With distributed backend you do not need any network connectivity between host and guest at all - just contact local hypervisor via local channel. That is actually more secure.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
</div>
</blockquote></div></div>