Description of problem: We need to make clearer what it is possible to do, and not possible to do, with regard to VLANs and the management network. Check out this thread on [1] on the Ovirt Users list. I think to resolve this bug, we'll need these topics: VLAN tagging and the Management Logical Network [N: Concept] Preparing to VLAN tag your Management Network [N: Task] And, we'll need to add something to this topic: Adding Multiple VLANs to a Single Network Interface using Logical Networks [1]http://lists.ovirt.org/pipermail/users/2013-May/014277.html
Hi, My network topology includes several vlans plus vlan1 untugged. At this time, I can't have in ovrit an interface assigned to both an untagged network and a tagged one. Also I can't create more than one logical network in the same vlan, so if I need to use more than one subnet in the same vlan, I can't define it inside ovirt. I had to modify my network topology to adapt to ovirt capabilities and by using management network tagged I can now use all the vlans I need to access in the same interface that mgmnt network. Hope this helps. Anything else I can conrtibute, please let me know. Regards, Juan Pablo Lorier
Tim, I think the big issue is the one that Juan Pablo mentioned above in comment 1. I can't think of any other limitations off the top of my head now that you can edit the VLAN tag of the RHEV-M network. I would think that "Preparing to VLAN tag your Management Network [N: Task]" would be: - Add a vlan tag to the RHEVM network - Put a host into maintenance mode - Bring up Setup Host Networks - Click "Save configuration" - Bring host out of maintenance - Check to see if rhevm is vlan-tagged I haven't verified the above steps but it should be pretty close. Let me know if you have questions.
As per a recent discussion, I'm thinking maybe all hosts should be in maintenance if you're changing the network topology like this. Thoughts? Have you tried this, Tim?
Reassigning to Jodi Biddle (jbiddle) as I am no longer working on Red Hat Enterprise Virtualization documentation.
Hi, As I see poor movement in this bug, I post a new question: why can you just add a bridge to the bond interface and use it for untagged traffic? You are now creatting a vlan device on top of the bond and adding it to a bridge to create a new tagged network, I don't see why this can't be done straight to the bond device. I have 2 xen servers running bridges this way and vms work just fine with the vifs either tagged or untagged. This won't help in solving the mgmt network, but at least is a step forward in using mixed tagg-untagg networks.
Just to show a practical case, I'm having to migrate over 40 desktops using untagged ports to a tagged vlan because I can't get my dhcp vm to share untagged and tagged traffic. Can't at least patch network to mix tagged and untagged LN on top of the same interface? I was able to do it in the actual production vm running on top of Xen since 8 years ago. Regards,
Changing status back to 'New' until re-assignment.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
Is this still relevant after the mixed tagged and untaged networks?
(In reply to Yaniv Dary from comment #9) > Is this still relevant after the mixed tagged and untaged networks? The recent relaxation makes the request of comment 6 possible. But manipulating the vlan tag of the management network is still confusing and under-documented. People keep asking, and we have no ready guide (c.f http://lists.ovirt.org/pipermail/users/2015-November/035994.html )
Assigning to Julie for review. From RHEV 3.6, tagged and untagged VLAN networks can be used together on interfaces and bonds. There are a few sections in the Admin Guide that should be updated with this information, and more information should be provided about configuring these interfaces and bonds.
Moving back to the default assignee for re-triaging as the schedule allows.
Please separate this to correcting the info in the 3.6 guide. Once that is created, please move this one to 4.0.
I have now created bug 1322699 to ensure that the 3.6 documentation states that tagged and untagged VLAN networks can be used together on interfaces and bonds. I am retargeting this bug to 4.0.
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
In my opinion we should explain the hardships of changing the vlan id of the management network. The important point to remember is that there is no way to change the ovirt-engine's idea of a host address, except removing the host and re-adding it. When the vlan id of the the management network changes, Engine would attempt to modify network on each of the host, and is most likely to fail, as it is going to loose connectivity to the old host address. This would make all host networking out-of sync. Then, each of the hosts should be moved to maintenance, its management network manually removed of it, it should be made reachable over the new vlan, and re-added to the cluster. VM that are not connected directly to the management network can be safely migrated between hosts. Michael, is this process correct, or have I missed a step? or could it be simplified?
Yes, the process is correct and you will get the next warning message when you will try to change such property such as vlan on the management network. I will write it in steps - 1) When you will try to change the vlan id of the management network you will see this nice warning message: 'Changing certain properties (e.g. VLAN, MTU) of the management network could lead to loss of connectivity to hosts in the data center, if its underlying network infrastructure isn't configured to accommodate the changes. Are you sure you want to proceed?' 2) Once you will approve it, all the hosts in the DC could loose connectivity with the engine and the apply of changing the network will fail. Management network should be and will be reported as out-of-sync. 3) You will need to remove host/s from the engine, configure them properly with vlan configuration and install them again.
Commit Information ------------------ git.redhat.com:rhci-documentation/docs-Red_Hat_Enterprise_Virtualization.git In branch "BZ#980360": commit 6882771f1efa275e1cb794284e2a151ba0a60b14 Author: Zac Dover <zdover> Date: Wed Oct 12 14:13:26 2016 +1000 BZ#980360 - the gotchas of migrating from one management network to another What Changed ------------ I added to section 6.5.2. Editing Host Network Interfaces and Assigning Logical Networks to Hosts of the Administration Guide the following warning: The only way to change a host's IP address in Red Hat Virtualization is to remove the host and then to add it again. To keep networking synchronized, do the following. Put the host in maintenance mode and manually remove the host's management network. This will make the host reachable over the new VLAN. Add the host to the cluster. Virtual machines that are not connected directly to the management network can be migrated between hosts safely. The following warning message appears when the VLAN ID of the management network is changed: 'Changing certain properties (e.g. VLAN, MTU) of the management network could lead to loss of connectivity to hosts in the data center, if its underlying network infrastructure isn't configured to accommodate the changes. Are you sure you want to proceed?' Answering 'yes' to this question causes all of the hosts in the data center to lose connectivity to the engine and causes the migration of hosts to the new management network to fail. The management network will be reported as "out-of-sync".
* This is in the wrong procedure. The warning appears in Networks tab > select network > Edit > change value in 'Enable VLAN tagging' text field, not in Setup Host Networks. * Shouldn't be just a warning; should probably be a new procedure: 'Changing the VLAN ID of the Management Network' (under Logical Network Tasks). * Need a link to this procedure in step 4 of Editing a Logical Network: something like 'If you change the VLAN ID of the management network, the network will be desynchronized. See [xref] to change the VLAN ID and resynchronize the network.' * First line about host IP seems tangential, since this is about VLAN tagging. * Paragraphs seem out of order; resynchronizing the network comes after changing the VLAN ID. * UI warning text should be in tags (<screen>, maybe). * You don't 'answer yes' in the UI, you click OK. * Do the hosts need to be removed from the Manager, reconfigured, and reinstalled; or moved to maintenance, management network removed, and re-added to the cluster? Comments 19 and 20 disagree.
(In reply to Tahlia Richardson from comment #22) > * This is in the wrong procedure. The warning appears in Networks tab > > select network > Edit > change value in 'Enable VLAN tagging' text field, > not in Setup Host Networks. > > * Shouldn't be just a warning; should probably be a new procedure: 'Changing > the VLAN ID of the Management Network' (under Logical Network Tasks). > > * Need a link to this procedure in step 4 of Editing a Logical Network: > something like 'If you change the VLAN ID of the management network, the > network will be desynchronized. See [xref] to change the VLAN ID and > resynchronize the network.' > > * First line about host IP seems tangential, since this is about VLAN > tagging. > > * Paragraphs seem out of order; resynchronizing the network comes after > changing the VLAN ID. > > * UI warning text should be in tags (<screen>, maybe). > > * You don't 'answer yes' in the UI, you click OK. > > * Do the hosts need to be removed from the Manager, reconfigured, and > reinstalled; or moved to maintenance, management network removed, and > re-added to the cluster? Comments 19 and 20 disagree. Hosts need to be removed from rhv-m, reconfigured and then re-installed.
Published for 4.0: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html-single/administration_guide/#sect-Hosts_and_Networking And 4.1-Beta: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1-beta/html-single/administration_guide/#sect-Hosts_and_Networking