Bug 980360 - [Docs][Admin][RFE] Add warning about changing the IP address and VLAN settings of a host
[Docs][Admin][RFE] Add warning about changing the IP address and VLAN setting...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation (Show other bugs)
unspecified
Unspecified Unspecified
medium Severity unspecified
: ovirt-4.1.1
: ---
Assigned To: Zac Dover
Lucy Bopf
: FutureFeature, Improvement
Depends On: 668847
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-02 03:32 EDT by Tim Hildred
Modified: 2017-03-23 22:41 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-23 22:41:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Docs
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Hildred 2013-07-02 03:32:36 EDT
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
Comment 1 Juan Pablo Lorier 2013-07-02 09:08:47 EDT
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
Comment 2 Bryan Yount 2013-08-08 18:15:18 EDT
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.
Comment 3 Bryan Yount 2013-09-04 12:28:02 EDT
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?
Comment 4 Tim Hildred 2013-10-27 20:05:05 EDT
Reassigning to Jodi Biddle (jbiddle@redhat.com) as I am no longer working on Red Hat Enterprise Virtualization documentation.
Comment 5 Juan Pablo Lorier 2013-11-20 09:55:13 EST
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.
Comment 6 Juan Pablo Lorier 2014-01-07 08:25:50 EST
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,
Comment 7 Andrew Dahms 2015-09-02 20:37:50 EDT
Changing status back to 'New' until re-assignment.
Comment 8 Sandro Bonazzola 2015-10-26 08:49:13 EDT
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
Comment 9 Yaniv Lavi (Dary) 2015-11-12 01:30:32 EST
Is this still relevant after the mixed tagged and untaged networks?
Comment 10 Dan Kenigsberg 2015-12-06 06:24:30 EST
(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 )
Comment 11 Lucy Bopf 2016-01-27 22:42:19 EST
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.
Comment 12 Lucy Bopf 2016-03-15 00:48:37 EDT
Moving back to the default assignee for re-triaging as the schedule allows.
Comment 13 Yaniv Lavi (Dary) 2016-03-16 08:47:32 EDT
Please separate this to correcting the info in the 3.6 guide. Once that is created, please move this one to 4.0.
Comment 14 Lucy Bopf 2016-03-31 03:28:27 EDT
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.
Comment 15 Yaniv Lavi (Dary) 2016-05-09 07:02:57 EDT
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Comment 19 Dan Kenigsberg 2016-09-14 06:11:50 EDT
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?
Comment 20 Michael Burman 2016-09-14 09:23:05 EDT
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.
Comment 21 Zac Dover 2016-10-12 00:24:07 EDT
Commit Information
------------------
git@gitlab.cee.redhat.com:rhci-documentation/docs-Red_Hat_Enterprise_Virtualization.git

In branch "BZ#980360":

commit 6882771f1efa275e1cb794284e2a151ba0a60b14
Author: Zac Dover <zdover@redhat.com>
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".
Comment 22 Tahlia Richardson 2016-10-13 21:48:01 EDT
* 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.
Comment 23 Michael Burman 2016-10-25 02:01:57 EDT
(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.

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