On Tue 06 Dec 2011 11:08:41 AM IST, Roy Golan wrote: > http://www.ovirt.org/wiki/Features/Design/Network

Hi all, The link above is for the wiki describing changes/additions to network features for the coming future. Network management by the engine is fairly big issue and only starting to evolve and may take totally different approach in the future, so this is a (small) start. The changes are typically extending the API to be more robust by provision a desired network topology in one call and create bridge-less networks to utilize network more wisely.

On 12/06/2011 11:52 AM, Roy Golan wrote: > On Tue 06 Dec 2011 11:08:41 AM IST, Roy Golan wrote: >> http://www.ovirt.org/wiki/Features/Design/Network > Hi all, > The link above is for the wiki describing changes/additions to network > features for > the coming future. Network management by the engine is fairly big issue > and only > starting to evolve and may take totally different approach in the > future, so this is a (small) start. > > The changes are typically extending the API to be more robust by > provision a desired network > topology in one call and create bridge-less networks to utilize network > more wisely. how is this feature related to data center compatibility level that it requires it to be 3.1? I'd even say this feature is limited to host level of 3.1, not cluster level?

the only item which would be a DC level is changing MTU, since it should affect all hosts in the DC using that logical network. as for MTU max value - I agree we need to check if there is a way to validate it across all hosts, but I'm pretty sure a config based validation for min/max mtu sizes is needed. then a host could fail the change if the MTU isn't supported by it.

while MTU is relevant in this verb to setup networks, the change of the MTU itself as at logical network at DC level, so it needs a flow for handling a change across all hosts?

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Roy Golan" <rgolan(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Thursday, December 15, 2011 1:44:07 PM Subject: Re: [Engine-devel] Network features design wiki On 12/15/2011 01:03 PM, Roy Golan wrote: > On Thu 15 Dec 2011 12:05:49 PM IST, Itamar Heim wrote: >> On 12/06/2011 11:52 AM, Roy Golan wrote: >>> On Tue 06 Dec 2011 11:08:41 AM IST, Roy Golan wrote: >>>> http://www.ovirt.org/wiki/Features/Design/Network >> >>> Hi all, >>> The link above is for the wiki describing changes/additions to >>> network >>> features for >>> the coming future. Network management by the engine is fairly big >>> issue >>> and only >>> starting to evolve and may take totally different approach in the >>> future, so this is a (small) start. >>> >>> The changes are typically extending the API to be more robust by >>> provision a desired network >>> topology in one call and create bridge-less networks to utilize >>> network >>> more wisely. >> >> >> how is this feature related to data center compatibility level >> that it >> requires it to be 3.1? >> I'd even say this feature is limited to host level of 3.1, not >> cluster >> level? > >> >> the only item which would be a DC level is changing MTU, since it >> should affect all hosts in the DC using that logical network. >> >> as for MTU max value - I agree we need to check if there is a way >> to >> validate it across all hosts, but I'm pretty sure a config based >> validation for min/max mtu sizes is needed. >> then a host could fail the change if the MTU isn't supported by >> it. > so interface MTU validation should be what? mtu < =1500 && mtu <= > logicalNetwork.mtu? >> >> while MTU is relevant in this verb to setup networks, the change >> of >> the MTU itself as at logical network at DC level, so it needs a >> flow >> for handling a change across all hosts? > probably but just for hosts which are in maintnace? what about > active one? > maybe put a "pending action for maintenance" note in the gui to > inform > some configuration sync is needed.(not sure its the best) > It can fall to in "cluster/dc configuration" case where all cluster > host's should have central configuration and once pulled the > vdsm can care to update its internal accordingly. for first phase - probably just block change of an MTU if there is any host in UP status in the DC.

also, since users may have changed the MTU at host level, need to make sure to not override it unless user explicitly asked to set the MTU. also worth checking what exactly is the default MTU for a host today (1500) and warn if it is different than the "default unconfigured MTU" and recommend they set the MTU correctly. _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel