Bug 1097668 - [rhevh tui] Network->Available nics lists pseudo-ifaces - bond - but not rhevm bridge
Summary: [rhevh tui] Network->Available nics lists pseudo-ifaces - bond - but not rhev...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 3.6.0
Assignee: Ryan Barry
QA Contact: Virtualization Bugs
URL:
Whiteboard: node
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-14 09:36 UTC by Jiri Belka
Modified: 2016-02-10 20:11 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-17 15:36:34 UTC
oVirt Team: Node
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screenshot (75.74 KB, image/png)
2014-05-14 09:36 UTC, Jiri Belka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 37203 0 master MERGED Don't hide bridges in the network page Never

Description Jiri Belka 2014-05-14 09:36:36 UTC
Created attachment 895421 [details]
screenshot

Description of problem:
TUI is strange.

Status tab:
  Networking: Connected rhevm
  IPv4: 10.34.63.222

Network tab:
  Available NICs lists not only real physical ifaces but also pseudo-ifaces like bonds. But no bridges.

But why is there no bridge, especially when 'rhevm' is currectly the iface holding known IPv4 address as displayed in 'Status' tab.

This is odd.

I think people would like to see under 'Network' tab how networking really works on their host.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Hypervisor release 6.5 (20140508.0.el6ev)

How reproducible:
100%

Steps to Reproduce:
1. have your host in RHEV env
2. check Status tab
3. check Network tab

Actual results:
Network tab does not show current networking configuration, in fact it hides bridges.

Expected results:
IPv4 used by rhevm bridge should be visible in Network tab and we should see it is binded to a rhevm bridge.

Additional info:
'Managed' is irrelevant in this context. Network tab should see network configuration reality on the host.

Comment 1 Fabian Deutsch 2014-05-14 10:49:10 UTC
This is a broader topic.

In general we need to identify how we handle networking on Node.

Historically this was very limited. And the current design quickly approaches it's limits.

Instead of supporting a fully fledged solution to setup arbitary network configurations, I am more in favor of being able to configure a number of layouts.

If managed then we should probably just list the physical nics and mark them as managed. That might make the most sense.

Comment 2 Ryan Barry 2014-10-01 18:04:00 UTC
In general, I would suspect that we don't show the ovirtmgmt or rhevm bridges because reconfiguring them would disconnect the node from the engine.

It's possible to show the bridges and prevent reconfiguration, but the networking page is intended to give an overview of what's necessary to connect to the engine, which then manages everything. We don't even present the option to create bridges, which is why they are not visible.

Additionally, other hypervisors do not allow you to see every network (guest, neutron, bridged, or otherwise) defined inside the management engine, which quickly gets unwieldy and cannot be effectively managed from the hypervisor side in any case. Not that I'm necessarily saying that because other vendors don't do it we shouldn't do it, but there is some rationale behind the decision.

Given this, what outcome would you like ot see in the TUI?

Comment 3 Jiri Belka 2014-10-02 07:57:41 UTC
I wanted to see reality, no lies, no obfuscation, no hidden details about networking.

Expected results:
IPv4 used by rhevm bridge should be visible in Network tab and we should see it is binded to a rhevm bridge.

Comment 4 Fabian Deutsch 2014-11-06 14:54:03 UTC
Re-targeting for 3.6

Comment 5 Fabian Deutsch 2015-09-17 15:36:34 UTC
This functionality will move to cockpit, and thus this bug does not apply there anymore.


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