Description of problem: Assigning a NON VM network with mtu via setup network to a host doesn't effect the host's interface. Steps to Reproduce: 1. Create a non vm network (sw162) with mtu 5000 (make sure it's non-vm) 2. Via setup networks, attach sw162 to eth1 Actual results: sw162 on eth1 (in the host) has mtu equal to 1500 Expected results: sw162 on eth1 (in the host) has mtu equal to 5000
This reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=980174#c17 . Which other networks are defined on the host? Could you check if all ifcfg files exists?
In the rhevm: I have defined "rhevm" network on eth0 & "sw164" on eth1. (sw164 is a non-vm network with vlan id equals to 164 and MTU equals to 4000) In the Host: In the directory /etc/sysconfig/network-scripts/ I have the default files (ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, ifcfg-eth3, ...) and ifcfg-eth1.164. The content of ifcfg-eth1.164 is: # Generated by VDSM version 4.12.0-105.git0da1561.el6ev DEVICE=eth1.164 ONBOOT=yes VLAN=yes MTU=4000 DEFROUTE=no NM_CONTROLLED=no
This BZ effect also on VM network with VLAN. Steps to Reproduce: 1. create VLAN network with MTU 5000 2. Attach the network to the host 3. Check the network MTU on the host Actual results: network (in the host) has mtu equal to 1500 Expected results: network (in the host) has mtu equal to 5000
I fail to reproduce this. Please provide the relevant vdsm version, as well as vdsm.log and supervdsm.log (these are better provided in any vdsm bug). If possible, ping me to log into a host where it has happened.
Created attachment 796793 [details] supervdsm.log (host pink-vds4)
Created attachment 796794 [details] supervdsm.log (host pink-vds4.qa.lab.tlv.redhat.com)
This seems to be fixed by Mark Wu's http://gerrit.ovirt.org/18966
vdsm-4.12.0-138.gitab256be.el6ev.x86_64
This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
This bug is a regression due to our initial solution for bz 982632. No need to document it.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0040.html