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
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?
(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.
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).
(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.
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?
Thank you for pointing this. Closing as duplicate *** This bug has been marked as a duplicate of bug 999975 ***