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

Bug 1198005

Summary:	engine keeps vlanid as integer. Exception when using fcoe
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Pavel Zhukov <pzhukov>
Component:	ovirt-engine	Assignee:	Lior Vernia <lvernia>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	3.4.4	CC:	amureini, bazulay, ecohen, gklein, iheim, lpeer, lsurette, lvernia, oourfali, pzhukov, rbalakri, Rhev-m-bugs, yeylon, ylavi
Target Milestone:	---
Target Release:	3.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	network
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 08:26:55 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:

Description Pavel Zhukov 2015-03-03 08:11:09 UTC

Description of problem:
If there are FCoE interfaces in the system engine throws an exception NumberFormatException in addHostVlanDevices. It tries to cast string to int but string has format "DDD-fcoe" so it fails  Auto_VLAN=no is not supported by bnx2fc so either vdsm or engine code must filter non-numeric vlans or handle it properly

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


How reproducible:
100%

Steps to Reproduce:
1. Use https://access.redhat.com/solutions/1268183 to configure FCoe with bnx2fc

Actual results:
NumberFormatException

Comment 1 Yaniv Lavi 2015-03-04 12:52:04 UTC

The action item here is to update the kbase to not get this problem, can you review it and see if the steps are correct?

Comment 2 Pavel Zhukov 2015-03-04 12:57:32 UTC

(In reply to Yaniv Dary from comment #1)
> The action item here is to update the kbase to not get this problem, can you
> review it and see if the steps are correct?

We don't have workaround so far. The general workaround (set auto_vlan=no) doesn't work with bnx driver.

Comment 3 Lior Vernia 2015-03-04 14:01:42 UTC

Hi Pavel,

First of all, this bug was reported on 3.4 (not sure which z-stream version), so changed the version accordingly. In fact, in 3.5 this might be fixed.

This definitely can't work on versions before 3.5 when the interface name isn't of format "<nic-name>.<vlan-id>" - it is indeed the "-fcoe" suffix that screws things up.

I'm not very knowledgeable about FCoE, is it possible to simply rename the ifcfg file (I assume they're originally created by a FCoE command/daemon), update the ifcfg file's contents and restart the network service? Would FCoE remain functional?

Again, in 3.5 I'd expect things to work (once the bond issue is resolved).

Comment 4 Pavel Zhukov 2015-03-04 14:25:34 UTC

(In reply to Lior Vernia from comment #3)
> Hi Pavel,
> 
> First of all, this bug was reported on 3.4 (not sure which z-stream
> version), so changed the version accordingly. In fact, in 3.5 this might be
> fixed.

vdsm-4.14.18-4.el6ev.x86_64  
rhevm-3.4.4-2.2.el6ev.noarch   

> 
> This definitely can't work on versions before 3.5 when the interface name
> isn't of format "<nic-name>.<vlan-id>" - it is indeed the "-fcoe" suffix
> that screws things up.
> 
> I'm not very knowledgeable about FCoE, is it possible to simply rename the
> ifcfg file (I assume they're originally created by a FCoE command/daemon),
> update the ifcfg file's contents and restart the network service? Would FCoE
> remain functional?
> 
No, it's not possible. ifcfg file itself doesn't contain the suffix. It's being added by fcoemon program which is binary (some kind of analog of ifup script).

Example:
# cat ifcfg-em1_1 
HWADDR="00:0A:F7:66:ED:B0"
ONBOT=yes
PEERDNS=no

result:
# ifconfig -a 
em1_1.1001-fcoe Link encap:Ethernet  HWaddr 00:0A:F7:66:ED:B0  
          inet6 addr: fe80::20a:f7ff:fe66:edb0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)



> Again, in 3.5 I'd expect things to work (once the bond issue is resolved).
I don't think so (I can be mistaken of course. can you please elaborate a little which commit is supposed to fix this?). However I don't have FCoE infrastructure to test it.

Comment 5 Lior Vernia 2015-03-04 15:11:24 UTC

Bug 999975 was fixed in 3.5, allowing for arbitrarily-named VLAN devices to be correctly displayed in the engine.

If this indeed turns out to be fine in 3.5, will the 3.4 issue still be relevant? Or should everything be upgraded to 3.5?

Comment 6 Pavel Zhukov 2015-03-05 08:26:55 UTC

Thank you for pointing this. Closing as duplicate

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