Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065385 - RHEV-H: An error appeared in the UI: UnknownNicError("Unknown network interface: 'eth0'",)
Summary: RHEV-H: An error appeared in the UI: UnknownNicError("Unknown network interfa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
urgent
medium
Target Milestone: ---
: 3.5.0
Assignee: Fabian Deutsch
QA Contact: Virtualization Bugs
URL:
Whiteboard: node
Depends On:
Blocks: 1065425 1073046 1123329 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-02-14 14:27 UTC by Evgheni Dereveanchin
Modified: 2016-02-10 20:03 UTC (History)
13 users (show)

Fixed In Version: rhev-hypervisor6-6.6-20141218.0.iso rhev-hypervisor7-7.0-20141218.0.iso
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 20:52:54 UTC
oVirt Team: Node
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0160 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2015-02-12 01:34:52 UTC
oVirt gerrit 25351 None None None Never

Description Evgheni Dereveanchin 2014-02-14 14:27:09 UTC
Description of problem:
With specific network configurations, when selecting an interface in the "Network" tab of the RHEV-H UI, the interface crashes.

Version-Release number of selected component (if applicable):
RHEV-H v6.5 20140121.0

Steps to Reproduce:
1) install RHEV-H from rhevh-6.5-20140121.0.el6ev.iso, assign 4 Ethernet adapters.
2) boot the hypervisor, configure networking on eth0 VLAN 10
3) enable SSH from the Security menu
4) connect host to RHEV-M
5) configure networks the following way:

eth0 |
      >- bond0 - vlan10 - rhevm (non VM network)
eth2 |


eth1 |
      >- bond1 - vlan20 - VMs
eth3 |

6) confirm host activated successfully
7) go to "Network", browse to "eth0" and press enter

Actual results:
UI crashes with error:
An error appeared in the UI: UnknownNicError("Unknown network interface: 'eth0'",)
Press ENTER to logout ...
or enter 's' to drop to shell

Expected results:
a warning  "Networking configuration detected an already configured NIC" displayed, same as for other interfaces

Comment 2 Douglas Schilling Landgraf 2014-02-14 15:46:58 UTC
Hi Evgheni,

Thanks for the report and sharing the machine. Moving the bug to ovirt-node component which cares about network page.

Comment 3 Fabian Deutsch 2014-02-14 16:23:34 UTC
I gues sthe problem is here that the NIC is used in a bond, and we filter out "used" NICs. That is why it is unknown.

We can drop that filter or block the network page when registered as a short term solution. But we need to see how we handle this network topic on a more global scope.

Comment 4 Evgheni Dereveanchin 2014-02-15 14:08:42 UTC
@Fabian I want to note that in my example all four physical interfaces on the system are used in bonds, but the UI crashes only when trying to edit "eth0".

Comment 5 Guohua Ouyang 2014-02-18 05:23:13 UTC
I try to reproduce the issue, but have two confusions:
1. the nic eth0 used by bond0 is filtering out on Network page, how to find it and edit it?

2. how to create multiple bonds on TUI, I can only create one and the "create bond" button becomes "remove bond0...".

Comment 6 Evgheni Dereveanchin 2014-02-18 08:52:19 UTC
@Ouyang all required steps are described in the case description. Bonds are created from the manager after the host is joined to it.

Comment 8 Guohua Ouyang 2014-02-18 10:19:34 UTC
(In reply to Evgheni Dereveanchin from comment #6)
> @Ouyang all required steps are described in the case description. Bonds are
> created from the manager after the host is joined to it.

could reproduce this issue by adding bonds from rhevm.

Comment 9 Fabian Deutsch 2014-02-19 15:15:34 UTC
My take is that we properly (rename) and implement the MANAGED_LOCKED_PAGES key and then just disabled the network page ... That would also match the 6.4 behavior.

Currently the underlying networking code doesn't support all the layouts which Engine can come up with. Adjustign the network code is a long term plan, but for now we should probably disable it to prevent this bug and others which are similar.

Comment 11 Fabian Deutsch 2014-03-04 12:08:31 UTC
A new take.

For now we disable the items on the network page when there is any MANAGED_IFNAMES is set.
This is also in line with the legacy TUI - where we also disabled the network page after the registration.

Fabio/Arthur, as this is basically limiting the current state in 6.5 I'd just like to get your input (and ack) on this.

This prevents us from implementing MANAGED_LOCKED_PAGES - and this is good because the semantics are not clear.

Comment 12 Fabio Massimo Di Nitto 2014-03-04 12:15:11 UTC
(In reply to Fabian Deutsch from comment #11)
> A new take.
> 
> For now we disable the items on the network page when there is any
> MANAGED_IFNAMES is set.
> This is also in line with the legacy TUI - where we also disabled the
> network page after the registration.
> 
> Fabio/Arthur, as this is basically limiting the current state in 6.5 I'd
> just like to get your input (and ack) on this.
> 
> This prevents us from implementing MANAGED_LOCKED_PAGES - and this is good
> because the semantics are not clear.

I agree that one the manager takes over the management, the TUI should stop allowing manual edit.

The manager can have X too many combinations that the TUI would have to replicate and manage.

This behavior should be consistent for anything (network/storage/etc) else on the system

Comment 13 Fabian Deutsch 2014-03-04 13:44:06 UTC
(In reply to Fabio Massimo Di Nitto from comment #12)
> I agree that one the manager takes over the management, the TUI should stop
> allowing manual edit.
>
> The manager can have X too many combinations that the TUI would have to
> replicate and manage.

Ack
 
> This behavior should be consistent for anything (network/storage/etc) else
> on the system

I agree that we should block a page, when the TUI can not do what the management part can do.

Comment 18 wanghui 2015-01-21 06:41:39 UTC
Test version:
rhev-hypervisor6-6.6-20150114.0
ovirt-node-3.2.1-4.el6.noarch

Test step:
1. Install rhev-hypervisor6-6.6-20150114.0, assign 4 Ethernet adapters.
2. Boot the hypervisor, configure networking on eth0 VLAN 10
3. Register host to RHEV-M
4. Confirm host activated successfully
5. Go to "Network", browse to "eth0" and press enter

Test result:
1. After step3, all the NIC in rhevh TUI is managed and can not be checked or edited.

So this issue is fixed as comment#13. Change the status from ON_QA to Verified.

Comment 20 errata-xmlrpc 2015-02-11 20:52:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0160.html


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