Description of problem: When BOOTPROTO=dhcp do NOT put DNS explicitly into ifcfg-$network. This is what vdsm does, this is against logic of DHCP networking model. If one uses DHCP then why vdsm is manually explicitly changing settings? This breaks any changes which would be done on DHCPd and propagated to DHCP clients (hosts) in next DHCPOFFER. Example: - DHCPd sends 10.0.0.1 in 'domain-name-servers' option in DHCP data payload - vdsm steps into game - DHCPd is reconfigured to send 10.0.0.2 in 'domain-name-servers' option in DHCP data payload - (host) DHCP clients sends DHCPREQUEST based on expiration time - DHCPd sends DHCPOFFER with new IP for DNS! - vdsm host still uses old IP because it is configured in ifcfg-$network Version-Release number of selected component (if applicable): vdsm-4.19.28-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. have host with dhcp configuration 2. add host into engine 3. check ifcfg-$network file and /etc/resolv.conf Actual results: vdsm put DNSx explicitly into ifcfg-$network, breaks any administration of network via DHCP (hosts can have static declaration!) Expected results: vdsm should not put DNSx options into ifcfg-$network if BOOTPROTO=dhcp Additional info: after IP network change, I have to reconfigure all hosts' ifcfg-$network even their IPs/default GW is OK - super annoying! # Generated by VDSM version 4.19.28-1.el7ev DEVICE=ovirtmgmt TYPE=Bridge DELAY=0 STP=off ONBOOT=yes BOOTPROTO=dhcp MTU=1500 DEFROUTE=yes NM_CONTROLLED=no IPV6INIT=yes IPV6_AUTOCONF=yes DNS1=10.34.63.202 DNS2=10.34.63.204 lease { interface "ovirtmgmt"; fixed-address 10.37.136.246; filename "pxelinux.0"; option subnet-mask 255.255.248.0; option routers 10.37.143.254; option dhcp-lease-time 2678400; option dhcp-message-type 5; option domain-name-servers 10.37.136.1,10.37.136.3; option dhcp-server-identifier 10.37.136.3; option ntp-servers 10.5.26.10,10.11.160.238,10.16.255.1,10.5.27.10; option domain-name "rhev.example.com"; renew 3 2017/11/15 13:46:33; rebind 2 2017/11/28 14:26:23; expire 6 2017/12/02 11:26:23; }
Users that want DHCP to control their DNS do not have to set the DNS property on they management network. If they set both DHCP and DNS on ovirtmgmt, it seems that the result is quite expected.
(In reply to Dan Kenigsberg from comment #1) > Users that want DHCP to control their DNS do not have to set the DNS > property on they management network. If they set both DHCP and DNS on > ovirtmgmt, it seems that the result is quite expected. This is on 4.1 env, where is that "property"?
DNS is exposed only in 4.2. What you report smells like a regression. Please specify your ovirt-engine version, as well as its logs and supervdsm.log
(In reply to Dan Kenigsberg from comment #1) > Users that want DHCP to control their DNS do not have to set the DNS > property on they management network. If they set both DHCP and DNS on > ovirtmgmt, it seems that the result is quite expected. Dan, not sure to whom this question is pointed, if to me then please repeat as i don't understand the question..)
- pristine OS # cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Created by cloud-init on instance boot automatically, do not edit. # BOOTPROTO=dhcp DEVICE=eth0 HWADDR=00:1a:4a:d0:40:28 ONBOOT=yes TYPE=Ethernet USERCTL=no - after adding the host into engine # cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt # Generated by VDSM version 4.19.36-1.el7ev DEVICE=ovirtmgmt TYPE=Bridge DELAY=0 STP=off ONBOOT=yes BOOTPROTO=dhcp MTU=1500 DEFROUTE=yes NM_CONTROLLED=no IPV6INIT=yes IPV6_AUTOCONF=yes DNS1=10.37.136.1 DNS2=10.37.136.3 vdsm-4.19.36-1.el7ev.x86_64 ovirt-engine-4.1.7.5-0.1.el7.noarch ovirt-host-deploy-1.6.7-1.el7ev.noarch
Petr, can you see if we intentionally copy DNS entries on acquisition, even with dchp?
(In reply to Michael Burman from comment #4) > (In reply to Dan Kenigsberg from comment #1) > > Users that want DHCP to control their DNS do not have to set the DNS > > property on they management network. If they set both DHCP and DNS on > > ovirtmgmt, it seems that the result is quite expected. > > Dan, not sure to whom this question is pointed, if to me then please repeat > as i don't understand the question..) vdsm adding the DNS entry to the ifcfg-ovirtmgmt file when adding host, even with dhcp. It always adding the DNS entry, even when the DNS property isn't set on ovirtmgmt in the UI. I think this behavior is expected and it always behaved this way, since the day we started to copy the DNS entries into the ifcfg file.
> vdsm adding the DNS entry to the ifcfg-ovirtmgmt file when adding host, even > with dhcp. > It always adding the DNS entry, even when the DNS property isn't set on > ovirtmgmt in the UI. > > I think this behavior is expected and it always behaved this way, since the > day we started to copy the DNS entries into the ifcfg file. Maybe nobody has cared about this till now by this is not what would anybody using DHCP except. My tolerance for this behavior ran out after change of IP network for all our lab!
Dan, the fix is only for 4.2? correct?
(In reply to Michael Burman from comment #10) > Dan, the fix is only for 4.2? correct? Correct.
Verified on - vdsm-4.20.7-35.git0f9b415.el7.centos.x86_64 and 4.2.0-0.0.master.20171118160347.git80b3e22.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.