Bug 1470696
| Summary: | Bridge with two ports kills getCaps - 'code=-32603, message=too many values to unpack' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Michael Burman <mburman> | ||||
| Component: | Core | Assignee: | Edward Haas <edwardh> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Michael Burman <mburman> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 4.20.0 | CC: | bugs, ylavi | ||||
| Target Milestone: | ovirt-4.2.0 | Flags: | rule-engine:
ovirt-4.2+
|
||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-12-20 11:07:35 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: | |||||||
| Attachments: |
|
||||||
At the very least we should report a clearer error message, since this is not the first time I'm asked about this unpacking error. When multiple ifaces are connected to the bridge, the associated network is ignored for the QoS report part. In the logs, the following error will appear: "Multiple southbound ports per network detected, ignoring this network for the QoS report"
Edward, i now see the new error in the logs and getCaps isn't dead, but host is stuck in connecting state in rhv and not coming up:
m4 8000.001d096871c3 no eno2.166
eno2.168
"m4": {
"ports": [
"eno2.166",
"eno2.168"
MainProcess|jsonrpc/2::ERROR::2017-08-21 09:26:42,434::qos::48::root::(report_network_qos) Multiple southbound ports per network detected, ignoring this network for the QoS report (network: m4, ports: ['eno2.166', 'eno2.168'])
Looks like engine can't handle such scenario, but vdsm side is fixed.
Reporting a bug on engine side.
Verified on - vdsm-4.20.2-90.git6511af5.el7.centos.x86_64
Bug for the engine side to handle such scenario - BZ 1483448 This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |
Created attachment 1297616 [details] Logs Description of problem: Bridge with two ports kills getCaps and cause the host to become non-responsive in rhv-m: MainProcess|jsonrpc/2::ERROR::2017-07-13 15:40:14,437::supervdsm_server::97::SuperVdsm.ServerCallback::(wrapper) Error in network_caps Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 95, in wrapper res = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 53, in network_caps return netswitch.configurator.netinfo(compatibility=30600) File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch/configurator.py", line 311, in netinfo _netinfo = netinfo_get(vdsmnets, compatibility) File "/usr/lib/python2.7/site-packages/vdsm/network/netinfo/cache.py", line 143, in get return _stringify_mtus(_get(vdsmnets)) File "/usr/lib/python2.7/site-packages/vdsm/network/netinfo/cache.py", line 67, in _get nets_info = _networks_report(vdsmnets, routes, ipaddrs, devices_info) File "/usr/lib/python2.7/site-packages/vdsm/network/netinfo/cache.py", line 92, in _networks_report report_network_qos(nets_info, devices_info) File "/usr/lib/python2.7/site-packages/vdsm/network/netinfo/qos.py", line 45, in report_network_qos iface, = host_ports ValueError: too many values to unpack [root@camel-vdsa ~]# vdsm-client Host getCapabilities vdsm-client: Command Host.getCapabilities with args {} failed: (code=-32603, message=too many values to unpack) [root@camel-vdsa ~]# brctl show bridge name bridge id STP enabled interfaces m1 8000.90e2ba18de7d no ens1f1.165 ens1f1.166 vdsm should behave more leniently in such case. Version-Release number of selected component (if applicable): vdsm-4.20.1-180.git07508e2.el7.centos.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attach vlan tagged network to host via setup networks 2. On the host, manually edit the vlan interface with different tag 3. Restart network service Actual results: vdsm is dead Expected results: vdsm should stay alive Additional info: Dan, i was trying to reproduce it with brctl addif without any restart(as suggested), but i couldn't reproduce(was i missing a step?). brctl addbr net1 brctl addif net1 enp6s0 vdsm is alive