<div dir="ltr"><div>Dan,</div><div><br></div>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 &quot;traffic for VM x in month Y&quot; could be made.<div>
<br></div><div>Another approach could be to have iptables keep the count?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 1:03 PM, Dan Kenigsberg <span dir="ltr">&lt;<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are users that would like to tell how much traffic each vnic of<br>
each VM has consumed in a period of time. Currently, we report only<br>
bitrate as a percetage of an estimated vnic &quot;speed&quot;. Integrating this<br>
value over time is inefficent and error prone.<br>
<br>
I suggest to have all the stack (Vdsm, Engine, dwh) report the<br>
actually-trasmitted (and actually-received) byte count on each vnic, as<br>
well as the time when the sample was taken.<br>
<br>
Currently, Vdsm reports<br>
<br>
                   &#39;eth0&#39;: {&#39;rxDropped&#39;: &#39;0&#39;,<br>
                            &#39;rxErrors&#39;: &#39;0&#39;,<br>
                            &#39;rxRate&#39;: &#39;8.0&#39;,<br>
                            &#39;speed&#39;: &#39;1000&#39;,<br>
                            &#39;state&#39;: &#39;up&#39;,<br>
                            &#39;txDropped&#39;: &#39;0&#39;,<br>
                            &#39;txErrors&#39;: &#39;0&#39;,<br>
                            &#39;txRate&#39;: &#39;10.0&#39;},<br>
<br>
but it should add rxKiBytes, txKiBytes and time to the frill.<br>
<br>
GUI could still calculate the rate for illustration, based on the raw<br>
trasmission and the sample time.<br>
<br>
Until we break backward compatibility, we&#39;d keep reporting the flaky<br>
rxRate/txRate, too.<br>
<br>
I can think of only two problems with this approach: Linux byte counters would<br>
eventually reset when they overflow. This is currently hidden by Vdsm, but with<br>
the suggested change, would have to be handled by higher levels of the stack.<br>
<br>
A similar problem appears on migration: the counters would reset and Engine<br>
would need to know how to keep up the accounting properly.<br>
<br>
I&#39;ve opened<br>
<br>
    Bug 1066570 - [RFE] Report actual rx_byte instead of a false rxRate<br>
<br>
to track this request of mine.<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Met vriendelijke groeten / With kind regards,<br>Johan Kooijman<br><br>T +31(0) 6 43 44 45 27<br>F +31(0) 162 82 00 01<br>E <a href="mailto:mail@johankooijman.com">mail@johankooijman.com</a>
</div>