<div dir="ltr">On Thu, Mar 3, 2016 at 9:06 AM, Dan Kenigsberg &lt;<a href="mailto:danken@redhat.com">danken@redhat.com</a>&gt; wrote:<br>&gt;<br>&gt; On Thu, Mar 03, 2016 at 12:54:25AM +0000, David LeVene wrote:<br>&gt; &gt;<br>&gt; &gt; Can you check our patches? They should resolve the problem we saw in the<br>&gt; &gt; log: <a href="https://gerrit.ovirt.org/#/c/54237">https://gerrit.ovirt.org/#/c/54237</a>  (based on oVirt-3.6.3)<br>&gt; &gt;<br>&gt; &gt; -- I&#39;ve manually applied the patch to the node that I was testing on<br>&gt; &gt; and the networking comes on-line correctly - now I&#39;m encountering a<br>&gt; &gt; gluster issue with cannot find master domain.<br>&gt;<br>&gt; You are most welcome to share your logs (preferably on a different<br>&gt; thread, to avoid confusion)<br>&gt;<br>&gt; &gt;<br>&gt; &gt; Without the fixes, as a workaround, I would suggest (if possible) to disable IPv6 on your host boot line and check if all works out for you.<br>&gt; &gt; -- Ok, but as I can manually apply the patch its good now. Do you know<br>&gt; &gt; what version are we hoping to have this put into as I won&#39;t perform an<br>&gt; &gt; ovirt/vdsm update until its part of the upstream RPM&#39;s<br>&gt;<br>&gt; The fix has been proposed to ovirt-3.6.4. I&#39;ll make sure it&#39;s accepted.<br>&gt;<br>&gt; &gt;<br>&gt; &gt; Do you need IPv6 connectivity? If so, you&#39;ll need to use a vdsm hook or another interface that is not controlled by oVirt.<br>&gt; &gt; -- Ideally I&#39;d prefer not to have it, but the way our network has been<br>&gt; &gt; configured some hosts are IPv6 only, so at a min the guests need it..<br>&gt; &gt; the hypervisors not so much.<br>&gt;<br>&gt; May I tap to what your IPv6 experience? (only if you feel confortable sharing<br>&gt; this publically). What does these IPv6-only servers do? What does the guest do<br>&gt; with them?<br>&gt;<br>&gt; &gt;<br>&gt; &gt; -- I&#39;ve now hit an issue with it not starting up the master storage<br>&gt; &gt; gluster domain - as it’s a separate issue I&#39;ll review the mailing<br>&gt; &gt; lists &amp; create a new item if its related.. I&#39;ve attached the<br>&gt; &gt; supervdsm.log incase you can save me some time and point me in the<br>&gt; &gt; right direction!<br>&gt;<br>&gt; All I see is this<br>&gt;<br>&gt; MainProcess|jsonrpc.Executor/4::ERROR::2016-03-03 11:15:04,699::supervdsmServer::118::SuperVdsm.ServerCallback::(wrapper) Error in wrapper<br>&gt; Traceback (most recent call last):<br>&gt;   File &quot;/usr/share/vdsm/supervdsmServer&quot;, line 116, in wrapper<br>&gt;     res = func(*args, **kwargs)<br>&gt;   File &quot;/usr/share/vdsm/supervdsmServer&quot;, line 531, in wrapper<br>&gt;     return func(*args, **kwargs)<br>&gt;   File &quot;/usr/share/vdsm/gluster/cli.py&quot;, line 496, in volumeInfo<br>&gt;     xmltree = _execGlusterXml(command)<br>&gt;   File &quot;/usr/share/vdsm/gluster/cli.py&quot;, line 108, in _execGlusterXml<br>&gt;     raise ge.GlusterCmdExecFailedException(rc, out, err)<br>&gt; GlusterCmdExecFailedException: Command execution failed<br>&gt; return code: 2<br><br><br>We have this logs before the exception:<br><br>MainProcess|jsonrpc.Executor/3::DEBUG::2016-03-03 11:02:42,945::utils::669::root::(execCmd) /usr/bin/taskset --cpu-list 0-39 /usr/sbin/gluster --mode=script volume info --re<br>mote-host=ovirtmount.test.lab data --xml (cwd None)<div><br></div><div>The command looks correct</div><div><br>MainProcess|jsonrpc.Executor/3::DEBUG::2016-03-03 11:02:43,024::utils::687::root::(execCmd) FAILED: &lt;err&gt; = &#39;\n&#39;; &lt;rc&gt; = 2</div><div><br></div><div>gluster command line failed in an unhelpful way.</div><div><br></div><div><div>(Adding Sahina)</div></div><div><br></div><div>David, can you try to run this command manually on this host? maybe there is some</div><div>--verbose flag revealing more info?</div><div><br></div><div>You may also try a simpler command:</div><div><br></div><div>    gluster volume info --remote-host=ovirtmount.test.lab data</div><div><br></div><div>Another issue you should check - gluster version on the hosts and on the gluster nodes *must*</div><div>match - otherwise you should expect failures accessing gluster server.</div><div><br></div><div>We have this patch for handling such errors gracefully - can you test it?</div><div><a href="https://gerrit.ovirt.org/53785">https://gerrit.ovirt.org/53785</a><br></div><div><br></div><div>(Adding Ala)</div><div> <br></div><div>Nir</div></div>