Bug 1293562 - [RHEV-H] - Vdsm recognizes a change in defaultRoute': of the management network after upgrading from 3.5 to 3.6, although the defaultRoute': wasn't changed
[RHEV-H] - Vdsm recognizes a change in defaultRoute': of the management netwo...
Status: CLOSED CURRENTRELEASE
Product: vdsm
Classification: oVirt
Component: Core (Show other bugs)
4.17.13
x86_64 Linux
high Severity medium (vote)
: ovirt-3.6.2
: 4.17.17
Assigned To: Edward Haas
Michael Burman
:
Depends On:
Blocks: RHEV3.6Upgrade
  Show dependency treegraph
 
Reported: 2015-12-22 02:13 EST by Michael Burman
Modified: 2016-02-18 06:18 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-18 06:18:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
gklein: ovirt‑3.6.z?
mburman: planning_ack?
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)
supervdsm log (22.04 KB, application/x-gzip)
2015-12-22 02:13 EST, Michael Burman
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 51594 master MERGED net: Normalize management network defaultRoute 2016-01-10 10:38 EST
oVirt gerrit 51611 ovirt-3.6 MERGED net: Normalize management network defaultRoute 2016-01-11 03:38 EST

  None (edit)
Description Michael Burman 2015-12-22 02:13:16 EST
Created attachment 1108582 [details]
supervdsm log

Description of problem:
[RHEV-H] - Vdsm recognize a change in defaultRoute': of the management network after upgrading from 3.5 to 3.6, although the defaultRoute': wasn't changed.

Because of that, vdsm touching the network after upgrade and reboot. And will continue to touch the rhevm network every reboot. 

Although the network was persisted as u'defaultRoute': True before the upgrade, vdsm recognize a change and consider the network was persisted as u'defaultRoute': False. 

- From supervdsm.log -->

MainProcess|Thread-272289::DEBUG::2015-12-20 12:10:05,941::ifcfg::488::root::(writeConfFile) Writing to file /etc/sysconfig/network-scripts/ifcfg-rhevm configuration:
# Generated by VDSM version 4.16.30-1.el7ev
DEVICE=rhevm
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
HOTPLUG=no

MainProcess|Thread-272289::INFO::2015-12-20 12:10:05,947::__init__::507::root.ovirt.node.utils.fs::(_persist_file) File "/etc/sysconfig/network-scripts/ifcfg-rhevm" successfully persisted

MainProcess|Thread-272289::INFO::2015-12-20 12:10:06,971::netconfpersistence::76::root::(setNetwork) Adding network rhevm({'nic': u'enp4s0', u'mtu': u'1500', u'bootproto': u'dhcp', u'STP': u'no', u'bridged': u'true', u'defaultRoute': True})

restore-net::INFO::2015-12-21 15:29:25,021::vdsm-restore-net-config::385::root::(restore) starting network restoration.

restore-net::INFO::2015-12-21 15:29:30,088::vdsm-restore-net-config::261::root::(_find_changed_or_missing) rhevm is different or missing from persistent configuration. current: {'nic': 'enp4s0', 'dhcpv6': False, 'mtu': '1500', 'bootproto': 'dhcp', 'stp': False, 'bridged': True, 'defaultRoute': True}, persisted: {u'nic': u'enp4s0', 'dhcpv6': False, 'mtu': '1500', u'bootproto': u'dhcp', 'stp': False, 'bridged': True, 'defaultRoute': False}

Version-Release number of selected component (if applicable):
rhev-m 3.6.1.3-0.1.el6
ovirt-node-3.6.0-0.24.20151209gitc0fa931.el7ev.noarch
vdsm-4.16.30-1.el7ev >> vdsm-4.17.13-1.el7ev.noarch
rhev-hypervisor7-7.2-20151129.1.el7ev >> rhev-hypervisor7-7.2-20151218.2.el7ev


Steps to Reproduce:
1. Configure rhev-h 7.2(20151129.1.el7ev) vdsm 3.5(4.16.30-1.el7ev) via TUI and register to engine  
2. Upgrade rhev-h 7.2 to latest vdsm 3.6.1.3 (4.17.13-1.el7ev.noarch)
3. Check the supervdsm.log 

Actual results:
vdsm recognize a change in 'defaultRoute' and see that it was persisted as False, although it was persisted as True. 
Because of that vdsm will touch the management network every reboot and it shouldn't. 

Expected results:
vdsm shouldn't recognize any change in such scenario and shouldn't touch the management network every reboot.
Comment 1 Dan Kenigsberg 2015-12-23 07:35:25 EST
Does this bug manifests itself only on RHEV-H? Can it not be seen on RHEL-based hosts?
Comment 2 Michael Burman 2015-12-23 09:16:07 EST
Seen it only on rhev-h
Comment 3 Michael Burman 2016-01-18 06:48:39 EST
Verified on - vdsm-4.17.17-0.el7ev

Tested with upgrade :
Red Hat Enterprise Virtualization Hypervisor release 7.2 (20160105.1.el7ev) > 
RHEV Hypervisor - 7.2 - 20160113.0.el7ev

vdsm-4.16.32-1.el7ev.x86_64 > vdsm-4.17.17-0.el7ev

On 3.5.7-0.1.el6ev engine

Note You need to log in before you can comment on or make changes to this bug.