[ovirt-users] Re: Best way to update dns config of ovirt node

On Mon, Sep 17, 2018 at 11:50 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > wrote: > On Sun, Sep 16, 2018 at 7:56 AM Edward Haas <ehaas(a)redhat.com&gt; wrote: > [...] [...] [...] [...] [...] [...] [...] [...] [...] >>> >>> Thanks for your answer Edward. >>> What do you mean with "network attachment window"? >>> a) Network > Networks, then select ovirtmgmt line and edit, putting DNS >>> info (that is empty right now) >>> or >>> b) Compute > Hosts, then select host1 line, click on host1 name, then >>> Network Interfaces and Setup Host Networks. then edit ovirtmgmt > DNS >>> Configuration (that is empty right now) >>> or what? >>> >> >> I meant (b). Option (a) is there to apply the same DNS entries over all >> hosts for that specific network. >> I do not see a problem of using both. >> > > OK. > What is it expected to happen if for example I have 4 active nodes and use > a)? > Possibly all of them loosing ovirtmgmt connection with possibly dangerous > effects? > I consider touching the management network always as a risk, but it should work if you do not have VM/s on it. I do not recall if changing the DNS on the Network immediately causes setup-network commands to be sent to all hosts.

> > [...] > > The strange thing is that apparently it made what you say (from a files > content point of view) but there is no match if you go into configuration > inside web admin gui pages, neither at cluster level, nor at host level. > This was what seemed strange to me. > Please notice that these hosts were installed in 4.1.x and then update > several times up to 4.2.6. > So it could be the case of some sort of bug in previous versions and not > if I plain install right now in 4.2.6 (not tested) > > > >> Upgraded systems (hosts have been added before DNS configuration was >> available) will have it empty and you will need to explicitly set it. >> > It is not my case. > We will have to check this then. We may have changed the policy on this issue due to other complaints. (An argument that we should not enforce DNS entries if not explicitly requested sounds valid to me)

> > > [...] [...] [...] >> The DNS entry are supposed to be applied immediately through ifcfg, >> rebooting is an precaution to make sure it has been correctly persisted. >> And if the management network is not serving VM/s, then no VM evacuation >> is needed. >> > > If host is not reachable through ovirtmgmt doesn't fencing take place? And > so indirect consequence a move of the VMs it had in charge? > Correct, but as far as I know it is not immediate. There is a grace period in which Engine (and VDSM) attempts to confirm connectivity. VDSM will also (try to) revert back to the previous working configuration in a "revert" action. It may also be a matter of the level of "defence" needed. As mentioned, there is a risk in touching the management network and your mentioned steps are a way to reduce the risks. But lets get another opinion on this, I may be wrong here.

> [...] [...] [...] > > This is a Red Hat case number, not a bugzilla entry. Because I had the > same kind of problems on oVirt based environments and RHV based ones that > are present. > So for RHV I opened a case. > As a consequence of the case, it was created this solution that I have not > tested yet: > https://access.redhat.com/solutions/3613731 > > Please note that it requires RH account, but in my opinion should be of > public domain or similar information put inside oVirt documentation pages. > It could happen having to change DNS and it can be useful to know the > recommended workflow for that > [...] [...] [...] [...] > Note also my comments regarding environment installed in 4.1 and then > updated to 4.2 > > Thanks > Gianluca >