[Users] oVirt 3.5 planning - bandwidth/cpu/io accounting

[Dan Kenigsberg]

On Thu, Feb 27, 2014 at 12:03:55PM +0000, Dan Kenigsberg wrote:
> There are users that would like to tell how much traffic each vnic of
> each VM has consumed in a period of time. Currently, we report only
> bitrate as a percetage of an estimated vnic "speed". Integrating this
> value over time is inefficent and error prone.
> 
> I suggest to have all the stack (Vdsm, Engine, dwh) report the
> actually-trasmitted (and actually-received) byte count on each vnic, as
> well as the time when the sample was taken.
> 
> Currently, Vdsm reports
> 
>                    'eth0': {'rxDropped': '0',
>                             'rxErrors': '0',
>                             'rxRate': '8.0',
>                             'speed': '1000',
>                             'state': 'up',
>                             'txDropped': '0',
>                             'txErrors': '0',
>                             'txRate': '10.0'},
> 
> but it should add rxKiBytes, txKiBytes and time to the frill.
> 
> GUI could still calculate the rate for illustration, based on the raw
> trasmission and the sample time.
> 
> Until we break backward compatibility, we'd keep reporting the flaky
> rxRate/txRate, too.
> 
> I can think of only two problems with this approach: Linux byte counters would
> eventually reset when they overflow. This is currently hidden by Vdsm, but with
> the suggested change, would have to be handled by higher levels of the stack.
> 
> A similar problem appears on migration: the counters would reset and Engine
> would need to know how to keep up the accounting properly.
> 
> I've opened
> 
>     Bug 1066570 - [RFE] Report actual rx_byte instead of a false rxRate
> 
> to track this request of mine.

For the reconrd, I'm told that there is a very similar need for
reporting accumulated guest CPU cycle IO operations consuption.
Martin, do we already have BZs for the other two use cases?