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

[Doron Fediuck]

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