Re: [vdsm] MTU setting according to ifcfg files.

2012-11-29 Thread Itamar Heim

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.

2012-11-29 Thread Alon Bar-Lev


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

2012-11-29 Thread Simon Grinberg


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

2012-11-29 Thread Alon Bar-Lev


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

2012-11-29 Thread Simon Grinberg


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

2012-11-29 Thread Alon Bar-Lev


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

2012-11-29 Thread Roni Luxenberg
 - 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.

2012-11-29 Thread Simon Grinberg


- Original Message -
 From: Roni Luxenberg rluxe...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: Simon Grinberg si...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Thursday, November 29, 2012 5:13:04 PM
 Subject: 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.

There is another thread on that, don't recall it's title but it discusses API, 
and there too we are divided into the stateless vs statefull parties. 

 
   
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

Re: [vdsm] MTU setting according to ifcfg files.

2012-11-28 Thread Simon Grinberg


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

2012-11-28 Thread Saggi Mizrahi
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.

2012-11-28 Thread Simon Grinberg


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

2012-11-28 Thread Saggi Mizrahi
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.

2012-11-28 Thread Simon Grinberg


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

2012-11-28 Thread Saggi Mizrahi
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.

2012-11-28 Thread Simon Grinberg


- 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

Re: [vdsm] MTU setting according to ifcfg files.

2012-11-28 Thread Saggi Mizrahi


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

2012-11-28 Thread Simon Grinberg


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

2012-11-28 Thread Alon Bar-Lev


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

2012-11-28 Thread Saggi Mizrahi


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

2012-11-28 Thread Dan Kenigsberg
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.

2012-11-28 Thread Alon Bar-Lev


- 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