Bug 1118699

Summary: rx/tx reported over 100% when adding/removing ethtools_opts
Product: [Retired] oVirt Reporter: Dan Kenigsberg <danken>
Component: ovirt-engine-coreAssignee: Barak <bazulay>
Status: CLOSED CURRENTRELEASE QA Contact: Meni Yakove <myakove>
Severity: low Docs Contact:
Priority: low    
Version: 3.5CC: bazulay, bugs, danken, ecohen, gcheresh, gklein, lsurette, mburman, mgoldboi, rbalakri, yeylon
Target Milestone: ---   
Target Release: 3.6.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: ovirt-3.6.0-alpha1.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1116577 Environment:
Last Closed: 2015-11-04 11:48:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1063343, 1116577    
Bug Blocks:    

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.