On 11/28/2012 02:58 PM, Igor Lvovsky wrote:

I am working on one of the vdsm bugs that we have and I found that initscripts 
behaviour doesn't fits our needs.
So, I would like to raise this issue in the list.

The issue is MTU setting according to ifcfg files.
I'll try to describe the flow below.

1. I started with ifcfg file for the interface without MTU keyword at all
and the proper interface (let say eth0) had the *default* MTU=1500 (according 
to /sys/class/net/eth0/mtu).
2. I created a bridge with MTU=9000 on top of this interface. Everything went 
    After I wrote MTU=9000 on ifcfg-eth0 and ifdown/ifup it, eth0 got the 
proper MTU.
3. Now, I removed the bridge and deleted MTU keyword from the ifcfg-eth0.
    But after ifup/ifdown the actual MTU of the eth0 stayed 9000.
The only way to change it back to 1500 (or something else) is explicitly set MTU in ifcfg file.
According to Bill Nottingham it is intentional behaviour.
If so, we have a problem in vdsm, because we never set MTU value until user ask 
it explicitly.
It means that if we have interface with MTU=9000 on it just because once there 
was a bridge with such MTU
attached to it and now we want to attach regular bridge with *default* MTU=1500 
we have a problem.
The only thing we can do to avoid this it's set explicitly MTU=1500 in 
interface's ifcfg file.
IMHO it's a bit ugly, but it looks like we have no choice.

As usual comments more than welcome...

    Igor Lvovsky
vdsm-devel mailing list
To me it doesn't sound ugly at all.. part of the interface configuration file we want to add our default MTU value. Isn't it sound reasonable? if we take over and create a bridge and modify eth-0 to work with that bridge, why can't we change or add other interface's parameters?

Yaniv Bronhaim.
RedHat, Israel

vdsm-devel mailing list

Reply via email to