Bug 1254611 - moving a bridge from a manually-editted eth0 to eth1 keeps eth0 and creates a loop
Summary: moving a bridge from a manually-editted eth0 to eth1 keeps eth0 and creates a...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.5.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ovirt-4.0.0-alpha
: 4.0.0
Assignee: Ido Barkan
QA Contact: Meni Yakove
URL:
Whiteboard: network
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-18 13:51 UTC by Pavel Zhukov
Modified: 2019-08-15 05:12 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-25 09:02:47 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
supervdsm.log (33.00 KB, text/plain)
2015-08-18 13:52 UTC, Pavel Zhukov
no flags Details

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.


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