[Engine-devel] Network Quality of Service 3.3 - Feature design

Mike Kolesnik mkolesni at redhat.com
Sun Jun 2 10:20:00 UTC 2013


----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Ofri Masad" <omasad at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, June 2, 2013 11:31:14 AM
> > Subject: Re: [Engine-devel] Network Quality of Service 3.3 - Feature design
> > 
> > On 06/02/2013 11:24 AM, Ofri Masad wrote:
> > > Hi,
> > > answers inline
> > >
> > > Thanks,
> > > Ofri
> > >
> > > ----- Original Message -----
> > >> From: "Itamar Heim" <iheim at redhat.com>
> > >> To: "Ofri Masad" <omasad at redhat.com>
> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >> Sent: Sunday, June 2, 2013 10:34:47 AM
> > >> Subject: Re: [Engine-devel] Network Quality of Service 3.3 - Feature
> > >> design
> > >>
> > >> On 06/02/2013 09:58 AM, Ofri Masad wrote:
> > >>> Hi all,
> > >>>
> > >>> A new Feature page for "Network Quality of Service" feature was
> > >>> published.
> > >>>
> > >>> http://www.ovirt.org/Features/Design/Network_QoS
> > >>>
> > >>> You are more than welcome to share you thoughts and insights.
> > >>>
> > >>> Thanks,
> > >>> Ofri.
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel at ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>
> > >>
> > >>
> > >> some questions:
> > >> 1. "In the Add/Edit Network two parts will be added - one for the QoS
> > >> properties of the network, the other for the QoS properties preset for
> > >> VNICs attached to the network."
> > >>
> > >> so the first part of QoS for network is the limit of the logical network
> > >> on the host for all vnic's associated to it, compared to other logical
> > >> networks?
> > >
> > > Exactly. first part is the network level limitation.
> > 
> > ok. i guess in most cases it wouldn't make sense for network level and
> > vnic level to be the same?
> >
> 
> correct. For example:
> the administrator could limit the network level to 10,000 Mbps average,
> 20,000 Mbps peak, 100,000 Mb burst
> and limit the vnic level to 2000 Mbps average, 5000 Mbps peak and 50,000Mb
> burst.
> So each vnic on this network would be limited to 5000 Mbps in peak but all
> together those vnics could not exceed 20,000 Mbps.

IIUC this is not planned to be supported, so why add this setting at network
level if it doesn't mean anything?

>  
> > ...
> > >
> > >>
> > >> 3. "outbound_burst 	Bigint "
> > >> just wondering - what numbers do you expect here that Integer like the
> > >> average and peak is not enough?
> > >>
> > >
> > > the units for the "burst" parameter are Mb (Mega bits). so, if we would
> > > like to allow burst of over 4GB (Giga byte) we will need Bigint.
> > 
> > integer is up to +2147483647 (Mb)? that's way more than 4GB?
> > 
> 
> You are correct.
> Fixed in the wiki.
> 
> > ...
> > >
> > >
> > >> 5. behavior with provider networks (quantum)?
> > >
> > > Traffic shaping using the Network QoS feature will be available only for
> > > oVirt networks at this stage.
> > 
> > 1. please comment as much
> > 2. btw, why? if libvirt is the one setting the traffic shaping, how
> > would it be different for (some) quantum networks like bridge or ovs?
> 
> Please see Doron's answer.
> I will add a comment to the summery to clarify this.

Technically it is possible to let libvirt shape the traffic as it does for internal
networks.
It is correct that we should factor in Quantum QoS consideration, but since it's not
available yet do we really want to hold back this feature for Quantum provisioned networks?

I am not sure we should plan this far ahead given the partial data that we have, and would
rather see Quantum (and any other provider) networks supported.

On a different subject, some notes..

In Design you wrote for example "Leaving the QoS properties empty will result in using the
default setting defined"
You mean to check the box and not fill anything in the field?

The descriptions of "leaving empty" sound more like implementation details than design, and
they don't coincide with the UI mockups..

In Backend > Classes:
   engine.core.dao.network.VmNetworkDao - add support to the NetworkQoS field
What is VmNetworkDao?

   engine.core.dao.network.VmNetworkQoSDao - new Dao
Why not NetworkQoSDao?



More information about the Engine-devel mailing list