Bug 1575883 - DEFROUTE set to no after update from vdsm 4.17 -> 4.19
Summary: DEFROUTE set to no after update from vdsm 4.17 -> 4.19
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.6.0
Hardware: Unspecified
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Edward Haas
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 07:47 UTC by Nikola Kresic
Modified: 2023-09-15 00:08 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-24 07:21:37 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1506550 0 high CLOSED [downstream clone - 4.1.7] File missing after upgrade of RHVH node from version RHVH-4.1-20170925.0 to latest. 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker RHV-43495 0 None None None 2021-09-09 14:05:14 UTC

Description Nikola Kresic 2018-05-08 07:47:18 UTC
Description of problem:
Very similar to the following bugzilla #1506550
Looks like a regression. Customer is updating the nodes, the network config files are old and created long time ago, never changed or edited, defroute=yes overwritten to defroute=no after update so that server hangs at boot until the defroute parameter is fixed manually.

Version-Release number of selected component (if applicable):
vdsm latest

How reproducible:
update from 4.17 to 4.19 tested, no idea if it hits other update paths

Steps to Reproduce:
1. one way
- Updated the host first from RHEVM: result was that avter VDSM Upgrade the host was unreachable.
- Previous SSH session was active 
- Set Host to Maintenance
- yum upgrade for rest of RHEL updates (kernel, etc.)
- Rebooted host
- Host not reachable via SSH
- From HW console: it is determined that there is no default route!!
- Set defroute=yes in /etc/sysconfig/network-scripts/ifcfg-rhevm
- service network restart
- Host is now activateable from RHEVM

2. second way
- Set host to maintenance
- yum upgrade
- reboot
- Host is not reachable via SSH
- On HW console again: no default route
- Edited /etc/sysconfig/network-scripts/ifcfg-rhevm, set defroute=yes
- service network restart
- Activate host in RHEVM


Actual results:
config file changed so that it breaks config

Expected results:
config file untouched during update, or at least not in a way that it breaks config

Additional info:

Comment 1 Dan Kenigsberg 2018-05-15 10:04:45 UTC
Would you please attach supervdsm.log from the time of the upgrade and first boot?

Comment 2 Jiri Belka 2018-05-22 11:37:03 UTC
can't reproduce, 3.6/el7.3 eus/els host to 4.1/el7.5:

# rpm -q vdsm kernel-$( uname -r ) initscripts redhat-release-server
vdsm-4.17.45-1.el7ev.noarch
kernel-3.10.0-693.21.1.el7.x86_64
initscripts-9.49.37-1.el7.x86_64
redhat-release-server-7.3-7.el7.x86_64

both ifcfg-* and vdsm's chech file in /var/run/vdsm have yes for defroute.

putting host into maintenance and doing update:

# rpm -q vdsm kernel-$( uname -r ) initscripts redhat-release-server
vdsm-4.19.51-1.el7ev.x86_64
kernel-3.10.0-862.3.2.el7.x86_64
initscripts-9.49.41-1.el7.x86_64
redhat-release-server-7.5-8.el7.x86_64

reboot

# grep -i 'def.*route' /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt 
DEFROUTE=yes
[root@10-37-140-151 ~]# grep -iIR 'def.*route' /var/run/vdsm/ 2>/dev/null
/var/run/vdsm/netconf/nets/ovirtmgmt:    "defaultRoute": true

Comment 3 Jiri Belka 2018-05-22 11:38:33 UTC
We have already release 4.2, thus vdsm is 4.20.x now, could you try with 4.2?

Comment 4 Jiri Belka 2018-05-23 07:55:34 UTC
I upgraded also from 3.6 to 4.2 and it still works too.

Comment 5 Dan Kenigsberg 2018-06-24 07:21:37 UTC
Please reopen with the required logs. Please also include your /etc/vdsm/vdsm.conf

Comment 6 Franta Kust 2019-05-16 13:03:41 UTC
BZ<2>Jira Resync

Comment 7 Red Hat Bugzilla 2023-09-15 00:08:01 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days


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