Bug 1460687

Summary: [RHEL 7.4] - When updating MTU to custom number and after that return to default MTU (1500) the network ifcfg file not updated
Product: [oVirt] vdsm Reporter: Ori Ben Sasson <obensass>
Component: CoreAssignee: Edward Haas <edwardh>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Burman <mburman>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.19.18CC: bugs, danken, mburman, myakove, obensass, stirabos, ylavi
Target Milestone: ovirt-4.1.4Keywords: Automation, Regression
Target Release: 4.19.22Flags: rule-engine: ovirt-4.1+
rule-engine: blocker+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-28 14:10:32 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:
Attachments:
Description Flags
logs
none
vdsm and supervdsm logs none

Description Ori Ben Sasson 2017-06-12 12:13:45 UTC
Created attachment 1287046 [details]
logs

Description of problem:
When updating MTU to custom number and after that return to default MTU (1500) the network ifcfg file not updated on RHEL - 7.4 - 11.el7
by looking on engine side look like the MTU updated

Version-Release number of selected component (if applicable):
ovirt-engine-4.1.3.2-0.1.el7.noarch
vdsm-4.19.18-1.el7ev.x86_64
RHEL - 7.4 - 11.el7
Kernel Version - 3.10.0 - 663.el7.x86_64

How reproducible:
100

Steps to Reproduce:
1. Create and attach network to host with default MTU (1500)
2. Update the MTU to 9000
3. Update the MTU to 1500

Actual results:
The bridge ifcfg file not updated to 1500

Expected results:
The bridge ifcfg file should be updated to 1500

Additional info:
This bug occur only in RHEL - 7.4

Comment 1 Red Hat Bugzilla Rules Engine 2017-06-21 07:45:49 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 2 Edward Haas 2017-07-02 08:18:59 UTC
Unfortunately, I'm unable to read the logs with so many networks defined there.
Please limit the scenario to one or two networks and share the logs again.

BTW: I suspect there is a 7.4 bug here regarding bond defaults.
It relates to the arp_ip_target default content.

arp_ip_target=216.124.160.62,51.152.255.255,185.170.104.145,255.255.255.255,56.125.160.62,51.152.255.255,15.157.201.145,255.255.255.255,16.0.0.0,51.152.255.255,72.125.160.62,51.152.255.255,8.125.160.62,51.152.255.255,111.242.37.235

Comment 3 Meni Yakove 2017-07-02 08:58:16 UTC
Created attachment 1293586 [details]
vdsm and supervdsm logs

Network name mtu_net

Comment 4 Edward Haas 2017-07-02 12:55:28 UTC
Thanks for the logs but I cannot see a problem from the logs.
After the setup is applied, a caps response is issued on 2017-07-02 11:53:55,538 which shows the correct MTU on the bridge.

Comment 5 Meni Yakove 2017-07-05 09:06:15 UTC
Only when setting back MTU to 1500 the ifcfg-<bridge-name> is not set to default MTU=1500

The physical interface is set to default MTU=1500 and /var/lib/vdsm/staging/netconf/nets/mtu_net is set to the currect MTU.

Need to fix the bridge ifcfg file to have the correct MTU.

Comment 6 Edward Haas 2017-07-06 15:25:51 UTC
On RLEH 7.4, when the bridge has no ports connected, it falls down to the default MTU.
The code has been adjusted to always write the bridge ifcfg file when the default mtu is set.

Comment 7 Michael Burman 2017-07-16 10:37:22 UTC
Verified on - vdsm-4.19.22-1.el7ev.x86_64 and
kernel-3.10.0-693.el7.x86_64
4.1.4.1-0.1.el7