Description of problem: Host booted up after upgrading it 3.5.4->3.6 with rhevm bridge with DEFROUTE=no. Version-Release number of selected component (if applicable): libvirt-client-1.2.17-6.el7.x86_64 vdsm-4.17.5-1.el7ev.noarch ovirt-vmconsole-1.0.0-0.0.1.master.el7ev.noarch qemu-kvm-rhev-2.3.0-22.el7.x86_64 ovirt-hosted-engine-ha-1.3.0-0.4.beta.git1bcfe28.el7ev.noarch ovirt-vmconsole-host-1.0.0-0.0.1.master.el7ev.noarch mom-0.5.0-1.el7ev.noarch ovirt-setup-lib-1.0.0-0.1.master.git6a54bc0.el7ev.noarch sanlock-3.2.4-1.el7.x86_64 ovirt-host-deploy-1.4.0-0.0.5.master.el7ev.noarch Linux version 3.10.0-309.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Mon Aug 24 16:30:44 EDT 2015 How reproducible: 50% Steps to Reproduce: 1.Upgrade rhevm3.5.4->3.6 and then it's hosts. 2.Power-cycle one of the hosts. 3.Check host's DEFROUTE=? Actual results: DEVICE=rhevm TYPE=Bridge DELAY=0 STP=off ONBOOT=yes BOOTPROTO=dhcp DEFROUTE=no NM_CONTROLLED=no IPV6INIT=no HOTPLUG=no Expected results: DEFROUTE=yes Additional info:
Has nothing to do with vmconsole, please do not abuse RFE and/or trackers.
Michael, do you this as well? how often?
Dan, Don't know how often. didn't try it(wasn't aware of it). in order to determine how often you need to test it several times. You can ask reporter^^ or i will test it few times. But any way, i don't think it's relevant to the engine upgrade like described above^^. I think it's a vdsm thing, no?
Nikolai, Are you sure that the ifcfg-ovirtmgmt included DEFROUTE=yes beforehand? Can you attach supervdsm.log of the host?
Nikolai, Can you also attach /var/lib/vdsm/persistence/netconf/nets/* ?
(In reply to Michael Burman from comment #3) > > Don't know how often. didn't try it(wasn't aware of it). Michael, it is important for network QE (with you experience and midfullness of upgrade problems) to verify vdsm 3.5.z->3.6 upgrade, hence my request.
Hi Dan, I run upgrade from vdsm-4.16.27-1.el7ev.x86_64(3.5.5) to latest 3.6 4.17.8-1.el7ev and DEFROUTE=yes remain 'yes' after upgrade and reboot.
Can you try to reproduce again with the report and clean env?
(In reply to Michael Burman from comment #7) > Hi Dan, > > I run upgrade from vdsm-4.16.27-1.el7ev.x86_64(3.5.5) to latest 3.6 > 4.17.8-1.el7ev and DEFROUTE=yes remain 'yes' after upgrade and reboot. the scenario is a nasty DEFROUTE=no that sticks because it was persistent. this can be reproduced with a node installation (which forgets to set it to true IIRC in 3.5.3, not sure about 3.5.4). then, an upgrade should not fix this, and this is a bug.
(In reply to Michael Burman from comment #7) Nikolai, I think mburman accidentally cleared the needinfo flag on you, so I am repeating my request" Are you sure that the ifcfg-ovirtmgmt included DEFROUTE=yes beforehand? Can you attach supervdsm.log of the host? Can you also attach /var/lib/vdsm/persistence/netconf/nets/* ? Thanks.
And please make sure you install a clean 3.5.4 before this upgrade test.
as per no real progress on this and the similarity to https://bugzilla.redhat.com/show_bug.cgi?id=1262431 I think we can close this. *** This bug has been marked as a duplicate of bug 1262431 ***
3.5 versions: Host - vdsm-4.16.27-1.el7ev.x86_64 Engine - rhevm-3.5.5-0.1.el6ev.noarch 3.6 versions: Host - vdsm-4.17.8-1.el7ev.noarch Engine - rhevm-3.6.0-0.18.el6.noarch 1) Start with 3.5 2) Put host to maintenance 3) Upgrade engine to 3.6 4) Upgrade host to 3.6 5) Restart host After restart: [root@cyan-vdsg ~]# cat /etc/sysconfig/network-scripts/ifcfg-rhevm # Generated by VDSM version 4.16.27-1.el7ev DEVICE=rhevm TYPE=Bridge DELAY=0 STP=off ONBOOT=yes BOOTPROTO=dhcp MTU=1500 DEFROUTE=yes NM_CONTROLLED=no HOTPLUG=no I see that this file still generated by old vdsm, so I not sure if it correct.
(In reply to Ido Barkan from comment #12) > as per no real progress on this and the similarity to > https://bugzilla.redhat.com/show_bug.cgi?id=1262431 I think we can close > this. > > *** This bug has been marked as a duplicate of bug 1262431 *** Please check that bug you're referring was opened later on one day than mine, please change the bug 1262431 to duplicate of 1262026 and not the vice versa. Reported: 2015-09-10 11:50 EDT by Nikolai Sednev Reported: 2015-09-11 12:04 EDT by Simone Tiraboschi Currently the bug not being reproduced, so it might be closed.
Currently the bug not being reproduced, so it might be closed.