----- Original Message ----- > From: "Alon Bar-Lev" <alo...@redhat.com> > To: "Simon Grinberg" <si...@redhat.com> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "Saggi > Mizrahi" <smizr...@redhat.com>, "lpeer >> > Livnat Peer" <lp...@redhat.com> > Sent: Wednesday, November 28, 2012 12:49:10 PM > Subject: Re: [vdsm] MTU setting according to ifcfg files. > > > > ----- Original Message ----- > > From: "Simon Grinberg" <si...@redhat.com> > > To: "Saggi Mizrahi" <smizr...@redhat.com>, "lpeer >> Livnat Peer" > > <lp...@redhat.com> > > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > > Sent: Wednesday, November 28, 2012 7:37:48 PM > > 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> > > > Sent: Wednesday, November 28, 2012 7:15:35 PM > > > Subject: Re: [vdsm] MTU setting according to ifcfg files. > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Simon Grinberg" <si...@redhat.com> > > > > To: "Saggi Mizrahi" <smizr...@redhat.com> > > > > Cc: "VDSM Project Development" > > > > <vdsm-devel@lists.fedorahosted.org>, > > > > "Barak Azulay" <bazu...@redhat.com>, "Igor > > > > Lvovsky" <ilvov...@redhat.com> > > > > Sent: Wednesday, November 28, 2012 12:03:03 PM > > > > Subject: Re: [vdsm] MTU setting according to ifcfg files. > > > > > > > > > > > > > > > > ----- 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, > > > It not weird at all, this is why MTU settings exist. > > > But setting a low MTU will not break the network but will just > > > have > > > some performance degredation. > > > > 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?. > > > It's a question of ownership. Because it's simpler I suggest we > > > assume ownership and always set the maximum needed (also lowering > > > if > > > to high). > > > The engine can query the MTU and make weird decision according. > > > Like > > > setting the current as default or as a saved value or whatever. > > > This flow obviously needs user input so VSDM is not the place to > > > put > > > the decision making. > > > > I tend to agree, it's an ownership thing > > > > Engine should not allow mixed configuration of 'default vs > > override' > > on the same interface. > > If user wishes to start playing with MTUs he needs to use it > > carefully and across the board. > > > > VDSM should not bother with the issue at all, certainly not playing > > a > > guessing game. > > > > Livant, your 0.02$? > > This exactly the reason why we should either define completely > stateless slave host, and apply configuration including what you > call 'defaults'. Completely stateless is problematic because if the engine is down or unavailable and VDSM happens to restart you can't use any of your resources.
The way forward is currently to get rid of most of the configuration in vdsm.conf. Only have things that are necessary for communication with the engine (eg. Core dump on\off, management interface\port, SSL on\off). Other VDSM configuration should have a an API introduced to set them and that will be persisted but only configurable by management (eg. reserved host mem, guest ram overhead, migration timeouts). There should be a place where VDSM saves the configuration of owned resources (eg. managed storage connections, managed interfaces). This will be use by VDSM to make sure that the resources are configured properly after restarts\downtimes without the need of the engine. To reiterate, the general logic for system resources should be that resources are either owned or used by VDSM, you never share ownership. Never assume ownership unless expressly given. VDSM has complete control over owned resources. VDSM has NO control over unowned resources, he can use them but never configure them. Every other hybrid scheme is just asking for trouble. > > Or, store configuration before we perform any change so we can > revert. > > Assuming manual changes and distro specific persistence make the > problem complex in factor of np complete, as we do not know what was > changed when and how to revert. > > Itamar though a bomb that we should co-exist on generic host, this is > something I do not know to compute. I still waiting for a response > of where this requirement came from and if that mandatory. It's all about resource provisioning and ownership delegation. > > Alon > > > > > > > > > > > > > > > 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 > > > > > _______________________________________________ > > 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
