Bug 1254611 - moving a bridge from a manually-editted eth0 to eth1 keeps eth0 and creates a loop
moving a bridge from a manually-editted eth0 to eth1 keeps eth0 and creates a...
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
x86_64 Linux
medium Severity medium
: ovirt-4.0.0-alpha
: 4.0.0
Assigned To: Ido Barkan
Meni Yakove
Depends On:
  Show dependency treegraph
Reported: 2015-08-18 09:51 EDT by Pavel Zhukov
Modified: 2016-02-10 14:16 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-25 05:02:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Pavel Zhukov 2015-08-18 09:51:03 EDT
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 09:52:13 EDT
Created attachment 1064325 [details]
Comment 4 Dan Kenigsberg 2015-08-26 07:41:02 EDT
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 05:02:47 EDT
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.