Bug 906359

Summary:	Management network VLAN tagging behaves badly
Product:	[Retired] oVirt	Reporter:	Lior Vernia <lvernia>
Component:	ovirt-engine-core	Assignee:	Lior Vernia <lvernia>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Martin Pavlik <mpavlik>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.2	CC:	acathrow, bazulay, danken, gklein, iheim, jkt, lvernia, masayag, mpavlik, myakove
Target Milestone:	---	Keywords:	Triaged
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	network
Fixed In Version:	ovirt-3.4.0-beta2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-31 12:25:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1024889

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