Bug 1730264
Summary: | VMs will fail to start if the vnic profile attached is having port mirroring enabled and have name greater than 15 characters | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | nijin ashok <nashok> | |
Component: | ovirt-engine | Assignee: | Ales Musil <amusil> | |
Status: | CLOSED ERRATA | QA Contact: | Michael Burman <mburman> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 4.3.4 | CC: | amusil, dholler, edwardh, mburman, pelauter, rdlugyhe | |
Target Milestone: | ovirt-4.4.0 | Keywords: | ZStream | |
Target Release: | 4.4.0 | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
Previously, enabling port mirroring on networks whose user-visible name was longer than 15 characters failed. This happened because port mirroring tried to use this long user-visible network name, which was not a valid network name. The current release fixes this issue. Now, instead of the user-visible name, port mirroring uses the VDSM network name. Therefore, you can enable port mirroring for networks whose user-visible name is longer than 15 characters.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1744571 (view as bug list) | Environment: | ||
Last Closed: | 2020-08-04 13:19:49 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: | 1765018 | |||
Bug Blocks: | 1744571 |
Description
nijin ashok
2019-07-16 11:08:32 UTC
QE managed to reproduce. Edy, can you please take a look? is it vdsm to handle or is it engine side? Thanks, (In reply to Michael Burman from comment #2) > QE managed to reproduce. > Edy, can you please take a look? is it vdsm to handle or is it engine side? > > Thanks, Looks like Engine side. The long-name should never reach VDSM in the current solution. sync2jira sync2jira I have no idea how this is possible, but the issue reproduced on rhv-4.4.0 4.4.0-0.4.master.el7 vdsm-4.40.0-127.gitc628cce.el8ev.x86_64 rhel8.1 MainProcess|vm/f1473d49::ERROR::2019-10-23 07:43:13,779::supervdsm_server::96::SuperVdsm.ServerCallback::(wrapper) Error in setPortMirroring Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/vdsm/supervdsm_server.py", line 94, in wrapper res = func(*args, **kwargs) File "/usr/lib/python3.6/site-packages/vdsm/network/tc/__init__.py", line 83, in setPortMirroring _qdisc_replace_ingress(network) File "/usr/lib/python3.6/site-packages/vdsm/network/tc/__init__.py", line 119, in _qdisc_replace_ingress qdisc.add(dev, 'ingress') File "/usr/lib/python3.6/site-packages/vdsm/network/tc/qdisc.py", line 43, in add _wrapper.process_request(command) File "/usr/lib/python3.6/site-packages/vdsm/network/tc/_wrapper.py", line 44, in process_request raise TrafficControlException(retcode, err, command) vdsm.network.tc._wrapper.TrafficControlException: (2, 'Error: Exclusivity flag on, cannot modify.\n', ['/sbin/tc', 'qdisc', 'add', 'dev', 'ond0985e33f0f94', 'ingress']) MainProcess|jsonrpc/0::DEBUG::2019-10-23 07:43:13,789::supervdsm_server::92::SuperVdsm.ServerCallback::(wrapper) call unsetPortMirroring with ('ond0985e33f0f94', 'vnet1') {} This is a new issue, probably rhel8 related: the initial reported error was: TrafficControlException: (1, 'Cannot find device "verylongnetwork"\n', ['/sbin/tc', 'qdisc', 'add', 'dev', 'verylongnetworkname', 'ingress']) the new error is: TrafficControlException: (2, 'Error: Exclusivity flag on, cannot modify.\n', ['/sbin/tc', 'qdisc', 'add', 'dev', 'ond0985e33f0f94', 'ingress']) But never the less we should fix this. Networks with short names are affected, too. That is different issue and IIRC we had discussion some time ago that tc is not working as vdsm expects. (In reply to Ales Musil from comment #14) > That is different issue and IIRC we had discussion some time ago that tc is > not working as vdsm expects. ack Do you want new bug for that which will block this one? Yes please, to keep it separate. WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops Verified on - vdsm-4.40.0-164.git38a19bb.el8ev.x86_64 with rhvm-4.4.0-0.9.master.el7.noarch WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3247 |