11:17 a.m.
Greetings.
We are under the impression if the machine that runs the oVirt-engine
looses it's primary nameserver, the oVirt web-ui becomes more or less
unresponsive.
By primary I mean the nameserver at the top of resolv.conf
In 3.x it was a disaster, 4.0 is far better, but for instance trying to
import storage domains just gives you a spinning wheel when it's
searching for nfs-domains to display.
By reorder the nameservers in resolv.conf we got it working yesterday
during our 3.6 ---> 4.0 migration.
Could someone confirm this, please ?
Brgds,
Jonas
12:34 p.m.
On Thu, Oct 27, 2016 at 10:17 AM, Jonas Israelsson <
jonas.israelsson(a)elementary.se> wrote:
Greetings.
We are under the impression if the machine that runs the oVirt-engine
looses it's primary nameserver, the oVirt web-ui becomes more or less
unresponsive.
By primary I mean the nameserver at the top of resolv.conf
In 3.x it was a disaster, 4.0 is far better, but for instance trying to
import storage domains just gives you a spinning wheel when it's searching
for nfs-domains to display.
By reorder the nameservers in resolv.conf we got it working yesterday
during our 3.6 ---> 4.0 migration.
Could someone confirm this, please ?
Yes, in order to correctly work, oVirt requires a working DNS also for
reverse resolution.
Brgds,
Jonas
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:42 p.m.
This is a multi-part message in MIME format.
--------------4AA68191197AEBF1E730D066
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 27/10/16 11:34, Simone Tiraboschi wrote:
On Thu, Oct 27, 2016 at 10:17 AM, Jonas Israelsson
<jonas.israelsson(a)elementary.se
<mailto:jonas.israelsson@elementary.se>> wrote:
Greetings.
We are under the impression if the machine that runs the
oVirt-engine looses it's primary nameserver, the oVirt web-ui
becomes more or less unresponsive.
By primary I mean the nameserver at the top of resolv.conf
In 3.x it was a disaster, 4.0 is far better, but for instance
trying to import storage domains just gives you a spinning wheel
when it's searching for nfs-domains to display.
By reorder the nameservers in resolv.conf we got it working
yesterday during our 3.6 ---> 4.0 migration.
Could someone confirm this, please ?
Yes, in order to correctly work, oVirt requires a working DNS also for
reverse resolution.
Well it's not like the machine (nor oVirt) doesn’t have a
working DNS.
My point is, I'm under the impression it only uses one (the first) from
resolv.conf and ignores the rest.
Rgds,
Jonas
--------------4AA68191197AEBF1E730D066
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 27/10/16 11:34, Simone Tiraboschi
wrote:<br>
</div>
<blockquote
cite="mid:CAN8-ONrPXnyJb2wT1w1iS-q8FrUbg3Ss-_2hjJ9Of2jKi9SDnw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Oct 27, 2016 at 10:17 AM,
Jonas Israelsson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jonas.israelsson@elementary.se"
target="_blank">jonas.israelsson(a)elementary.se</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">Greetings.<br>
<br>
We are under the impression if the machine that runs the
oVirt-engine looses it's primary nameserver, the oVirt
web-ui becomes more or less unresponsive.<br>
<br>
By primary I mean the nameserver at the top of resolv.conf<br>
<br>
In 3.x it was a disaster, 4.0 is far better, but for
instance trying to import storage domains just gives you a
spinning wheel when it's searching for nfs-domains to
display.<br>
<br>
By reorder the nameservers in resolv.conf we got it
working yesterday during our 3.6 ---> 4.0 migration.<br>
<br>
Could someone confirm this, please ?<br>
<br>
</blockquote>
<div><br>
</div>
<div>Yes, in order to correctly work, oVirt requires a
working DNS also for reverse resolution.</div>
</div>
</div>
</div>
</blockquote>
Well it's not like the machine (nor oVirt) doesn’t have a working
DNS. My point is, I'm under the impression it only uses one (the
first) from resolv.conf and ignores the rest.<br>
<br>
Rgds,<br>
Jonas<br>
<br>
<br>
</body>
</html>
--------------4AA68191197AEBF1E730D066--
1:10 p.m.
On Thu, Oct 27, 2016 at 11:42 AM, Jonas Israelsson <
jonas.israelsson(a)elementary.se> wrote:
On 27/10/16 11:34, Simone Tiraboschi wrote:
On Thu, Oct 27, 2016 at 10:17 AM, Jonas Israelsson <
jonas.israelsson(a)elementary.se> wrote:
> Greetings.
>
> We are under the impression if the machine that runs the oVirt-engine
> looses it's primary nameserver, the oVirt web-ui becomes more or less
> unresponsive.
>
> By primary I mean the nameserver at the top of resolv.conf
>
> In 3.x it was a disaster, 4.0 is far better, but for instance trying to
> import storage domains just gives you a spinning wheel when it's searching
> for nfs-domains to display.
>
> By reorder the nameservers in resolv.conf we got it working yesterday
> during our 3.6 ---> 4.0 migration.
>
> Could someone confirm this, please ?
>
>
Yes, in order to correctly work, oVirt requires a working DNS also for
reverse resolution.
Well it's not like the machine (nor oVirt) doesn’t have a working DNS. My
point is, I'm under the impression it only uses one (the first) from
resolv.conf and ignores the rest.
Not really, the default behavior is:
(The algorithm used is to try a name server, and if the query times out,
try the next, until out of name servers, then repeat trying all the name
servers until a maximum number of retries are made.)
From:
https://linux.die.net/man/5/resolver
That's why you see delays if the first DNS entry is not correctly working.
Rgds,
Jonas
1:19 p.m.
On Thu, Oct 27, 2016 at 11:42 AM, Jonas Israelsson <
jonas.israelsson(a)elementary.se> wrote:
Well it's not like the machine (nor oVirt) doesn’t have a working DNS. My
point is, I'm under the impression it only uses one (the first) from
resolv.conf and ignores the rest.
Rgds,
Jonas
Can you try if these settings inside /etc/resolv.conf can make oVirt engine
web uo work better?
options rotate
options timeout:1
options attempts:1
Please note that nslookup and dig commands seem not to go through these
settings if you change them.
But if you use eg ping command you can see they work as expected (at least
the rotate one).
1:32 p.m.
This is a multi-part message in MIME format.
--------------EF578D2809121361A4CDCB0B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Can you try if these settings inside /etc/resolv.conf can make oVirt
engine web uo work better?
options rotate
options timeout:1
options attempts:1
Please note that nslookup and dig commands seem not to go through
these settings if you change them.
But if you use eg ping command you can see they work as expected (at
least the rotate one).
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.
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.
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.
I can't say for sure if this was due to long delays, but some operations
in the UI, I was waiting for several minutes before cancelling. And I
believe that is more than enough time for the OS to try a second
nameserver.
But this could by all mean have something to do with my
infrastructure/setup. So let me do some more digging, and if I'm wrong,
my apologies for the noise.
Brgds,
Jonas
--------------EF578D2809121361A4CDCB0B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:CAG2kNCzEvR9fR-xwrYxYooMEFV2EVvBYzgVZ=HE=oCObpucP-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Can you try if these settings inside /etc/resolv.conf
can make oVirt engine web uo work better?</div>
<div><br>
</div>
<div>options rotate<br>
</div>
<div>options timeout:1</div>
<div>options attempts:1</div>
<div><br>
</div>
<div>Please note that nslookup and dig commands seem not to
go through these settings if you change them.</div>
<div>But if you use eg ping command you can see they work as
expected (at least the rotate one).</div>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
I can't say for sure if this was due to long delays, but some
operations in the UI, I was waiting for several minutes before
cancelling. And I believe that is more than enough time for the OS
to try a second nameserver. <br>
<br>
But this could by all mean have something to do with my
infrastructure/setup. So let me do some more digging, and if I'm
wrong, my apologies for the noise.<br>
<br>
Brgds,<br>
Jonas<br>
</body>
</html>
--------------EF578D2809121361A4CDCB0B--
1:48 p.m.
On Thu, Oct 27, 2016 at 12:32 PM, Jonas Israelsson <
jonas.israelsson(a)elementary.se> wrote:
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.
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.
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.
It was only a suggestion, I didn't try myself with ovirt-engine.
But if you have a test system, you can simulate running something like this
on your engine server
change resolv.conf while engine is running
silently drop connections to primary dns server with
iptables -I OUTPUT -d your_primary_dns_ip -j DROP
(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
iptables -L -n --line-numbers
and then
iptables -D OUTPUT 1
or in general
iptables -D OUTPUT N
if line is not 1 but N
)
you can then monitor calls to dns with tcpdump, something like
tcpdump -nn dst port 53
HIH debugging,
Gianluca
2948
days inactive
2948
days old
6 comments
3 participants
participants (3)
-
Gianluca Cecchi -
Jonas Israelsson -
Simone Tiraboschi