Bug 906359 - Management network VLAN tagging behaves badly
Summary: Management network VLAN tagging behaves badly
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.4.0
Assignee: Lior Vernia
QA Contact: Martin Pavlik
URL:
Whiteboard: network
Depends On:
Blocks: 1024889
TreeView+ depends on / blocked
 
Reported: 2013-01-31 13:54 UTC by Lior Vernia
Modified: 2015-05-05 01:43 UTC (History)
10 users (show)

Fixed In Version: ovirt-3.4.0-beta2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-31 12:25:45 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 23893 0 None None None Never

Description Lior Vernia 2013-01-31 13:54:48 UTC
Description of problem:

It is possible to enable VLAN tagging for the management network in the default cluster, before adding any hosts. Then when a host is added, its network isn't synchronised

Moreover, the default selection of the network's boot protocol in the "edit network" dialog is DHCP, and if the user doesn't change it and confirms the "setup host networks" dialog, the operation will always fail (and it will only fail a couple of minutes later, during which time the user isn't able to do anything with the host).


Version-Release number of selected component (if applicable):


How reproducible:

Always.


Steps to Reproduce:
1. Straight after installing ovirt-engine, edit management network to enable VLAN tagging.
2. Add host and storage to the system.
3. Head to setup host networks, see that the management network isn't synchronised.
4. Edit it, mark it to be synchronised without changing anything else.
5. Confirm both dialogs.
6. Operation times out.
  
Actual results:

First host management network isn't synchronised, then it can never be synchronised as long as DHCP is selected as its boot protocol.


Expected results:

Preferably that when VLAN tagging is enabled on the management network in ovirt-engine, then it is also defined that way on the host and there are no synchronisation problems.


Additional info:

Comment 1 Itamar Heim 2013-12-01 10:19:07 UTC
still relevant?

Comment 2 Itamar Heim 2014-01-12 08:42:31 UTC
setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.

Comment 3 Dan Kenigsberg 2014-01-16 10:26:20 UTC
Lior, would the following make sense to you: if vlan id of the management network is about to be added/changed, "check connectivity" is bound to fail, and we should not allow enabling it. However, it we must add a big warning that following this change, the IP address of the management network is going to change (most probably) and that unless the user takes further actions (such as updating his dns) the host would become unreachable.

Comment 4 Lior Vernia 2014-01-16 11:05:30 UTC
Itamar and Dan, I'm not sure any of this is still relevant.

When deploying a new host, isn't the VLAN tagging of the management network properly configured on the host to begin with these days?

When editing the management network and it's already provisioned on a host, then changing the VLAN tag should propagate to the host these days behind the scenes. In which case, I'm not even sure what would happen.

Comment 5 Moti Asayag 2014-01-16 12:16:10 UTC
(In reply to Lior Vernia from comment #4)
> Itamar and Dan, I'm not sure any of this is still relevant.
> 
> When deploying a new host, isn't the VLAN tagging of the management network
> properly configured on the host to begin with these days?
> 
> When editing the management network and it's already provisioned on a host,
> then changing the VLAN tag should propagate to the host these days behind
> the scenes. In which case, I'm not even sure what would happen.

In this case, the user will face lose of connectivity to his hosts.
If he wishes to change the vlan-id of the logical network and to apply it to the hosts, he should follow this steps:

0. Put host in maintenance (else host moves to non-responsive on 2)
1. Perform setup networks to the host, with 'check connectivity' disabled, and 'force' enabled.
2. Lease the new ip for the management network interface.
3. Configure that ip to match the host name originally used to add the host into the system (by which the engine communicate with the host).
4. activate the host.

Therefore I suggest either blocking updating the vlan-id of the management network (which might result in entire DC's hosts non-responsive until the net config rollback) or add a warning in that dialog for this case.

Comment 6 Lior Vernia 2014-01-28 13:11:21 UTC
I think blocking the operation isn't a good idea, because it's convenient to be able to change the VLAN ID of the management network if your switches are properly configured.

On the other hand, I don't think adding a warning is ever a solution to any bug. That being said, this current discussion has very little to do with my original intent when opening this bug, so I don't mind adding a warning in the dialog and consider things settled.

Comment 7 Martin Pavlik 2014-02-17 11:36:56 UTC
Verified on oVirt Engine Version: 3.4.0-0.7.beta2.el6 

when trying to edit VLAN tag on management network following warning is displayed:

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?

Comment 8 Sandro Bonazzola 2014-03-31 12:25:45 UTC
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released


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