Re: [Users] oVirt 3.5 planning - bandwidth accounting
On Thu, Feb 27, 2014 at 02:14:32PM +0100, Johan Kooijman wrote: > Dan, > > How about storing the rx_byte per 5 minutes in the engine DB? That way a > reset of the counters has a minimal impact and analytics as "traffic for VM > x in month Y" could be made. > > Another approach could be to have iptables keep the count? I do not see how iptables can help here. On the host, Vdsm reports how much traffic did VM x consume. However, when the VM is migrated to another host, the accounting at the destination are reset. If Engine simply copied the value, you can start month Y with 10GiB of traffic, and end it with 7KiB. This should be solved by Engine, probably by "banking" the Vdsm-reported values on certain occasions (vm shutdown, migration, counter reset), and exposing only the accumulated result. Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.5 planning - bandwidth accounting
Dan,
How about storing the rx_byte per 5 minutes in the engine DB? That way a
reset of the counters has a minimal impact and analytics as "traffic for VM
x in month Y" could be made.
Another approach could be to have iptables keep the count?
On Thu, Feb 27, 2014 at 1:03 PM, 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.
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
--
Met vriendelijke groeten / With kind regards,
Johan Kooijman
T +31(0) 6 43 44 45 27
F +31(0) 162 82 00 01
E m...@johankooijman.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.5 planning - bandwidth accounting
+1 This would be very useful! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.5 planning - bandwidth accounting
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.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
