Re: [vdsm] MTU setting according to ifcfg files.
On 11/28/2012 01:20 PM, Saggi Mizrahi wrote: ... 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. that's actually a very good point. going forward we would like to be able for hosts to continue working when engine is down, even post reboot. engine passing the policy to the hosts and hosts assuming that policy is relevant post boot would allow that. (though relying on central network services like qunatum will also cause an issue for this architecture). 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. hybrid mode is something brought up several times as a use case we should consider. so far our main concern was that SLA in the host would be needed (cgroup for example) between the native and guest workloads. as well as making sure hybrid nodes will not contend for critical resources to reduce the risk of a need to fence them. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On 11/28/2012 01:20 PM, Saggi Mizrahi wrote: ... 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. that's actually a very good point. going forward we would like to be able for hosts to continue working when engine is down, even post reboot. engine passing the policy to the hosts and hosts assuming that policy is relevant post boot would allow that. (though relying on central network services like qunatum will also cause an issue for this architecture). 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. hybrid mode is something brought up several times as a use case we should consider. so far our main concern was that SLA in the host would be needed (cgroup for example) between the native and guest workloads. as well as making sure hybrid nodes will not contend for critical resources to reduce the risk of a need to fence them. brought up - ok. should be supported - this is the question. there is no problem to wrap the original server within vm and solve the problem with current terms. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On 11/28/2012 01:20 PM, Saggi Mizrahi wrote: ... 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. that's actually a very good point. going forward we would like to be able for hosts to continue working when engine is down, even post reboot. How?, Will you really fire up VMs without central management control? This implies you'll have to go into host based clustering where you'll hit scale limits as any other such a solution. If you do not intend to do the above then why not stateless? Host to remember on wakeup an old configuration may at best not work but at worst may conflict with existing configuration and do unpredictable things to your environment. You also loose the benefit of recovering bad configured host simply by fencing it. engine passing the policy to the hosts and hosts assuming that policy is relevant post boot would allow that. (though relying on central network services like qunatum will also cause an issue for this architecture). 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. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. It's all about resource provisioning and ownership delegation. hybrid mode is something brought up several times as a use case we should consider. so far our main concern was that SLA in the host would be needed (cgroup for example) between the native and guest workloads. as well as making sure hybrid nodes will not contend for critical resources to reduce the risk of a need to fence them. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, November 29, 2012 2:12:09 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. snip 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. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Actually, I am. I claim that we will never be able to stabilize a product if we go this way. There is a very good reason why other virtualization solutions out there put similar restriction. When and if we finish with rock solid solution using a pure completely managed slave and have good market share then we can start thinking about these non deterministic approaches. Or... maybe this is the marketing advantage we would like, and then we should FOCUS on this approach, but then we are aiming to low scale, manual managed solution, and the other open source project will probably consume the higher scale. As I wrote there are two solution using CURRENT technology for that: 1. Move the original host into virtual machine and manage the host as a whole. 2. Execute virtual machine with nested virtualization and manage this VM as if it was our host, in this mode we have no conflict. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. This is not the way to go in this case, Oracle will not live within stateless world, nor 1000 other solutions. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Simon Grinberg si...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:25:03 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, November 29, 2012 2:12:09 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. snip 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. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Actually, I am. I claim that we will never be able to stabilize a product if we go this way. There is a very good reason why other virtualization solutions out there put similar restriction. When and if we finish with rock solid solution using a pure completely managed slave and have good market share then we can start thinking about these non deterministic approaches. Actually it's the other way around. Since you are far from there, then many (if not most) users today actually use a full blown host to complement features or required functionality like: Monitoring, Private firewall, central logging, customization for third party devices etc. Or... maybe this is the marketing advantage we would like, and then we should FOCUS on this approach, but then we are aiming to low scale, manual managed solution, and the other open source project will probably consume the higher scale. As I wrote there are two solution using CURRENT technology for that: 1. Move the original host into virtual machine and manage the host as a whole. 2. Execute virtual machine with nested virtualization and manage this VM as if it was our host, in this mode we have no conflict. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. This is not the way to go in this case, Oracle will not live within stateless world, nor 1000 other solutions. You missed what I've said: Admin configures state-fully everything required for the 'native' application, VDSM may configure starless on top. After reboot, host goes back to the original configuration that is enough to run the 'native' non managed by VDSM applications. Regards, Alon. ___ 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
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Simon Grinberg si...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:35:46 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Simon Grinberg si...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:25:03 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, November 29, 2012 2:12:09 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. snip 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. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Actually, I am. I claim that we will never be able to stabilize a product if we go this way. There is a very good reason why other virtualization solutions out there put similar restriction. When and if we finish with rock solid solution using a pure completely managed slave and have good market share then we can start thinking about these non deterministic approaches. Actually it's the other way around. Since you are far from there, then many (if not most) users today actually use a full blown host to complement features or required functionality like: Monitoring, Private firewall, central logging, customization for third party devices etc. And again, I disagree. This may be enough for an entry level solution. Enterprise solution will probably prefer rhev-h or similar self managed solution, this of course, if we provide decent management support. Customization for third party devices has no management/state impact. Central logging - we have the log collector for that. Monitoring - if we going to provide SLA we are going to perform monitoring as well. Private Firewall - this will totally conflict with whatever engine enforces. Or... maybe this is the marketing advantage we would like, and then we should FOCUS on this approach, but then we are aiming to low scale, manual managed solution, and the other open source project will probably consume the higher scale. As I wrote there are two solution using CURRENT technology for that: 1. Move the original host into virtual machine and manage the host as a whole. 2. Execute virtual machine with nested virtualization and manage this VM as if it was our host, in this mode we have no conflict. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. This is not the way to go in this case, Oracle will not live within stateless world, nor 1000 other solutions. You missed what I've said: Admin configures state-fully everything required for the 'native' application, VDSM may configure starless on top. After reboot, host goes back to the original configuration that is enough to run the 'native' non managed by VDSM applications. No I did not. Let's say we
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Simon Grinberg si...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:35:46 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Simon Grinberg si...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:25:03 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, November 29, 2012 2:12:09 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. snip 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. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Actually, I am. I claim that we will never be able to stabilize a product if we go this way. There is a very good reason why other virtualization solutions out there put similar restriction. When and if we finish with rock solid solution using a pure completely managed slave and have good market share then we can start thinking about these non deterministic approaches. Actually it's the other way around. Since you are far from there, then many (if not most) users today actually use a full blown host to complement features or required functionality like: Monitoring, Private firewall, central logging, customization for third party devices etc. And again, I disagree. This may be enough for an entry level solution. Enterprise solution will probably prefer rhev-h or similar self managed solution, this of course, if we provide decent management support. Customization for third party devices has no management/state impact. Central logging - we have the log collector for that. Monitoring - if we going to provide SLA we are going to perform monitoring as well. Private Firewall - this will totally conflict with whatever engine enforces. engine vdsm should provide a framework/api to offload network services like FW, IPS, DLP, WAAS, etc. (as well as other types of services like backup/DR) to external virtual appliances by seamlessly routing/redirecting traffic to/from these appliances. this will potentially reduce conflicts dependencies and accelerate feature velocity. Or... maybe this is the marketing advantage we would like, and then we should FOCUS on this approach, but then we are aiming to low scale, manual managed solution, and the other open source project will probably consume the higher scale. As I wrote there are two solution using CURRENT technology for that: 1. Move the original host into virtual machine and manage the host as a whole. 2. Execute virtual machine with nested virtualization and manage this VM as if it was our host, in this mode we have no conflict. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after
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
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. - 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
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. I understand, This is why I've suggested to keep the old value and revert to that. Igor, alternately you may always calculate based on the hierarchy leafs, meaning the 'trunk' interface always needs to be set to the maximal MTU required by any of the logical networks, and it needs to be recalculated every time you change something in the hierarchy The problem is what happens if all are removed and then another is configured with MTU set to not override, here you may need to use the saved one. - 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
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
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Igor Lvovsky ilvov...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 6:10:27 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, 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 Assumption is the mother of all . What needs to be done is reverting to the old value. Can be done easily by inserting a comment in the ifcfg-file with the MTU prior to the change. When we (hopefully) go into a stateless configuration controlled by the engine/any other manager then it should be determined solely by the manager, and reverted to user defined on reboot. - 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
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. 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. - 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
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 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
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$? 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
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'. 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. 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
Re: [vdsm] MTU setting according to ifcfg files.
- 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
Re: [vdsm] MTU setting according to ifcfg files.
On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: 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. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: 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. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
