Bug 1319323 - [RFE] Do not check VLAN ID for duplicates (allow them on different networks, DCs... ?)
Summary: [RFE] Do not check VLAN ID for duplicates (allow them on different networks, ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: 3.6.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.1.4
: 4.1.4
Assignee: Leon Goldberg
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks: 1410490
TreeView+ depends on / blocked
 
Reported: 2016-03-18 20:54 UTC by bill.james@j2.com
Modified: 2017-10-09 08:10 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1410490 (view as bug list)
Environment:
Last Closed: 2017-07-28 14:20:14 UTC
oVirt Team: Network
rule-engine: ovirt-4.1+
mburman: testing_plan_complete+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 57571 0 ovirt-engine-3.6 ABANDONED engine: remove VLAN_ID uniqueness across DC networks validation 2016-08-29 14:09:15 UTC
oVirt gerrit 78887 0 ovirt-engine-4.1 MERGED backend: don't check for duplicate vlan ids 2017-07-04 12:35:57 UTC
oVirt gerrit 78888 0 ovirt-engine-4.1 MERGED frontend: disallow duplicate vlan ids on a single interface 2017-07-04 12:36:41 UTC

Description bill.james@j2.com 2016-03-18 20:54:12 UTC
Description of problem:
Adding new network with vlan tag, ovirt doesn't allow duplicate VLAN IDs.
But it should be allowed, because if you are using multiple interfaces you can have the same vlan ID as long as they aren't assigned to the same interface on the hardware node.


Version-Release number of selected component (if applicable):
ovirt-engine-3.6.3.4-1.el7.centos.noarch


How reproducible:
100%

Steps to Reproduce:
1. Just add network with same vlan id as an already added interface.

2.
3.

Actual results:
See email thread labeled "Re: [ovirt-users] multiple NICs VLAN ID conflict".
GUI says vlan already used.

Expected results:
Duplicate VLAN ID should be checked when you are assign network to the hardware node, not when creating the interface.


Additional info:
Trying to work around this with vdsm hooks in before_network_setup, after_get_caps and after_get_stats is very difficult to get it to work right. (see email thread)

Comment 1 Yaniv Kaul 2016-03-20 07:12:24 UTC
Perhaps only WARN.

Comment 2 bill.james@j2.com 2016-03-23 21:21:38 UTC
(In reply to Yaniv Kaul from comment #1)
> Perhaps only WARN.

Just warning at network creation time would be fine too.

Comment 3 bill.james@j2.com 2016-03-30 16:31:59 UTC
Any chance I could get a "patch" or "hack" that could change the rejection to a warning?
Unfortunately this is holding up me being able to deploy oVirt.

ovirt-engine-3.6.3.4-1.el7.centos.noarch

Comment 4 Dan Kenigsberg 2016-05-17 14:47:40 UTC
I'm afraid that we should fix Engine to accept this. Yevgeni, how hard is the fix?

Bill, can you add a reference to the email thread? I'd like to understand which problem you have seen with implementing this with a vdsm hook.

Comment 5 Yevgeny Zaspitsky 2016-05-17 15:22:18 UTC
The change on the engine side for the "add network" flow seems quite easy to me.
However it might break some decisions that were made based on the assumption that VLAN_ID is unique across a DC networks.

Bill, could you please explain the use-case where multiple networks could bear the same VLAN_ID in a single data-center?

Comment 6 bill.james@j2.com 2016-05-17 15:34:56 UTC
We have 4 different switches in our prod datacenter that cover different products and usage requirements. We want to keep some products separate from others which is why they have their own switch and set of subnets.
Since they are separate switches there was no need to be concerned about keeping VLAN IDs unique across switches.
With virtualization we don't mind mixing products on same hardware, but want to keep network traffic separated. So our hardware nodes have 8 NICs to handle all the different network switches. Our previous virtualization platform didn't have any problem with duplicate VLAN IDs so this wasn't an issue. Until we tried to move to oVirt.

Comment 7 Yevgeny Zaspitsky 2016-05-17 16:30:36 UTC
Bill,

I've created the Gerrit patch [1] that removes the validation.
Please let us know if you're able to consume the patch (build oVirt from its sources) and if the patch does what you ask for.

[1] http://gerrit.ovirt.org/57571

Comment 8 Dan Kenigsberg 2016-05-18 12:30:37 UTC
The request was discussed on http://lists.ovirt.org/pipermail/users/2016-March/038463.html

Comment 9 bill.james@j2.com 2016-06-13 15:33:56 UTC
sorry, I haven't had a chance to setup a build host for ovirt yet so haven't tested the patch.

Comment 10 Steffen Froemer 2017-02-10 08:26:59 UTC
As I can see, the gerrit case is abandoned, what's the real status of this request? What is needed, to get this accepted and included in ovirt?

Comment 11 Yaniv Lavi 2017-02-13 23:13:32 UTC
(In reply to Steffen Froemer from comment #10)
> As I can see, the gerrit case is abandoned, what's the real status of this
> request? What is needed, to get this accepted and included in ovirt?

It is not POST, there are no plans currently to enable this for 4.1. The only option is to consider it for 4.2.

Comment 15 Red Hat Bugzilla Rules Engine 2017-07-03 08:14:10 UTC
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Comment 16 Michael Burman 2017-07-09 11:48:52 UTC
Verified on - 4.2.0-0.0.master.20170707124946.gitf15a6d9.el7.centos

1) Create networks with same vlan IDs in the DC 
2) Attach networks with same vlan IDs to the same host(not one interface)
3) Validate when trying to attach networks with same vlan IDs to one interface on the host

Comment 17 Michael Burman 2017-07-09 11:55:44 UTC
Verified on - 4.1.4-0.2.el7


Note You need to log in before you can comment on or make changes to this bug.