Bug 1262026
| Summary: | Host booted up after upgrading it 3.5.4->3.6 with rhevm bridge with DEFROUTE=no. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Nikolai Sednev <nsednev> |
| Component: | ovirt-engine | Assignee: | Ido Barkan <ibarkan> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.6.0 | CC: | alonbl, alukiano, bazulay, danken, ecohen, gklein, ibarkan, istein, lsurette, mburman, nsednev, rbalakri, Rhev-m-bugs, yeylon, ylavi |
| Target Milestone: | ovirt-3.6.1 | Keywords: | Reopened |
| Target Release: | 3.6.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | network | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-19 13:12:22 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
Nikolai Sednev
2015-09-10 15:50:37 UTC
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. |