Red Hat Bugzilla – Bug 1467058
[downstream clone - 4.1.4] [RFE] Do not check VLAN ID for duplicates (allow them on different networks, DCs... ?)
Last modified: 2017-07-27 14:02:44 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):
Steps to Reproduce:
1. Just add network with same vlan id as an already added interface.
See email thread labeled "Re: [ovirt-users] multiple NICs VLAN ID conflict".
GUI says vlan already used.
Duplicate VLAN ID should be checked when you are assign network to the hardware node, not when creating the interface.
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 firstname.lastname@example.org 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 email@example.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.
--- 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 firstname.lastname@example.org 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 ---
I've created the Gerrit patch  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.
--- 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 email@example.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)
Would you be willing to try out an upstream build with the suggested patch, to help in testing it?
(Originally by danken)
Verified on - 4.1.4-0.2.el7
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.