Bug 1091863

Summary: OVIRT35 - [RFE] Accept vlan devices identified by any name
Product: [Retired] oVirt Reporter: Alona Kaplan <alkaplan>
Component: ovirt-engine-coreAssignee: Alona Kaplan <alkaplan>
Status: CLOSED CURRENTRELEASE QA Contact: Meni Yakove <myakove>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.5CC: asegundo, bazulay, danken, gklein, iheim, lpeer, lvernia, masayag, mburman, myakove, nyechiel, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: 3.5.0   
Hardware: All   
OS: Linux   
Whiteboard: network
Fixed In Version: ovirt-3.5.0-beta2 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 999975 Environment:
Last Closed: 2014-10-17 12:39:02 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:
Bug Depends On: 999975    
Bug Blocks:    

Description Alona Kaplan 2014-04-28 08:37:32 UTC
+++ This bug was initially created as a clone of Bug #999975 +++

Currently ovirt-engine can not handle vlans with names not in standard "dev.VLANID" (e.g. eth0.10-fcoe, em1.myvlan10, vlan20, ...).

If host has a vlan already created with an alternative name, host can not get activated and engine shows the error:

2013-08-22 10:21:03,315 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-29) Failed in GetCapabilitiesVDS method, for vds: vdsm-devel; host: 192.168.122.158
2013-08-22 10:21:03,316 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-29) Command GetCapabilitiesVDS execution failed. Exception: NumberFormatException: For input string: "myvlan40"

engine is trying to deduct vlan id from vlan name. After split the name, engine is hoping for "myvlan40" as vlan ID, which is clearly not true.

Commit "8b2bbe6 [2/3] Add "vlanid" to VLAN information" introduced in vdsm the ability to report the vlan id as an independent field, regardless the vlan name. Now engine must be fixed to get vlan id from this new field instead of deducting it from vlan name.

Steps to Reproduce:
- Change Host to maintenance mode.
- Add a vlan with alternative name to the Host:
 # ip link add dev eth1.myvlan10 link eth1 name eth1.myvlan10 type vlan id 10
- Activate the Host.

--- Additional comment from lpeer on 2013-08-27 01:55:29 EDT ---

A fix for this bug should be on the VDSM side. Reporting of the VLAN tag instead of the vlan device name.

--- Additional comment from Dan Kenigsberg on 2013-08-27 16:38:42 EDT ---

(In reply to lpeer from comment #1)
> A fix for this bug should be on the VDSM side. Reporting of the VLAN tag
> instead of the vlan device name.

Livnat, I believe that the vdsm side is already done upstream:
http://gerrit.ovirt.org/18180
http://gerrit.ovirt.org/18181
http://gerrit.ovirt.org/18182
http://gerrit.ovirt.org/18449

and that we are left with collecting this information in Engine. Amador, haven't you started an Engine-side patch for this?

--- Additional comment from Amador Pahim on 2013-08-27 16:58:35 EDT ---

(In reply to Dan Kenigsberg from comment #2)
> (In reply to lpeer from comment #1)
> > A fix for this bug should be on the VDSM side. Reporting of the VLAN tag
> > instead of the vlan device name.
> 
> Livnat, I believe that the vdsm side is already done upstream:
> http://gerrit.ovirt.org/18180
> http://gerrit.ovirt.org/18181
> http://gerrit.ovirt.org/18182
> http://gerrit.ovirt.org/18449
> 

Yes, upstream vdsm is reporting vlanid like this:
...
        vlans = {'eth0.10': {'addr': '',
                             'cfg': {},
                             'iface': 'eth0',
                             'ipv6addrs': [],
                             'mtu': '1500',
                             'netmask': '',
                             'vlanid': 10},   <----
...
> and that we are left with collecting this information in Engine. Amador,
> haven't you started an Engine-side patch for this?

No, I have not.

--- Additional comment from John Skeoch on 2013-09-08 20:51:51 EDT ---

User giuseppe's account has been closed

Comment 1 Sandro Bonazzola 2014-10-17 12:39:02 UTC
oVirt 3.5 has been released and should include the fix for this issue.