Description of problem: Vdsm (as well as layers above it) reports the rxRate for each network device. This number is calculated by dividing the bits transferred over the device per second, by the "speed" of the device. For nics, this speed is estimated based on the device driver. For vlan devices or nics that does not support speed (virtio, ib) it is faked as 1000mbps. The speed is fake in the sense that on a host overloaded with multiple VMs, no vNIC has true 1000mbps. On the other hand, inter-VM communication can easily go above 100% of the virtio "speed". In several cases (e.g. when calculating total VM traffic), Engine multiplies the two values to re-produce the actual values. Introducing meaningless numbers into the computation only to remove them later, is bound to cause trouble (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=996678#c7 ) Vdsm reports "speed" and rxRate/txRate since ever, and it would continue to do so in oVirt-3.y.z. However, it's a piece of API we should get straight.
Actually, we'd better report the actual rx_byte and the sample time, and not the calculated rate. The actual rx_byte/tx_byte are important for accounting. The only problem in that is that Linux byte counters may reset once they pass their 64 bit maximum, and are harder to maintain during migration.
Dan, please note the current patch doesn't include sampling times - we'd also want those reported, as you mentioned in Comment 1, to enable the engine to properly compute rate on its own, so in the future the reported rates could be dropped (speed would still be required, though).
Please check how this change affects DWH collection.
This is a part of the Cummulative_RX_TX_Statistics feature. Will discuss the issue with Lior.
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Verified on - 3.6.0.3-0.1.el6 and vdsm-4.17.10.1-0.el7ev.noarch
Since oVirt 3.6.0 has been released, moving from verified to closed current release.