[Engine-devel] Network Quality of Service 3.3 - Feature design
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.
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? 2. "Only a user permitted to edit the network may edit the QoS properties in the network dialog or override the QoS properties in the VNIC dialog. " why would a network operator (having permissions on networks) have permissions on specific VM's vnic's? probably a special permission to edit network QoS at vm level is needed? 3. "outbound_burst Bigint " just wondering - what numbers do you expect here that Integer like the average and peak is not enough? 4. "Old libvirt versions that have the global driver lock may have performance problems. It would be nice to check what version of libvirt is this going to run on" old versions but 1.0.1 is required, does 1.0.1 have this issue? 5. behavior with provider networks (quantum)? Thanks, Itamar
Hi, answers inline Thanks, Ofri ----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ofri Masad" <omasad@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.
2. "Only a user permitted to edit the network may edit the QoS properties in the network dialog or override the QoS properties in the VNIC dialog. "
why would a network operator (having permissions on networks) have permissions on specific VM's vnic's? probably a special permission to edit network QoS at vm level is needed?
True. we will limit the VNIC QoS editing to a user which holds both UserVmManager and NetworkAdmin permissions. This also the case for editing port mirroring for vnic.
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.
4. "Old libvirt versions that have the global driver lock may have performance problems. It would be nice to check what version of libvirt is this going to run on"
old versions but 1.0.1 is required, does 1.0.1 have this issue?
No. ver 1.0.1 does not have that problem. this sentence was left there by mistake and will be removed.
5. behavior with provider networks (quantum)?
Traffic shaping using the Network QoS feature will be available only for oVirt networks at this stage.
Thanks, Itamar
On 06/02/2013 11:24 AM, Ofri Masad wrote:
Hi, answers inline
Thanks, Ofri
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ofri Masad" <omasad@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? ...
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? ...
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? Thanks, Itamar
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ofri Masad" <omasad@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" <iheim@redhat.com> To: "Ofri Masad" <omasad@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?
...
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?
...
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?
Good question. Quantum has its own API which may conflict the libvirt one.
From what we saw so far, the Quantum QoS API is still in process, but should support VM level and not vNIC level. Either way, at this point to prevent conflicts we support oVirt networks only and once possible we'll try to expand it to provided networks.
Thanks, Itamar _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ofri Masad" <omasad@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" <iheim@redhat.com> To: "Ofri Masad" <omasad@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
----- Original Message -----
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ofri Masad" <omasad@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" <iheim@redhat.com> To: "Ofri Masad" <omasad@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.
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?
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
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Ofri Masad" <omasad@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.
participants (5)
-
Doron Fediuck -
Itamar Heim -
Livnat Peer -
Mike Kolesnik -
Ofri Masad