Qos feature
Michael Pasternak
mpastern at redhat.com
Tue May 28 07:34:55 UTC 2013
On 05/27/2013 07:13 PM, Doron Fediuck wrote:
>
>
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org
>> Sent: Monday, May 27, 2013 3:32:37 PM
>> Subject: Re: Qos feature
>>
>>
>> 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.
>>
>
> I'm ok with wither.
> Just note that the hierarchy is deeper, and the design will be updated.
> Basically we have:
> Policy
> -> QoS
> -> Network
> -> In
> -> Out
>
> The reason for it is that going forward Policy will include CPU QoS, memory
> QoS, Storage QoS and Quota.
okay, but CPU is not relevant in the context of nic,
but if you say we will add more similar features under
same devices, we can have sla_policy or shaping_policy
(sla_ sounds less aggressive in my view)
> Most humans will want to kill us if they need to fill in all of it every
> time. So policies is something which we can manage and people can actually
> use. If someone needs something specific he can clone a policy and make the
> relevant changes.
this why i suggested using it :)
> In this context what we need is for a network to reference a policy. The
> vNIC will get the policy reference by default, and can override it by
> specifying a different policy.
in my opinion, no default policies should be used
(i put my two cents in other email on this tread (to livnat))
>
>>> 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.
>>
>>> 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.
>>>
>
> The assumption is that users with permissions to modify a vNIC can
> get/set the information in REST.
i think it's a bit deeper, it should be handled by the administration,
while regular NIC changes by technical personnel.
>
>>>
>>>>
>>>> 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)
>>
> See my response above on policies.
> As for setting it, well, we prefer to start with a baseline which can be later
> changed. This is better than starting in 'unlimited' mode we currently have.
> In this way potential bursts are still in control and if more resources needed
> than a matching policy should be assigned.
>
>>>
>>>>
>>>>> 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
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
More information about the Arch
mailing list