[vdsm] MTU setting according to ifcfg files.

Alon Bar-Lev alonbl at redhat.com
Wed Nov 28 13:02:22 UTC 2012



----- Original Message -----
> From: "Igor Lvovsky" <ilvovsky at redhat.com>
> To: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Cc: "Simon Grinberg" <simon at redhat.com>
> Sent: Wednesday, November 28, 2012 2:58:52 PM
> Subject: [vdsm] MTU setting according to ifcfg files.
> 
> Hi,
> 
> I am working on one of the vdsm bugs that we have and I found that
> initscripts (initscripts-9.03.34-1.el6.x86_64)
> 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 OK.
>    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.

Right. The network should not push what not configured.

> 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...

For the long run have total control over our resources, and push whatever configuration we require... skipping distribution specific behaviour.

Regards,
Alon.


More information about the vdsm-devel mailing list