Bug 1262026 - Host booted up after upgrading it 3.5.4->3.6 with rhevm bridge with DEFROUTE=no.
Host booted up after upgrading it 3.5.4->3.6 with rhevm bridge with DEFROUTE=no.
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.0
x86_64 Linux
high Severity high
: ovirt-3.6.1
: 3.6.0
Assigned To: Ido Barkan
network
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-10 11:50 EDT by Nikolai Sednev
Modified: 2016-02-10 14:15 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-19 09:12:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nikolai Sednev 2015-09-10 11:50:37 EDT
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@x86-019.build.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:
Comment 1 Alon Bar-Lev 2015-09-10 11:54:20 EDT
Has nothing to do with vmconsole, please do not abuse RFE and/or trackers.
Comment 2 Dan Kenigsberg 2015-09-24 05:47:07 EDT
Michael, do you this as well? how often?
Comment 3 Michael Burman 2015-09-24 06:04:09 EDT
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?
Comment 4 Ido Barkan 2015-09-24 06:13:46 EDT
Nikolai,
Are you sure that the ifcfg-ovirtmgmt included DEFROUTE=yes beforehand?
Can you attach supervdsm.log of the host?
Comment 5 Ido Barkan 2015-09-24 06:16:41 EDT
Nikolai, Can you also attach /var/lib/vdsm/persistence/netconf/nets/* ?
Comment 6 Dan Kenigsberg 2015-10-02 07:15:36 EDT
(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.
Comment 7 Michael Burman 2015-10-06 03:45:30 EDT
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.
Comment 8 Yaniv Lavi 2015-10-07 05:22:50 EDT
Can you try to reproduce again with the report and clean env?
Comment 9 Ido Barkan 2015-10-07 05:51:48 EDT
(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.
Comment 10 Ido Barkan 2015-10-07 05:55:09 EDT
(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.
Comment 11 Barak 2015-10-07 09:12:16 EDT
And please make sure you install a clean 3.5.4 before this upgrade test.
Comment 12 Ido Barkan 2015-10-11 01:54:13 EDT
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 ***
Comment 13 Artyom 2015-10-11 05:10:16 EDT
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.
Comment 14 Nikolai Sednev 2015-10-11 07:36:19 EDT
(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.
Comment 15 Ido Barkan 2015-10-19 09:12:22 EDT
Currently the bug not being reproduced, so it might be closed.

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