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

Bug 1081489

Summary: replacing vlan tag fails when that network is attached to bond
Product: Red Hat Enterprise Virtualization Manager Reporter: GenadiC <gcheresh>
Component: vdsmAssignee: Antoni Segura Puimedon <asegurap>
Status: CLOSED ERRATA QA Contact: GenadiC <gcheresh>
Severity: urgent Docs Contact:
Priority: high    
Version: 3.4.0CC: acathrow, bazulay, danken, gcheresh, gklein, iheim, lbopf, lpeer, masayag, myakove, nyechiel, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.4.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously, a host with VLAN-tagged network attached to bond would become unsynced after network update, and the unsynced network could not be removed from the host. Now, the VLAN tag is successfully updated on the host bond.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 13:29:54 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
engine and vdsm log
none
new engine and vdsm logs
none
engine, vdsm and supervdsm logs none

Description GenadiC 2014-03-27 12:45:11 UTC
Created attachment 879447 [details]
engine and vdsm log

Description of problem:
If you attach tagged network to bond on Host and try to update the Network (for muliHost feature) instead of update on the Host you get the network in unsynced state.
Remove of that network or breading the bond fails with "Error while executing action Setup Networks: Unexpected exception"

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


How reproducible:
Always

Steps to Reproduce:
1. Create Network with VLAN 163 and attach it to the bond on Host
2. Update the network with VLAN 164
3.

Actual results:
The network gets into unsynced state and can't be removed

Expected results:
The network should be updated on the bond of the host

Additional info:
For regular NIC (not a bond) the behaviour is good

Comment 1 GenadiC 2014-03-27 15:33:42 UTC
Updated VLAN network over bond to be untagged over bond fails in the same way

Comment 2 Dan Kenigsberg 2014-03-31 13:19:21 UTC
Genady, your true Engine sits in 10.35.162.28, but vdsm.log is filled with noise from 0.35.161.40. Please remove the host from there as it confuses the logs.

Has supervdsmd crashed? Could you attach its log?

Thread-392::ERROR::2014-03-27 14:36:55,653::BindingXMLRPC::1086::vds::(wrapper) unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/BindingXMLRPC.py", line 494, in setupNetworks
    return api.setupNetworks(networks, bondings, options)
  File "/usr/share/vdsm/API.py", line 1297, in setupNetworks
    supervdsm.getProxy().setupNetworks(networks, bondings, options)
  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 setupNetworks
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 740, in _callmethod
    raise convert_to_error(kind, result)
AssertionError

Comment 3 GenadiC 2014-03-31 14:19:32 UTC
Created attachment 880763 [details]
new engine and vdsm logs

Comment 4 GenadiC 2014-03-31 14:20:54 UTC
I have noticed that in order to reproduce this bug you should first create a network as untagged, then put a VLAN on it and after that change the VLAN to some other value.
Only then you get to unsync state as mentioned in the bug
New logs are attached

Comment 5 Dan Kenigsberg 2014-04-01 10:45:58 UTC
Genady, you still have an old Engine in 10.35.161.40 trashing vdsm log, and supervdsm.log is still missing.

Comment 6 Dan Kenigsberg 2014-04-01 10:48:51 UTC
However, an interesting exception can be seen:

Thread-28::DEBUG::2014-03-31 17:11:27,917::BindingXMLRPC::1067::vds::(wrapper) client [10.35.162.28]::call setupNetworks with ({'multinet': {'bonding': 'bond0', 'vlan': '167', 'STP': 'no', 'bridged': 'true'}}, {}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {} flowID [28299346]
Thread-12::ERROR::2014-03-31 17:11:28,147::sampling::423::vds::(run) Error while sampling stats
Traceback (most recent call last):
  File "/usr/share/vdsm/sampling.py", line 412, in run
    sample = self.sample()
  File "/usr/share/vdsm/sampling.py", line 401, in sample
    self._updateIfidsIfrates()
  File "/usr/share/vdsm/sampling.py", line 388, in _updateIfidsIfrates
    devices = getLinks()
  File "/usr/lib64/python2.6/site-packages/vdsm/ipwrapper.py", line 286, in getLinks
    return [Link.fromDict(data) for data in netlink.iter_links()]
  File "/usr/lib64/python2.6/site-packages/vdsm/ipwrapper.py", line 147, in fromDict
    data['linkType'] = cls._detectType(data['name'])
  File "/usr/lib64/python2.6/site-packages/vdsm/ipwrapper.py", line 172, in _detectType
    driver = _drvinfo(name)
  File "/usr/lib64/python2.6/site-packages/vdsm/ipwrapper.py", line 268, in _drvinfo
    fcntl.ioctl(sock, SIOCETHTOOL, data)
IOError: [Errno 19] No such device

Comment 7 GenadiC 2014-04-01 13:24:53 UTC
Created attachment 881351 [details]
engine, vdsm and supervdsm logs

Comment 8 Moti Asayag 2014-04-03 21:37:54 UTC
Dan, see the trackback from supervdsm.log (275):

MainProcess|Thread-392::DEBUG::2014-03-27 14:36:55,651::utils::662::root::(execCmd) SUCCESS: <err> = ''; <rc> = 0
MainProcess|Thread-392::ERROR::2014-03-27 14:36:55,652::supervdsmServer::100::SuperVdsm.ServerCallback::(wrapper) Error in setupNetworks
Traceback (most recent call last):
  File "/usr/share/vdsm/supervdsmServer", line 98, in wrapper
    res = func(*args, **kwargs)
  File "/usr/share/vdsm/supervdsmServer", line 202, in setupNetworks
    return configNetwork.setupNetworks(networks, bondings, **options)
  File "/usr/share/vdsm/configNetwork.py", line 613, in setupNetworks
    implicitBonding=False)
  File "/usr/share/vdsm/configNetwork.py", line 186, in wrapped
    return func(*args, **kwargs)
  File "/usr/share/vdsm/configNetwork.py", line 394, in delNetwork
    nics, vlan, bonding = _netinfo.getNicsVlanAndBondingForNetwork(network)
  File "/usr/lib64/python2.6/site-packages/vdsm/netinfo.py", line 749, in getNicsVlanAndBondingForNetwork
    assert bonding is None
AssertionError

Comment 10 Dan Kenigsberg 2014-04-09 17:10:22 UTC
When deleting the old implementation of the network, Vdsm notices that the relevant bridge has a bonding device connected directly, and explodes.

This seems to be a duplicate of bug 1071398 and bug 1082275.

Would you verify this, by checking build av7 (or the tip of ovirt-3.4 branch)?

Comment 11 GenadiC 2014-04-27 07:45:00 UTC
Indeed solved in av7

Comment 12 GenadiC 2014-04-27 09:44:37 UTC
Verified in AV7

Comment 13 errata-xmlrpc 2014-06-09 13:29:54 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.

http://rhn.redhat.com/errata/RHBA-2014-0504.html