Bug 1255106 - Shut down of a VM with Port Mirroring Profile ends up with vdsm errors every few seconds and host recognize the VM as running on host
Shut down of a VM with Port Mirroring Profile ends up with vdsm errors every ...
Status: CLOSED DUPLICATE of bug 1254713
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.6.0
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: nobody nobody
Michael Burman
network
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-19 12:06 EDT by Michael Burman
Modified: 2016-02-10 14:50 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-20 02:27:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logs and screen shots (936.84 KB, application/x-gzip)
2015-08-19 12:06 EDT, Michael Burman
no flags Details

  None (edit)
Description Michael Burman 2015-08-19 12:06:07 EDT
Created attachment 1064925 [details]
logs and screen shots

Description of problem:
Shut down of a VM with Port Mirroring Profile ends up with vdsm errors every few seconds and host recognize the VM as running on host.

Shutting down a VM with Port Mirroring profile will end up with errors in event log, vdsm and super vdsm log -->

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 522, in _serveRequest
    res = method(**params)
  File "/usr/share/vdsm/rpc/Bridge.py", line 277, in _dynamicMethod
    result = fn(*methodArgs)
  File "/usr/share/vdsm/API.py", line 337, in destroy
    res = v.destroy()
  File "/usr/share/vdsm/virt/vm.py", line 3757, in destroy
    result = self.doDestroy()
  File "/usr/share/vdsm/virt/vm.py", line 3775, in doDestroy
    return self.releaseVm()
  File "/usr/share/vdsm/virt/vm.py", line 3675, in releaseVm
    supervdsm.getProxy().unsetPortMirroring(network, nic.name)
  File "/usr/share/vdsm/supervdsm.py", line 50, in __call__
    return callMethod()
  File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>
    **kwargs)
  File "<string>", line 2, in unsetPortMirroring
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod
    raise convert_to_error(kind, result)
TrafficControlException: (22, 'RTNETLINK answers: Invalid argument', ['/usr/sbin/tc', 'qdisc', 'del', 'dev', u'net-1', 'ingress'])

- [root@orchid-vds2 ~]# vdsClient -s 0 list table
8f6dc4a3-ff06-4eb5-8824-a58e4d484e8c   4797  vm3_sriov            Down                                     

- [root@orchid-vds2 ~]# virsh -r list
 Id    Name                           State
----------------------------------------------------



Sorry, but i wasn't sure if it's a network or virt bug.
The logs got filled with those errors every few seconds.
Only rebooting the server will resolve this and host will no longer see the VM as running on host.
This happens only with Port Mirroring profiles from what i tested.


Version-Release number of selected component (if applicable):
3.6.0-0.11.master.el6

How reproducible:
100

Steps to Reproduce:
1. Create new network(net-1) and attach to host. 
2. Enable Port Mirroring on 'net-1' profile and add to VM
3. Run VM, wait until it finishing the launch and then shut it down

Actual results:
VDSM orchid-vds2.qa.lab.tlv.redhat.com command failed: (22, 'RTNETLINK answers: Invalid argument', ['/usr/sbin/tc', 'qdisc', 'del', 'dev', u'net-1', 'ingress'])

errors in event, vdsm and supervdsm logs. And in /var/log/messages as well now i see, the log is spammed as well.

Expected results:
Shut down VM should work as expected for all vNIC profiles.
Comment 1 Michael Burman 2015-08-19 12:10:02 EDT
It trying to run the same VM again, then failing because VM is got stuck on host, only reboot will fix it and i will be able to run this VM on this server again. Thanks,
Comment 2 Michael Burman 2015-08-20 02:27:43 EDT

*** This bug has been marked as a duplicate of bug 1254713 ***

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