This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1467058 - [downstream clone - 4.1.4] [RFE] Do not check VLAN ID for duplicates (allow them on different networks, DCs... ?)
[downstream clone - 4.1.4] [RFE] Do not check VLAN ID for duplicates (allow t...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.9
All Linux
medium Severity high
: ovirt-4.1.4
: ---
Assigned To: Leon Goldberg
Michael Burman
: FutureFeature, ZStream
Depends On: 1410490
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-02 06:40 EDT by rhev-integ
Modified: 2017-07-27 14:02 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Previously, when creating a new VLAN-tagged network, the Manager did not allow the same VLAN ID to be duplicated across various entities, such as networks and data centers. In this release, it is now possible to use the same VLAN ID across multiple entities, as long as they are not used on the same interface on the hardware node.
Story Points: ---
Clone Of: 1410490
Environment:
Last Closed: 2017-07-27 14:02:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 57571 None None None 2017-07-02 06:42 EDT
oVirt gerrit 78303 master MERGED backend: don't check for duplicate vlan ids 2017-07-02 06:42 EDT
oVirt gerrit 78887 ovirt-engine-4.1 MERGED backend: don't check for duplicate vlan ids 2017-07-04 08:35 EDT
oVirt gerrit 78888 ovirt-engine-4.1 MERGED frontend: disallow duplicate vlan ids on a single interface 2017-07-04 08:36 EDT

  None (edit)
Description rhev-integ 2017-07-02 06:40:16 EDT
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1410490 +++
======================================================================

+++ This bug was initially created as a clone of Bug #1319323 +++

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)

--- Additional comment from Yaniv Kaul on 2016-03-20 03:12:24 EDT ---

Perhaps only WARN.

--- Additional comment from bill.james@j2.com on 2016-03-23 17:21:38 EDT ---

(In reply to Yaniv Kaul from comment #1)
> Perhaps only WARN.

Just warning at network creation time would be fine too.

--- Additional comment from bill.james@j2.com on 2016-03-30 12:31:59 EDT ---

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

--- Additional comment from Dan Kenigsberg on 2016-05-17 10:47:40 EDT ---

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.

--- Additional comment from Yevgeny Zaspitsky on 2016-05-17 11:22:18 EDT ---

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?

--- Additional comment from bill.james@j2.com on 2016-05-17 11:34:56 EDT ---

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.

--- Additional comment from Yevgeny Zaspitsky on 2016-05-17 12:30:36 EDT ---

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

--- Additional comment from Dan Kenigsberg on 2016-05-18 08:30:37 EDT ---

The request was discussed on http://lists.ovirt.org/pipermail/users/2016-March/038463.html

--- Additional comment from bill.james@j2.com on 2016-06-13 11:33:56 EDT ---

sorry, I haven't had a chance to setup a build host for ovirt yet so haven't tested the patch.

(Originally by Vaibhav Pagar)
Comment 8 rhev-integ 2017-07-02 06:41:07 EDT
Would you be willing to try out an upstream build with the suggested patch, to help in testing it?

(Originally by danken)
Comment 18 Michael Burman 2017-07-10 06:28:13 EDT
Verified on - 4.1.4-0.2.el7
Comment 21 errata-xmlrpc 2017-07-27 14:02:44 EDT
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.

https://access.redhat.com/errata/RHEA-2017:1814

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