----- Original Message -----
> From: "Saggi Mizrahi" <smizr...@redhat.com>
> To: "Igor Lvovsky" <ilvov...@redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "Simon 
> Grinberg" <si...@redhat.com>, "Barak
> Azulay" <bazu...@redhat.com>
> Sent: Wednesday, November 28, 2012 6:49:22 PM
> Subject: Re: [vdsm] MTU setting according to ifcfg files.
> 
> OK, I think I need to explain myself better,
> MTU sizes under 1500 are not interesting as they are only really
> valid for slow networks which will not be able to support virt
> workloads anyway.
> 1500 is "internet MTU" and is the recommended size when communicating
> with the outside world.
> 
> MTU is just a size that has to be agreed upon by all participants in
> the chain.
> There is no inherent default MTU but default is technically 1500.
> 
> Reverting to previous value makes no sense unless you are just
> testing something out.

Yes it does, 
There are networks out there that do use MTU > 1500 as weird as it sounds, this 
usually the admin does initial settings on the management network and then when 
you set don't touch all works well. An example is when you have storage and 
management on the same network. 

Now consider the scenario that for some VMs the user wants to limit to the 
'normal/recommended defaults' so in this case he will have to set in the 
logical network property to MTU=1500. when VDSM sets this chain it supposedly 
won't touch the interface MTU since it's already bigger (if it does it's a 
bug). Now the user has one more logical network of VMs with 9000 since he also 
have VMs using shared storage on this network. 

All works well till now.

But what about when removing the 9000 network? 
Will VDSM 'remember' that it did not touch the interface MTU in the first 
place, or will it try to set it to this recommended MTU?.

I have no idea :)


> For that case the engine can remember the current MTU and set it
> back.
> 
> To sum up, I suggest ignoring any previously set value like we would
> ignore it if VDSM had set it.
> It makes no sense to keep it because the semantic of setting the MTU
> is to override the current configuration.
> 
> As a side note, having verb to test max MTU for a path might be a
> good idea to give the engine\user a way to recommend a value to the
> user.

That is better but not perfect :)


> 
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizr...@redhat.com>
> > To: "Igor Lvovsky" <ilvov...@redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>,
> > "Simon Grinberg" <si...@redhat.com>
> > Sent: Wednesday, November 28, 2012 11:23:52 AM
> > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > 
> > I don't want to keep the last configured MTU. It's problematic.
> > Having a stack is even worse.
> > VDSM should try not to persist anything if possible.
> > 
> > Also, reverting to the last MTU is raceful and has weird corner
> > cases. Best to just assume default it 1500 (Like all major OSs do).
> > But since it's not really a default I would call it a recommended
> > setting.
> > 
> > ----- Original Message -----
> > > From: "Igor Lvovsky" <ilvov...@redhat.com>
> > > To: "Saggi Mizrahi" <smizr...@redhat.com>
> > > Cc: "VDSM Project Development"
> > > <vdsm-devel@lists.fedorahosted.org>,
> > > "Simon Grinberg" <si...@redhat.com>
> > > Sent: Wednesday, November 28, 2012 11:10:27 AM
> > > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Saggi Mizrahi" <smizr...@redhat.com>
> > > > To: "Simon Grinberg" <si...@redhat.com>
> > > > Cc: "VDSM Project Development"
> > > > <vdsm-devel@lists.fedorahosted.org>,
> > > > "Igor Lvovsky" <ilvov...@redhat.com>
> > > > Sent: Wednesday, November 28, 2012 5:30:17 PM
> > > > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > > > 
> > > > I suggest we don't have a default. If you don't specify an MTU
> > > > it
> > > > will use whatever is already configured.
> > > > There is no way to "go back to the defaults" only to set a new
> > > > value.
> > > > The engine can assume 1500 (in case of ethernet devices) is the
> > > > "recommended value".
> > > > 
> > > 
> > > This is not related to engine. You are right that the actually
> > > MTU
> > > will the last configured one,
> > > but this is exactly a problem.
> > > As I already mentioned, if you will add another bridge without
> > > custom
> > > MTU its users (VMs)
> > > can assume that the MTU is 1500
> > > 
> > > > ----- Original Message -----
> > > > > From: "Simon Grinberg" <si...@redhat.com>
> > > > > To: "Igor Lvovsky" <ilvov...@redhat.com>
> > > > > Cc: "VDSM Project Development"
> > > > > <vdsm-devel@lists.fedorahosted.org>
> > > > > Sent: Wednesday, November 28, 2012 9:53:48 AM
> > > > > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Igor Lvovsky" <ilvov...@redhat.com>
> > > > > > To: "VDSM Project Development"
> > > > > > <vdsm-devel@lists.fedorahosted.org>
> > > > > > Cc: "Simon Grinberg" <si...@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.
> > > > > > If so, we have a problem in vdsm, because we never set MTU
> > > > > > value
> > > > > > until user ask it explicitly.
> > > > > 
> > > > > Actually you are,
> > > > > 
> > > > > You where asked for MTU 9000 on the network,
> > > > > As implementation specif you had to do this all the way down
> > > > > the
> > > > > chain
> > > > > Now it's only reasonable that when you cancel the 9000
> > > > > request
> > > > > then
> > > > > you'll do what is necessary to rollback the changes.
> > > > > It's pity that ifcfg-files don't have the option to set
> > > > > MTU='default', but as you can read this default before you
> > > > > change,
> > > > > then please keep it somewhere and revert to that.
> > > > > 
> > > > > 
> > > > > > 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...
> > > > > > 
> > > > > > Regards,
> > > > > >    Igor Lvovsky
> > > > > > _______________________________________________
> > > > > > vdsm-devel mailing list
> > > > > > vdsm-devel@lists.fedorahosted.org
> > > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > > 
> > > > > _______________________________________________
> > > > > vdsm-devel mailing list
> > > > > vdsm-devel@lists.fedorahosted.org
> > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > 
> > > > 
> > > 
> > 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to