Qos feature
Livnat Peer
lpeer at redhat.com
Mon May 27 16:55:27 UTC 2013
On 05/27/2013 03:32 PM, Michael Pasternak wrote:
>
> Hi Livnat,
>
> On 05/27/2013 02:45 PM, Livnat Peer wrote:
>> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>>> Hi Ofri,
>>>
>>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>>> Hi Michael,
>>>>
>>>> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
>>>> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
>>>>
>>>> Thanks,
>>>> Ofri
>>>>
>>>
>>> i have few questions/comments regarding api/general design:
>>>
>>> 1) incoming and outgoing traffic can be shaped independently, will we support
>>> granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>> then i'd suggest modelling QOS in api like this:
>>>
>>> <qos>
>>> <inbound enabled="true|false">
>>> <average>xxx</average>
>>> <peak>yyy</peak>
>>> <burst>zzz</burst>
>>> <floor>qqq</floor>
>>> </inbound>
>>> <outbound enabled="true|false">
>>> <average>xxx</average>
>>> <peak>yyy</peak>
>>> <burst>zzz</burst>
>>> </outbound>
>>> </qos>
>>
>>
>> Note that the above requires to support a mode of inbound (or outbound)
>> values configured while not enabled,
>
> no it doesn't, all attributes can have NULLs when disabled.
>
Why disable+null values is better than just omitting the
inbound/outbound elements?
I liked the disable/enable idea...
>> it also requires a change in the UI.
>
> api & UI doesn't have to be the same, but i think suggested above makes sense
> for UI as well.
>
of course, I agree, they don't have to be the same. In this case I think
it makes sense.
>> I see how the above suggestion can be useful to users.
>
> it can be useful for us on a first place, cause it's easily extendible,
> i.e it much easier to extend expended type with new elements rather
> than inline adding attributes <outbound average='' peak='' burst='' ...../>
> and in addition we can easily add system element's (if not now then in future)
> such as <inbound enabled="true|false" policy='xxx' ...>
>
>>
>>>
>>>
>>> 2) at design page, i didn't saw you mentioning permission model for the QOS,
>>> who should be able seeing it/manipulating it (note, that in case of user
>>> that should not be seeing it, in api you shouldn't even show the state of the
>>> qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>>
>>
>> That's a good point.
>> Also note that the above suggests different UI dialogs in the user
>> portal and the admin portal for adding vnic.
>>
>>
>>>
>>> 3) what about exposing policies?, like making admin being able to apply same policy
>>> on a different devices, rather than doing it manually per device.
>>
>> I suggest to support having default configuration on the Network entity,
>> all Vnics connected to the network inherit the configuration from the
>> Network.
>> If qos is configured both on the network and on the VNIC the VNIC
>> configuration holds.
>
> usually QoS providers avoid having defaults cause when QoS turned on by
> mistake it's simply applies these values silently, while if it has NULLs,
> you cannot turn it on by mistake (i.e forcing users to set rules preferred
> over default configurations)
>
I think the idea wasn't clear enough, a more detailed explanation -
A user can configure the inbound/outbound values on the network entity.
This configuration would apply to all VNICs using this network.
That approach would help the administrator to configure, in a very
simple way, a policy that prevents one VM from taking too much of the
network bandwidth.
>>
>>>
>>>> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>>>>
>>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e" ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>> <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>> <name>nic1</name>
>>>> <interface>virtio</interface>
>>>> <mac address="00:1a:4a:16:84:07"/>
>>>> <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>> <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>>
>>> - 'bandwidth' is not clear enough in my view, i think we should just use 'qos'
>>>
>>>> <bandwidth>
>>>
>>> - we should be having <enabled>true|false</enabled> element here/peer traffic-dist?
>>>
>>>> <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>> <outbound average='128' peak='256' burst='256'/>
>>>> </bandwidth>
>>>> </nic>
>>>>
>>>>
>>>> An API user modifies a network interface with a PUT request
>>>>
>>>> <nic>
>>>> <name>nic2</name>
>>>> <network id="00000000-0000-0000-0000-000000000010"/>
>>>> <type>e1000</type>
>>>> <bandwidth>
>>>> <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>> <outbound average='128' peak='256' burst='256'/>
>>>> </bandwidth>
>>>> </nic>
>>>
>>>
>>
>
>
More information about the Arch
mailing list