Red Hat Bugzilla – Bug 1304509
[RFE] consume NetworkManager-defined interfaces
Last modified: 2016-12-25 05:45:31 EST
Description of problem:
Failed to add host with statically configured IP address to the engine and NetworkManager is not running after failed addition of the host.
Version-Release number of selected component (if applicable):
Linux version 2.6.32-573.8.1.el6.x86_64 (firstname.lastname@example.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Fri Sep 25 19:24:22 EDT 2015
Linux version 3.10.0-327.10.1.el7.x86_64 (email@example.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Sat Jan 23 04:54:55 EST 2016
Steps to Reproduce:
1.Assemble isolated NAT environment with host and engine within and static IP addresses assigned to both engine and host.
2.Add host to the engine via WEBUI of the engine.
Host addition failed, virtual bridge created, but does not retain statically assigned IP from the physical interface and NetworkManager is not running after failed addition of the host.
Host should be added successfully, NetworkManager should be running normally, virtual bridge must receive the same IP, which was assigned to the host's physical NIC. Virtual bridge should not automatically choose DHCP adress assignment, but retain configuration from previously worked physical NIC.
See sosreports attached from the engine and host.
Created attachment 1120900 [details]
sosreport from host
Created attachment 1120901 [details]
sosreport from engine
Host addition worked for me if I disabled the NetworkManager, then configuring statically the IP addressing within the configuration files, then added host to the engine.
According to Fabian, this is working well. So let's include it in 4.0, and attempt to backport it to 3.6.7's NGN.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
(In reply to Dan Kenigsberg from comment #4)
> According to Fabian, this is working well. So let's include it in 4.0, and
> attempt to backport it to 3.6.7's NGN.
Time to move it to 4.1?
(In reply to Yaniv Kaul from comment #6)
> Time to move it to 4.1?
No - we block on rhel-7.2.z bug 1346947, but ngn needs it for 4.0.
Can we do it, now the dep bug has been released?
correct it should have been moved to ON_QA with bug 1326798
Is this bug depend on bug 1364126? if so then this bug should be moved to modify.
(In reply to Meni Yakove from comment #10)
> Is this bug depend on bug 1364126? if so then this bug should be moved to
It's not related this is a different issue.
If it's not related, so what should be tested here in order to verify this bug?
(In reply to Michael Burman from comment #12)
> If it's not related, so what should be tested here in order to verify this
The flow described in the description.
This bug shouldn't be ON_QA and i can't verify it.
Basic flow of setting static ip and DNS name server using NetworkManager is not passing, because after adding the host to rhev-m(with success) the name server is trashed from resolv.conf by NM it self.
It means this bug for sure related to BZ 1364126 and depends on him.
(In reply to Michael Burman from comment #14)
> This bug shouldn't be ON_QA and i can't verify it.
> Basic flow of setting static ip and DNS name server using NetworkManager is
> not passing, because after adding the host to rhev-m(with success) the name
> server is trashed from resolv.conf by NM it self.
> It means this bug for sure related to BZ 1364126 and depends on him.
Writing this here just in case that it might be useful.
I've seen that for NGN, the NM was disabled right after hosted-engine deployment created ovirtmgmt bridge. I've configured static IP, couple of DNS servers and default gateway on NGN using nmtui prior to hosted-engine deployment procedure.
Given the recent reports regarding the using UUID in ifcfg MASTER= line, the failure to define a vlan over bond, as well as ifcfg names, we must declare this RFE as failed.
Any update on this?
(In reply to Dan Kenigsberg from comment #16)
> Given the recent reports regarding the using UUID in ifcfg MASTER= line, the
> failure to define a vlan over bond, as well as ifcfg names, we must declare
> this RFE as failed.
We are still waiting on rhbz#1368764, as far as I know, which is currently slated for 7.3.1
(In reply to Ryan Barry from comment #19)
> We are still waiting on rhbz#1368764, as far as I know, which is currently
> slated for 7.3.1
So this won't make 4.0.5.
Actually, we are blocked on bug 1371126 which is yet to be cloned to to 7.3.z
Must be verified only after http://errata.devel.redhat.com/advisory/25497 is released
Test results for redhat-virtualization-host-4.0-20161206.0 and rhel7.3 using
* Scenarios tested and PASS:
 - vlan device configured in cockpit, add host PASS
 - vlan device configured via nmcli, add host PASS
 - bond device using nmcli, add host PASS
 - vlan bond device configured via nmcli, add host PASS
 - bond device via cockpit
 - vlan bond device via cokpit
blocked by some bugs on cockpit for the way it creates bonds -
- Bug 1395108 - Improve the way cockpit creates bonds when the primary slave or one of the slaves has the host connection - POST
- Bug 1400891 - Setup bond via cockpit failed - NEW
* NOTE - NetworkManager is alive after add ngn host to rhv-m and it's not our desired behavior. It is running when the cockpit session is active and inactive during the add host.
Should i move this RFE to VERIFIED?
As agreed with Dan and Yaniv this bug can be considered as verified.
See comment 23 ^^ for the scenarios that passed with success.
NOTE- the known issues are setup bond via cockpit failed.
- All bond scenarios via cockpit blocked.
- The work around is to create bonds via nmcli
- Currently NetworkManager is alive after ngn host to rhv-m
Verified on - 184.108.40.206-0.1.el7ev and
Given the (vdsm-side) complexity of acquiring bonding slaves with multiple connections, we are going to focus our effort on consuming interfaces from a living NM instance (bug 1326798).