Qos feature

Tue May 28 07:49:40 UTC 2013

On 05/27/2013 07:55 PM, Livnat Peer wrote:
> 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?

basically this design serves my proposal mentioned below,
so administration can clearly see that no defaults exist,
and they have to choose policy explicitly.

but i agree "omitting" is a good way to go as well
(we actively using it across the api)

> 
> I liked the disable/enable idea...

this is exactly the same idea, just a bit visualized.

> 
>>> 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.

i understand, but this is different use-case, i was thinking about
private policies (i'm sure there are plenty use-cases for it), this
way we can help by providing policy management, like:

/api/slapolicies

<slapolicy id=xxx href=/api/slapolicies>
  <name>backup_qos_policy</name>
  <type>network</type>
  <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>
</slapolicy>

<slapolicy id=xxx href=/api/slapolicies>
  <name>user_cpu_policy</name>
  <type>cpu</type>
  ...
</slapolicy>

<slapolicy id=xxx href=/api/slapolicies>
  <name>user_memory_policy</name>
  <type>memory</type>
  ...
</slapolicy>

...

> 
> 
> 
>>>
>>>>
>>>>> 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>
>>>>
>>>>
>>>
>>
>>
> 

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D