Bug 1508397

Summary: When BOOTPROTO=dhcp do NOT put DNS options explicitly into ifcfg-$network
Product: [oVirt] vdsm Reporter: Jiri Belka <jbelka>
Component: GeneralAssignee: Petr Horáček <phoracek>
Status: CLOSED CURRENTRELEASE QA Contact: Meni Yakove <myakove>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.19.28CC: bugs, danken, jbelka, mburman, phoracek, ylavi
Target Milestone: ovirt-4.2.0Flags: ylavi: ovirt-4.2+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-20 11:19:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Belka 2017-11-01 11:41:51 UTC
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;
}

Comment 1 Dan Kenigsberg 2017-11-01 11:51:36 UTC
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.

Comment 2 Jiri Belka 2017-11-01 11:56:28 UTC
(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"?

Comment 3 Dan Kenigsberg 2017-11-01 12:54:24 UTC
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

Comment 4 Michael Burman 2017-11-01 15:36:38 UTC
(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..)

Comment 5 Jiri Belka 2017-11-01 17:12:17 UTC
- 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

Comment 7 Dan Kenigsberg 2017-11-03 09:27:20 UTC
Petr, can you see if we intentionally copy DNS entries on acquisition, even with dchp?

Comment 8 Michael Burman 2017-11-05 06:09:53 UTC
(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.

Comment 9 Jiri Belka 2017-11-06 07:23:14 UTC
> 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!

Comment 10 Michael Burman 2017-11-19 09:53:46 UTC
Dan, the fix is only for 4.2? correct?

Comment 11 Dan Kenigsberg 2017-11-19 11:25:08 UTC
(In reply to Michael Burman from comment #10)
> Dan, the fix is only for 4.2? correct?

Correct.

Comment 12 Michael Burman 2017-11-19 13:55:31 UTC
Verified on - vdsm-4.20.7-35.git0f9b415.el7.centos.x86_64 and 4.2.0-0.0.master.20171118160347.git80b3e22.el7.centos

Comment 13 Sandro Bonazzola 2017-12-20 11:19:08 UTC
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.