Re: [Engine-devel] Network Quality of Service 3.3 - Feature design
- Original Message - From: Livnat Peer lp...@redhat.com To: Ofri Masad oma...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, June 4, 2013 12:02:35 PM 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. Hi Ofri, Here is another suggestion for you to consider, this suggestion is realted only to QoS on the VNIC level - Introducing a new entity - VNIC Profile. The VNIC profile would include all the properties of a VNIC: - network, - Qos, - Port mirroring, - custom properties From now on a user would choose a VNIC profile when he defines a VNIC (instead of choosing a network and defining properties directly on the VNIC) A network could have multiple profiles defined on it. A User would need permissions to use a profile instead of the current state that we require permission to use a network. The benefits of this approach : 1. Limiting the user to a specific QoS on a network is easy you give the user permission to use a specific profile. 2. A user can add a new VNIC but he would be limited to QoS defined on the profile he is able to use (which eliminates the problem that a user can add a VNIC to it's VM but won't get any bandwidth limitations). 3. An administrator does not add VNIC QoS properties on the network entity (to serve as defaults) which are not relevant for non-VM network. 4. The network admin who creates the VNIC profile is also the one who can configure the QoS to that Network. 5. The separation between user portal and admin portal is very clear, in user portal we expose only the profile name and in the admin portal a user can view the profile details. 6. We would leave custom properties also on the VNIC level not only the profile level so a user can send VM specific data. 7.I can also describe upgrade path but maybe we should discuss the general concept before diving into the details. Hi Livnat, This design creates a new feature of network profile, which has QoS included in it, so it's bigger the the original intention. Having that said, I agree with the concept as we need to take a more holistic approach which considers other areas of the system, such as SLA policies and instance types. So in this view I'll just add that going forward the QoS element of the profile will be a reference to a policy entity which will include network QoS as well as other QoS elements. At this point we're going back to the drawing board to update the design and will publish an update asap. Doron Livnat Thanks, Ofri. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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. Hi Ofri, Here is another suggestion for you to consider, this suggestion is realted only to QoS on the VNIC level - Introducing a new entity - VNIC Profile. The VNIC profile would include all the properties of a VNIC: - network, - Qos, - Port mirroring, - custom properties From now on a user would choose a VNIC profile when he defines a VNIC (instead of choosing a network and defining properties directly on the VNIC) A network could have multiple profiles defined on it. A User would need permissions to use a profile instead of the current state that we require permission to use a network. The benefits of this approach : 1. Limiting the user to a specific QoS on a network is easy you give the user permission to use a specific profile. 2. A user can add a new VNIC but he would be limited to QoS defined on the profile he is able to use (which eliminates the problem that a user can add a VNIC to it's VM but won't get any bandwidth limitations). 3. An administrator does not add VNIC QoS properties on the network entity (to serve as defaults) which are not relevant for non-VM network. 4. The network admin who creates the VNIC profile is also the one who can configure the QoS to that Network. 5. The separation between user portal and admin portal is very clear, in user portal we expose only the profile name and in the admin portal a user can view the profile details. 6. We would leave custom properties also on the VNIC level not only the profile level so a user can send VM specific data. 7.I can also describe upgrade path but maybe we should discuss the general concept before diving into the details. Livnat Thanks, Ofri. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Network Quality of Service 3.3 - Feature design
- Original Message - From: Itamar Heim ih...@redhat.com To: Ofri Masad oma...@redhat.com Cc: engine-devel engine-devel@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 ih...@redhat.com To: Ofri Masad oma...@redhat.com Cc: engine-devel engine-devel@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@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. ... 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. Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
