Description of problem: Currently, for setting DNS configuration on static IP networks, we rely on: - 'cfg' field for reporting. - Legacy Ifcfg option passthrough in SetupNetworks with a blacklist of what can and what can't be passed through. The problem with the above approach is that it just can't work with other configurators without hooks and hacks. In order to address this, we should: - Read /etc/resolv.conf and report the dns configuration on the networks that have defaultRoute=True - Accept a dns attribute to setupNetworks network definition API that takes a possibly empty list of addresses where one can find the dns servers. This would then be processed differently by configurators: + ifcfg: Would just have it added to the top device of the network as: DNS<NUM_OF_ELEMENT> for each element in the 'dns' list. + others: Would just write each element to /etc/resolv.conf Steps to verify: 1. setupNetworks({'ovirtmgmt': {'nic': 'eth1', 'addr': '192.168.11.3', 'defaultRoute': True, 'netmask': '255.255.255.0', 'gateway': '192.168.1.1', 'dns': ['10.10.10.10', '10.10.10.11'], 'bridged': True}}, {}, {'connectivityCheck': False}) 2. cat /etc/resolv.conf 3. getVdsCapabilities and check that the ovirtmgmt network reports dns servers as a list like: ['10.10.10.10', '10.10.10.11'].
I believe this bug should be pursued with high priority, since the most typical server configuration is with static addressing. Thus, this bug affects the majority of ovirt installations, resulting in a fatal error for hosted-engine-setup which is difficult to recover from. This should be considered a serious bug, rather than a low priority feature. A fix should be provided in the earliest possible release of 3.5.1.
Previous note should have read "3.5.x"
It did not make it to 3.6, moving to 4.0. as this is an API it may be a bit more than described above especially since cluster levels are now involved (with the API changes)
Vdsm side has been merged to 4.0 branch. Engine side still needs design.
Any update on this?
please read: https://github.com/oVirt/ovirt-site/pull/456 feature page is not approved/merged yet, but REST details are present and probably (.9) final. IIUC that's what you need most, right?
Dan, any reason it cannot be in 4.2?
Moving back to 4.2, as the feature is already in final bug-fixing phase.
According to bug 1451261, setting DNS with DHCP most often ends with host out-of-sync. This can be mitigated by refreshing caps. Except this bug, I believe the feature has been implemented.
This should be part of the known issues for the DNS feature. In case of setting DNS with DHCP, most of the times ends with host out-of-sync and additional manual refresh caps is needed by the user/admin. Verified on - 4.2.0-0.0.master.20170921184504.gitfcfc9a7.el7.centos
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
*** Bug 1534290 has been marked as a duplicate of this bug. ***