<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 12:32 PM, Jonas Israelsson <span dir="ltr"><<a href="mailto:jonas.israelsson@elementary.se" target="_blank">jonas.israelsson@elementary.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
</span>I could indeed, the issue I saw yesterday is resolved already. I was
merely thinking we might have a potential single point of failure
here. <br>
While the primary nameserver was offline the machine (where the
ovirt-engine is running) itself had no problem doing
name-resolution, still oVirt-ui was acting rather unpleasant.<br>
And since my changes to resolv.conf only had an impact after
restarting the engine I thought there are some internals, such as a
cache causing this problem.</div></blockquote><div><br></div><div>It was only a suggestion, I didn't try myself with ovirt-engine.</div><div>But if you have a test system, you can simulate running something like this on your engine server</div><div><br></div><div>change resolv.conf while engine is running</div><div><br></div><div>silently drop connections to primary dns server with</div><div>iptables -I OUTPUT -d your_primary_dns_ip -j DROP</div><div>(at the end of tests you delete the rule checking the line number of the inserted line (it should be 1 because of "-I" option above) with</div><div>iptables -L -n --line-numbers </div><div>and then</div><div>iptables -D OUTPUT 1</div><div>or in general</div><div>iptables -D OUTPUT N </div><div>if line is not 1 but N</div><div>)</div><div><br></div><div>you can then monitor calls to dns with tcpdump, something like</div><div>tcpdump -nn dst port 53</div><div><br></div><div>HIH debugging,</div><div>Gianluca</div></div></div></div>