----- Original Message ----- | From: "Doron Fediuck" <[email protected]> | To: "Moti Asayag" <[email protected]> | Cc: "Giuseppe Vallarelli" <[email protected]>, [email protected] | Sent: Sunday, July 21, 2013 10:09:01 AM | Subject: Re: Network traffic shaping. | | | | ----- Original Message ----- | | From: "Moti Asayag" <[email protected]> | | To: "Giuseppe Vallarelli" <[email protected]> | | Cc: [email protected] | | Sent: Friday, July 19, 2013 6:07:35 PM | | Subject: Re: Network traffic shaping. | | | | Hi, | | | | According to the 'Detailed description' section in the wiki, it is stated | | that the | | admin may override the traffic shaping of the network on the data-center | | level with | | a specific one per host. | | | | Is there a need to persist this configuration on the engine side and to | | present it | | to the user or we just passing these settings to the host while configuring | | the | | network on the host and abandoning them afterwards? Meaning, VDSM will | | report | | the QoS per | | host's network and it will be presented to the user. But the actual values | | that | | were used to set these network QoS won't be persistent on the engine side? | | | | The answer to the above has further implication on the design on engine | | side, | | therefore before starting futile discussion, is there such a requirement ? | | | | ----- Original Message ----- | | > From: "Giuseppe Vallarelli" <[email protected]> | | > To: [email protected] | | > Sent: Monday, July 8, 2013 1:45:41 PM | | > Subject: Network traffic shaping. | | > | | > Hi everybody, I'm working to implement traffic shaping at the network | | > level | | > [1]. | | > This feature is composed by two distinct parts: definition of traffic | | > shaping | | > for a logical network entity and optional redefinition of traffic shaping | | > when | | > the user is doing a Setup Host Networks task. Initial focus will be on | | > first | | > part. There are some points of contact with Network Qos [2] that's why I | | > proposed | | > to reuse some code backend side. | | > | | > Cheers, Giuseppe | | > | | > [1] http://www.ovirt.org/Features/Network_traffic_shaping | | > [2] http://www.ovirt.org/Features/Network_QoS | | Hi guys, | Adding my comments to Moti's; | | First of all Giuseppe, looks like a good start for a much needed | functionality in oVirt. | So thumbs' up on driving it forward and having this discussion in place ;) | Somehow, your writing was taken out of context, so I think we should | clarify the concepts to begin with;
Hi Doron, | Host-level traffic shaping handles one aspect in the domain of QoS. For | 3.3 we're already planning VM-level networking QoS and your feature is | completing it. | Network traffic shaping is one implementation libvirt chose, in order | to provide quality of service at host level. Look for "quality of service" | in [1]. But we should also remember that it may have additional | implementations | which goes all the way to the network device, as we will need to handle in | provided networks. All right. | | So for completeness and clarification we should align host-level network QoS | with VM-level network QoS. Let's start with renaming the feature from it's | implementation to what it should provide: host network QoS. Ofri may assist | you with renaming current pages as needed to improve things. This may also | help me find the detailed description Moti was referring to. Ok I agree on the naming issue, I wanted to get Network QoS (still not the best name) but that was already used. Host network QoS sounds good to me. | As a next step we should verify there are no conflicts in functionality | and UI in both levels. Implementation wise, I like your re-use attempts, | and I'd suggest revisiting the UI part based on network profiles. Network | profiles are consumers for network QoS entities just as logical network is a | consumer of network QoS entities. IIUC, you should be using the QoS left tab | as depicted in [2] in the new/edit logical network dialog. For your UI concern, the actual mockups are rough sketches it's probably going to look different. I agree with you on the need of having a possible uniform UI look'n'feel. A possible idea for future releases would be to have a sort of unified QoS dashboard where the admin can have an overall picture of the defined QoS at multiple levels. | Going forward we'll have to close the gaps of the API for both levels, | and make sure these QoS settings are managed properly as a policy and | delivered to the host, where it will be enforced by MoM. Ok, thanks for the feedback, Giuseppe | | Doron | | [1] http://libvirt.org/formatnetwork.html | [2] http://www.ovirt.org/File:New_netwrok_profiles.png | | | _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
