[Engine-devel] Add traffic shaping parameters for a network interface.

[Livnat Peer]

On 06/10/2013 07:46 PM, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
>> From: "Giuseppe Vallarelli" <gvallare at redhat.com>
>> To: "Dan Kenigsberg" <danken at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Monday, June 10, 2013 6:04:27 PM
>> Subject: Re: [Engine-devel] Add traffic shaping parameters for a network interface.
>>
>> ----- Original Message -----
>> | From: "Dan Kenigsberg" <danken at redhat.com>
>> | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
>> | Cc: engine-devel at ovirt.org
>> | Sent: Monday, June 10, 2013 4:22:54 PM
>> | Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
>> | interface.
>> | 
>> | On Mon, Jun 10, 2013 at 08:56:21AM -0400, Giuseppe Vallarelli wrote:
>> | > Hi Guys, I've recently submitted a patch to support traffic shaping for a
>> | > network interface (http://gerrit.ovirt.org/#/c/15445/).
>> | > This work is needed in order to support
>> | > http://www.ovirt.org/Features/Network_QoS .
>> | > Given:
>> | > 
>> | > 'specParams': {'inbound': {'average': '1000', 'peak': '5000', 'burst':
>> | > '1024'},
>> | >                'outbound': {'average': '128', 'burst': '256'}}}
>> | > 
>> | > Generated xml is the following one:
>> | > 
>> | > 
>> | > 
>> | > 
>> | > 
>> | > 
>> | > As you can see I tried to keep the data structure as flat as possible
>> | > having the bandwidth element not carrying any useful information.
>> | > Feedback is highly appreciated.
>> | > 
>> | 
>> | The issue has not been mentioned on the wiki page, but may need a means
>> | to report the currently-configured QoS of each vNIC from Vdsm to Engine.
>> | For example, when a VM is de-hibernated, we may want to tell whether its
>> | QoS needs to be set according to a recently-tweaked policy.
>> | 
>> | I suggest that we use the "getVmList" verb of Vdsm, which is intended to
>> | report "static" properties of one Vm (or all of them).
>> | 
>> | On the other hand, Engine would want to blindly set new values whenever
>> | in doubt. In such a case, I think that reporting of QoS can be avoided.
>> | 
>> | Dan.
>> | 
>>
>> I'm not sure I've understood completely the issue in discussion, doesn't the
>> engine knows already
>> which are the QoS profile applied to each vNIC ? The last 'tweaked' profile
>> is the one that should
>> be applied after de-hibernation. This means that on the engine side we should
>> keep track of profile
>> change, if a change happens de-hibernating a vm triggers a QoS profile update
>> on the host of the
>> latest profile. I'm not aware of the implementation details so I might be
>> wrong.
>>
>> Giuseppe.
> 
> The idea is to handle scenarios where something went wrong;
> For example, VDSM crash while starting a new VM, engine crash, etc.
> So the engine should be able to ask for current QoS for reporting,
> and (re-)apply it if out of sync.


In addition, if we change the VNIC profile we do not require the VMs
that are using this profile to be down.
Now we can reach a state were the profile is configured for one thing
and the VMs using this profile are running with another value.

At least we would like the user to be aware of that.
I'm not sure if we'd like to sync it automatically. I would start only
with exposing this information to our administrator.

Livnat




> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>