Bug 1118699 - rx/tx reported over 100% when adding/removing ethtools_opts
Summary: rx/tx reported over 100% when adding/removing ethtools_opts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: 3.6.0
Assignee: Barak
QA Contact: Meni Yakove
URL:
Whiteboard: network
Depends On: Cumulative_RX_TX_Statistics_VDSM_Engine 1116577
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-11 09:22 UTC by Dan Kenigsberg
Modified: 2016-02-10 19:37 UTC (History)
11 users (show)

Fixed In Version: ovirt-3.6.0-alpha1.2
Doc Type: Bug Fix
Doc Text:
Clone Of: 1116577
Environment:
Last Closed: 2015-11-04 11:48:54 UTC
oVirt Team: Network


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 37752 master MERGED engine: Truncate percentage in case NIC speed is too low Never

Description Dan Kenigsberg 2014-07-11 09:22:39 UTC
+++ This bug was initially created as a clone of Bug #1116577 +++

Description of problem:
If you add/remove ethtool_opts you get an error: BindingXMLRPC::1126::vds::(wrapper) unexpected error in VDSM log, though an action succeeds

Version-Release number of selected component (if applicable):


How reproducible:
From time to time

Steps to Reproduce:
1. Add ethtool_opts in GUI or remove it (sometimes you see it when creating and sometimes when deleting ethtool_opts)
2. Check VDSM and Engine logs
3.

Actual results:
Unexpected exception Error in VDSM log and Failed to GetStatsVDS, error = Unexpected exception, code = 16 in engine log

Expected results:
No error messages in the logs

Additional info:
Usually it happens when trying to remove ethtool_opts with '-' sign in GUI

--- Additional comment from Dan Kenigsberg on 2014-07-08 11:58:53 IDT ---

Thread-709::DEBUG::2014-07-06 15:54:25,853::sampling::619::vds::(_getInterfacesStats) Rate above 100%. DEBUG: ifid eth1 interval: 8.11740493774 thisRx 4293800384 thisTx 4294966838 samples [(1404651256.1012111, 1166912, 458), (1404651258.113075, 1176526, 458), (1404651260.125016, 1186458, 458), (1404651262.197691, 0, 0), (1404651264.218616, 0, 0)]
Thread-709::ERROR::2014-07-06 15:54:25,854::BindingXMLRPC::1126::vds::(wrapper) unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 1110, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 455, in getStats
    return api.getStats()
  File "/usr/share/vdsm/API.py", line 1245, in getStats
    decStats = self._cif._hostStats.get()
  File "/usr/share/vdsm/virt/sampling.py", line 514, in get
    stats = self._getInterfacesStats()
  File "/usr/share/vdsm/virt/sampling.py", line 619, in _getInterfacesStats
    for hs in self._samples])
KeyError: 'kaka'

Comment 1 Dan Kenigsberg 2015-01-22 17:30:54 UTC
In a sampling window, the host may transmit traffic at 1000mbps. Just before the window is shut, we set ethtools which changes the (reported) speed to 100mpbs. The counted traffic can amount to 10 times of the most-recently reported speed.

In 3.6, Engine is going to ignore Vdsm's rxRate. Therefore, I do not think that we should care much about it on Vdsm side.

That reported case is not pretty, and should probably taken into consideration when Engine calculates the reported tx/rx rates.

Comment 3 Michael Burman 2015-06-08 08:18:42 UTC
Hi Dan,

Please explain what do you mean by 100%.. 100% of what?
The bug in the origin was opened for errors in vdsm and engine logs, and then the summary changed rx/tx reported over 100%. 

Thanks,

Comment 4 Dan Kenigsberg 2015-06-08 12:05:24 UTC
Engine reports the the percentage of host bandwidth that is currently being used.
However, the nic speeds may change, which may lead to the calculated bandwidth percentage being more than 100%, which may confuse end users.

Comment 5 Michael Burman 2015-06-09 08:20:29 UTC
Verified on - 3.6.0-0.0.master.20150519172219.git9a2e2b3.el6 with vdsm-4.17.0-912.git25a063d.el7

Comment 6 Sandro Bonazzola 2015-11-04 11:48:54 UTC
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.


Note You need to log in before you can comment on or make changes to this bug.