Qos feature
Doron Fediuck
dfediuck at redhat.com
Sun Jun 2 11:48:59 UTC 2013
----- 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: Tuesday, May 28, 2013 10:49:40 AM
> Subject: Re: Qos feature
>
> 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>
>
> ...
>
Michael,
This makes a lot of sense, but in a given context.
For example, each cluster will have its own defaults,
and policy implementations. Since this is still in a
thinking process I'd like to wait with this important
discussion until we have some time to come up with
a more complete policies design.
In the meantime we may want to continue with network
QoS without the REST implementation to prevent a lock
before we can ensure it works well with the whole SLA
design.
> >
> >
> >
> >>>
> >>>>
> >>>>> 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
>
More information about the Arch
mailing list