<div dir="ltr"><p dir="ltr"><br>
On 23/07/2014 1:45 am, &quot;Jason Brooks&quot; &lt;<a href="mailto:jbrooks@redhat.com" target="_blank">jbrooks@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; &gt; From: &quot;Jason Brooks&quot; &lt;<a href="mailto:jbrooks@redhat.com" target="_blank">jbrooks@redhat.com</a>&gt;<br>
&gt; &gt; To: &quot;Andrew Lau&quot; &lt;<a href="mailto:andrew@andrewklau.com" target="_blank">andrew@andrewklau.com</a>&gt;<br>
&gt; &gt; Cc: &quot;users&quot; &lt;<a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a>&gt;<br>
&gt; &gt; Sent: Tuesday, July 22, 2014 8:29:46 AM<br>
&gt; &gt; Subject: Re: [ovirt-users] Can we debug some truths/myths/facts       about   hosted-engine and gluster?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ----- Original Message -----<br>
&gt; &gt; &gt; From: &quot;Andrew Lau&quot; &lt;<a href="mailto:andrew@andrewklau.com" target="_blank">andrew@andrewklau.com</a>&gt;<br>
&gt; &gt; &gt; To: &quot;users&quot; &lt;<a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a>&gt;<br>
&gt; &gt; &gt; Sent: Friday, July 18, 2014 4:50:31 AM<br>
&gt; &gt; &gt; Subject: [ovirt-users] Can we debug some truths/myths/facts about<br>
&gt; &gt; &gt;     hosted-engine and gluster?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; As most of you have got hints from previous messages, hosted engine won&#39;t<br>
&gt; &gt; &gt; work on gluster . A quote from BZ1097639<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &quot;Using hosted engine with Gluster backed storage is currently something we<br>
&gt; &gt; &gt; really warn against.<br>
&gt; &gt;<br>
&gt; &gt; My current setup is hosted engine, configured w/ gluster storage as described<br>
&gt; &gt; in my<br>
&gt; &gt; blog post, but with three hosts and replica 3 volumes.<br>
&gt; &gt;<br>
&gt; &gt; Only issue I&#39;ve seen is an errant message about the Hosted Engine being down<br>
&gt; &gt; following an engine migration. The engine does migrate successfully, though.</p><div class="gmail_default" style="font-family:tahoma,sans-serif">​​That was fixed in 3.4.3 I believe, although when it happened to me my engine didn&#39;t migrate it ju​st sat there.</div>

<p></p><p dir="ltr"><br>
&gt; &gt;<br>
&gt; &gt; RE your bug, what do you use for a mount point for the nfs storage?<br>
&gt;<br>
&gt; In the log you attached to your bug, it looks like you&#39;re using localhost as<br>
&gt; the nfs mount point. I use a dns name that resolves to the virtual IP hosted<br>
&gt; by ctdb. So, you&#39;re only ever talking to one nfs server at a time, and failover<br>
&gt; between the nfs hosts is handled by ctdb.</p>
<p dir="ltr">I also tried your setup, but hit other complications. I used localhost </p><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">​in an old setup, ​</div>previously as I was under the assumption when accessing anything gluster related,<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">

​ the connection point only provides the volume info and you connect to any server in the volume group.​</div> <p></p>
<p dir="ltr">&gt;<br>
&gt; Anyway, like I said, my main testing rig is now using this configuration,<br>
&gt; help me try and break it. :)</p>
<p dir="ltr">rm -rf /</p>
<p dir="ltr">Jokes aside, are you able to reboot a server without losing the VM ?</p><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">​ My experience with ctdb (based on your blog) was even with the &quot;floating/virtual IP&quot; it wasn&#39;t fast enough, or something in the gluster layer delayed the failover. Either way, the VM goes into paused state and can&#39;t be resumed.​</div>

 <p></p>
<p dir="ltr">&gt;<br>
&gt; &gt;<br>
&gt; &gt; Jason<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I think this bug should be closed or re-targeted at documentation,<br>
&gt; &gt; &gt; because there is nothing we can do here. Hosted engine assumes that<br>
&gt; &gt; &gt; all writes are atomic and (immediately) available for all hosts in the<br>
&gt; &gt; &gt; cluster. Gluster violates those assumptions.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; ​&quot;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; ​Until the documentation gets updated, I hope this serves as a useful<br>
&gt; &gt; &gt; notice at least to save people some of the headaches I hit like<br>
&gt; &gt; &gt; hosted-engine starting up multiple VMs because of above issue.<br>
&gt; &gt; &gt; ​<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Now my question, does this theory prevent a scenario of perhaps something<br>
&gt; &gt; &gt; like a gluster replicated volume being mounted as a glusterfs filesystem<br>
&gt; &gt; &gt; and then re-exported as the native kernel NFS share for the hosted-engine<br>
&gt; &gt; &gt; to consume? It could then be possible to chuck ctdb in there to provide a<br>
&gt; &gt; &gt; last resort failover solution. I have tried myself and suggested it to two<br>
&gt; &gt; &gt; people who are running a similar setup. Now using the native kernel NFS<br>
&gt; &gt; &gt; server for hosted-engine and they haven&#39;t reported as many issues. Curious,<br>
&gt; &gt; &gt; could anyone validate my theory on this?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; Andrew<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; Users mailing list<br>
&gt; &gt; &gt; <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
&gt; &gt; &gt; <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Users mailing list<br>
&gt; &gt; <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
&gt; &gt; <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt; &gt;<br>
</p>
</div>