On Tue, 25 Sep 2018 08:19:55 +0300 Edward Haas <eh...@redhat.com> wrote:
> On Mon, Sep 17, 2018 at 11:50 AM, Gianluca Cecchi <gianluca.cec...@gmail.com > > wrote: > > > On Sun, Sep 16, 2018 at 7:56 AM Edward Haas <eh...@redhat.com> 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. > Changing the DNS on the Network does immediately causes setup-network commands to be sent to all hosts, after a big warning is shown in web UI. > > > > > > [...] > > > > 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) > > It is possible to overwrite the DNS per host. This will be reported as 'out-of-sync'. You can explicitly mark the DNS setting of a host as synchronized to the network. > > > > > > > [...] > [...] > [...] > >> 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. > Maybe I did not get the point here. Except a scenario of adding a host with FQDN instead of IP address to host engine, I am not aware of a scenario to make the host unreachable for engine by changing the DNS on the hosts. > > > > [...] > [...] > [...] > > > > 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 > > _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/72KB7JPPPPPVAKD5NEF2JZUC5V65E63G/
