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
Hi Evgheni, Thanks for the report and sharing the machine. Moving the bug to ovirt-node component which cares about network page.
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.
@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".
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...".
@Ouyang all required steps are described in the case description. Bonds are created from the manager after the host is joined to it.
(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.
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.
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.
(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
(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.
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.
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