Bug 1254611

Summary: moving a bridge from a manually-editted eth0 to eth1 keeps eth0 and creates a loop
Product: Red Hat Enterprise Virtualization Manager Reporter: Pavel Zhukov <pzhukov>
Component: vdsmAssignee: Ido Barkan <ibarkan>
Status: CLOSED NOTABUG QA Contact: Meni Yakove <myakove>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.5.3CC: amureini, bazulay, danken, ecohen, gklein, lpeer, lsurette, mburman, pzhukov, rmcswain, ycui, yeylon, ylavi
Target Milestone: ovirt-4.0.0-alpha   
Target Release: 4.0.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-25 09:02:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
supervdsm.log none

Description Pavel Zhukov 2015-08-18 13:51:03 UTC
Description of problem:
vdsm doesn't check if rhevm bridge already exist and creates bridge loop which leads network infrastructure to be flooded.

Version-Release number of selected component (if applicable):
vdsm-4.16.20-1.el6ev.x86_64 in RHELH based env

How reproducible:
Unknown. User reported

Steps to Reproduce:
*Haven't verified*
1. Install rhel, configure bridge named rhevm with out underlying interface (eth0) 
2. Attach host to manager. Configure manager to assign rhevm to eth0. Don't touch eth0

Actual results:
rhevm bridge created and both eth0 and eth1 are in the bridge

Expected results:
eth0 removed from the bridge

Additional info:

Comment 1 Pavel Zhukov 2015-08-18 13:52:13 UTC
Created attachment 1064325 [details]
supervdsm.log

Comment 4 Dan Kenigsberg 2015-08-26 11:41:02 UTC
Why did the customer create rhevm bridge to begin with, and why did they move it to another nic?

I would not want Vdsm to be over-protective and forcibly remove interfaces the where configured by the local admin.

I don't believe that the severity of the issue is urgent, in any case: it can be easily avoided by pre-creating rhevm on top of eth1.

Comment 8 Dan Kenigsberg 2015-10-25 09:02:47 UTC
I don't see how I can keep this bug open. In my opinion, whomever edited eth0 manually, should take it down, and edit eth1 manually on the production network.

Please reopen if you understand how RHEV can assist the customer in this use case.