Bug 1293562
| Summary: | [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 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Michael Burman <mburman> | ||||
| Component: | Core | Assignee: | Edward Haas <edwardh> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Michael Burman <mburman> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 4.17.13 | CC: | alkaplan, bugs, danken, gklein, mburman | ||||
| Target Milestone: | ovirt-3.6.2 | Flags: | gklein:
ovirt-3.6.z?
mburman: planning_ack? rule-engine: devel_ack+ rule-engine: testing_ack+ |
||||
| Target Release: | 4.17.17 | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-02-18 11:18:12 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1285700 | ||||||
| Attachments: |
|
||||||
Does this bug manifests itself only on RHEV-H? Can it not be seen on RHEL-based hosts? Seen it only on rhev-h 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 |
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.