Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1101505

Summary: Turning NIC down with IP link command is not projected to VDSM
Product: Red Hat Enterprise Virtualization Manager Reporter: GenadiC <gcheresh>
Component: vdsmAssignee: Antoni Segura Puimedon <asegurap>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Michael Burman <mburman>
Severity: high Docs Contact:
Priority: medium    
Version: 3.4.0CC: bazulay, danken, gklein, iheim, lpeer, mburman, myakove, nyechiel, oblaut, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.5.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-08 18:34: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:
Attachments:
Description Flags
supervdsm and vdsm logs. vdsStats. none

Description GenadiC 2014-05-27 11:05:24 UTC
Description of problem:
Turning NIC with 3 VLAN networks down with ip link command is not projected to the VDSM - getVdsStats shows NIC as up,though ip addr shows it's down

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


How reproducible:
Always

Steps to Reproduce:
1. Put 3 VLAN networks on eth1 of the Host
2. ip link set down dev eth1
3.

Actual results:
getVdsStats shows interface as up and as a result this is what the user get in GUI

Expected results:
The interface should go down and the GUI should show the interface being down

Additional info:
ip addr show dev eth1 shows interface as down

Comment 1 Michael Burman 2014-05-27 11:13:39 UTC
Created attachment 899472 [details]
supervdsm and vdsm logs. vdsStats.

Comment 2 Michael Burman 2014-05-27 12:25:09 UTC
Though all 3 VLAN networks are attached to eth1 (GUI and vdsCaps), vdsStats shows that on eth1 there is only one VLAN, the rest are on eth2 and eth3 (one on each)
So there is incorrect information representation for vdsStats and vdsCaps on the Host

Comment 3 Dan Kenigsberg 2014-06-05 11:28:34 UTC
from the attachement:

'eth1': {'name': 'eth1',                                                   
         'rxDropped': '0',                                                 
         'rxErrors': '1',                                                  
         'rxRate': '0.0',                                                  
         'speed': '1000',                                                  
         'state': 'up',                                                    
         'txDropped': '0',                                                 
         'txErrors': '0',                                                  
         'txRate': '0.0'},

Comment 4 Dan Kenigsberg 2014-06-05 12:27:28 UTC
Could you provide more info about your kernel and and /usr/bin/ip in general? I do not reproduce this issue on centos6.5.

Could you report the output of

 python -c 'import ethtool;print hex(ethtool.get_flags("eth1"))'

Comment 5 Antoni Segura Puimedon 2014-06-06 16:14:59 UTC
Indeed I can't reproduce. On el6.5 I do:

1. create the devs
    toniel602 tests (ae9d21f) # ip link add link eth5 name eth5.1 type vlan id 1
    toniel602 tests (ae9d21f) # ip link add link eth5 name eth5.2 type vlan id 2
    toniel602 tests (ae9d21f) # ip link add link eth5 name eth5.3 type vlan id 3

2. Take them up:
    toniel602 tests (ae9d21f) # ip link set dev eth5 up   
    toniel602 tests (ae9d21f) # ip link set dev eth5.1 up
    toniel602 tests (ae9d21f) # ip link set dev eth5.2 up
    toniel602 tests (ae9d21f) # ip link set dev eth5.3 up

3. check vdsStats
    toniel602 tests (ae9d21f) # vdsClient -s 0 getVdsStats
	anonHugePages = '34'
	...
	network = {';vdsmdummy;': {'name': ';vdsmdummy;',
        ...
	           'eth5': {'name': 'eth5',
	                    'rxDropped': '0',
	                    'rxErrors': '0',
	                    'rxRate': '0.0',
	                    'speed': '1000',
	                    'state': 'up',
	                    'txDropped': '0',
	                    'txErrors': '0',
	                    'txRate': '0.0'},
	           'eth5.1': {'name': 'eth5.1',
	                      'rxDropped': '0',
	                      'rxErrors': '0',
	                      'rxRate': '0.0',
	                      'speed': '1000',
	                      'state': 'up',
	                      'txDropped': '0',
	                      'txErrors': '0',
	                      'txRate': '0.0'},
	           'eth5.2': {'name': 'eth5.2',
	                      'rxDropped': '0',
	                      'rxErrors': '0',
	                      'rxRate': '0.0',
	                      'speed': '1000',
	                      'state': 'up',
	                      'txDropped': '0',
	                      'txErrors': '0',
	                      'txRate': '0.0'},
	           'eth5.3': {'name': 'eth5.3',
	                      'rxDropped': '0',
	                      'rxErrors': '0',
	                      'rxRate': '0.0',
	                      'speed': '1000',
	                      'state': 'up',
	                      'txDropped': '0',
	                      'txErrors': '0',
	                      'txRate': '0.0'},
	...
	vmMigrating = 0

Seeing that the relevant devices are all up, do:

    toniel602 tests (ae9d21f) # ip link set dev eth5 down 

Then check the vdsStats:

    toniel602 tests (ae9d21f) # vdsClient -s 0 getVdsStats
            ...
            network = {';vdsmdummy;': {'name': ';vdsmdummy;',
            ...
                       'eth5': {'name': 'eth5',
                                'rxDropped': '0',
                                'rxErrors': '0',
                                'rxRate': '0.0',
                                'speed': '1000',
                                'state': 'down',
                                'txDropped': '0',
                                'txErrors': '0',
                                'txRate': '0.0'},
                       'eth5.1': {'name': 'eth5.1',
                                  'rxDropped': '0',
                                  'rxErrors': '0',
                                  'rxRate': '0.0',
                                  'speed': '1000',
                                  'state': 'down',
                                  'txDropped': '0',
                                  'txErrors': '0',
                                  'txRate': '0.0'},
                       'eth5.2': {'name': 'eth5.2',
                                  'rxDropped': '0',
                                  'rxErrors': '0',
                                  'rxRate': '0.0',
                                  'speed': '1000',
                                  'state': 'down',
                                  'txDropped': '0',
                                  'txErrors': '0',
                                  'txRate': '0.0'},
                       'eth5.3': {'name': 'eth5.3',
                                  'rxDropped': '0',
                                  'rxErrors': '0',
                                  'rxRate': '0.0',
                                  'speed': '1000',
                                  'state': 'down',
                                  'txDropped': '0',
                                  'txErrors': '0',
                                  'txRate': '0.0'},
            ...
            vmMigrating = 0

As seen above, the device providing link (eth5) is down as are the
vlan devices.

Comment 6 Michael Burman 2014-06-08 08:05:45 UTC
2.6.32-431.17.1.el6.x86_64- kernel version of the host pink-vds3.qa.lab.tlv.redhat.com

I can't reproduce too at this stage.
The incorrect information representation for vdsStats and vdsCaps on the Host, solved after restarting the super vdsm and vdsm services, and from that moment i couldn't reproduce this bug.

Comment 7 Dan Kenigsberg 2014-06-08 18:34:49 UTC
Odd indeed. Maybe the host stats thread stopped collecting data and missed the state change. Please reopen when this oddity is reproduced, and report

 python -c 'import ethtool;print hex(ethtool.get_flags("eth1"))'

so we can tell if it's a system issue or a Vdsm bug.