Qos feature
Livnat Peer
lpeer at redhat.com
Mon May 27 18:06:39 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.
> 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.
> 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.
I assume setting QoS is done per vnic, I see above you wrote network.
Can you describe how setting a policy per vnic would look like in your mind?
>
>>> 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.
A user can add a VNIC to his VM if he has permission to use the network,
I'm not sure it make sense that he can also configure his own QoS.
I agree with Michael that configuring the QoS might not be relevant to
the user API/user Portal.
I would say that we should add a new permission on the network entity
for a user to configure QoS on that network.
>
>>>
>>>>
>>>> 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
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>
>
More information about the Arch
mailing list