Bug 1744571 - [downstream clone - 4.3.6] VMs will fail to start if the vnic profile attached is having port mirroring enabled and have name greater than 15 characters
Summary: [downstream clone - 4.3.6] VMs will fail to start if the vnic profile attache...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.3.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ovirt-4.3.6
: 4.3.6
Assignee: Ales Musil
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1730264
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-22 13:00 UTC by RHV bug bot
Modified: 2020-02-26 05:35 UTC (History)
6 users (show)

Fixed In Version: ovirt-engine-4.3.6.3
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1730264
Environment:
Last Closed: 2019-10-10 15:36:58 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:3010 0 None None None 2019-10-10 15:37:11 UTC
oVirt gerrit 102434 0 master MERGED core: Fix port mirror metadata for vm 2020-07-24 06:59:58 UTC
oVirt gerrit 102464 0 ovirt-engine-4.3 MERGED core: Fix port mirror metadata for vm 2020-07-24 06:59:58 UTC

Description RHV bug bot 2019-08-22 13:00:52 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1730264 +++
======================================================================

Description of problem:

If the network name is greater than 15 characters, the original name of the network will be  mapped to a different name while creating the bridge.


====
engine=# select name,vdsm_name from network where name='verylongnetworkname';
        name         |    vdsm_name    
---------------------+-----------------
 verylongnetworkname | on5604266439c64
(1 row)
====

However if the port mirroring is enabled, the vdsm still send setPortMirroring request to supervdsm with the "network name" instead of "vdsm_name". Because of this, the VM will fail to start with the error below in vdsm log since the bridge name "verylongnetworkname" doesn't exist.

====
2019-07-16 16:21:17,460+0530 ERROR (vm/b532b3ee) [virt.vm] (vmId='b532b3ee-c5f5-45e5-a1b9-136a7804b04b') The vm start process failed (vm:933)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 867, in _startUnderlyingVm
    self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2891, in _run
    self._domDependentInit()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2466, in _domDependentInit
    self._vmDependentInit()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2487, in _vmDependentInit
    supervdsm.getProxy().setPortMirroring(network, nic.name)
  File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 56, in __call__
    return callMethod()
  File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 54, in <lambda>
    **kwargs)
  File "<string>", line 2, in setPortMirroring
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod
    raise convert_to_error(kind, result)
TrafficControlException: (1, 'Cannot find device "verylongnetwork"\n', ['/sbin/tc', 'qdisc', 'add', 'dev', 'verylongnetworkname', 'ingress'])
=====

Supervdsm log shows error below.

====
MainProcess|vm/b532b3ee::ERROR::2019-07-16 16:21:17,459::supervdsm_server::103::SuperVdsm.ServerCallback::(wrapper) Error in setPortMirroring
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 101, in wrapper
    res = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/network/tc/__init__.py", line 80, in setPortMirroring
    _qdisc_replace_ingress(network)
  File "/usr/lib/python2.7/site-packages/vdsm/network/tc/__init__.py", line 116, in _qdisc_replace_ingress
    qdisc.add(dev, 'ingress')
  File "/usr/lib/python2.7/site-packages/vdsm/network/tc/qdisc.py", line 43, in add
    _wrapper.process_request(command)
  File "/usr/lib/python2.7/site-packages/vdsm/network/tc/_wrapper.py", line 43, in process_request
    raise TrafficControlException(retcode, err, command)
TrafficControlException: (1, 'Cannot find device "verylongnetwork"\n', ['/sbin/tc', 'qdisc', 'add', 'dev', 'verylongnetworkname', 'ingress'])
====

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

vdsm-4.30.17-1.el7ev.x86_64
rhvm-4.3.4.3-0.1.el7.noarch

How reproducible:

100%

Steps to Reproduce:

1. Create a network with name greater than 15 characters.
2. Enable port mirroring.
3. Attach this network to the VM and start it.

Actual results:

VMs will fail to start if the vnic profile attached is having port mirroring enabled and have name greater than 15 characters

Expected results:

VM should start.

Additional info:

(Originally by Nijin Ashok)

Comment 2 RHV bug bot 2019-08-22 13:00:56 UTC
QE managed to reproduce.
Edy, can you please take a look? is it vdsm to handle or is it engine side? 

Thanks,

(Originally by Michael Burman)

Comment 3 RHV bug bot 2019-08-22 13:00:58 UTC
(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.

(Originally by edwardh)

Comment 8 Michael Burman 2019-08-25 08:19:25 UTC
Verified on - rhvm-4.3.6.3-0.1.el7.noarch and vdsm-4.30.29-1.el7ev.x86_64

Comment 9 Daniel Gur 2019-08-28 13:15:07 UTC
sync2jira

Comment 10 Daniel Gur 2019-08-28 13:20:10 UTC
sync2jira

Comment 11 RHV bug bot 2019-09-25 08:46:48 UTC
INFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Tag 'ovirt-engine-4.3.5.6' doesn't contain patch 'https://gerrit.ovirt.org/102464']
gitweb: https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/tags/ovirt-engine-4.3.5.6

For more info please contact: rhv-devops

Comment 13 errata-xmlrpc 2019-10-10 15:36:58 UTC
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, 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/RHEA-2019:3010


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