Bug 1304509 - [RFE] consume NetworkManager-defined interfaces
[RFE] consume NetworkManager-defined interfaces
Status: CLOSED WONTFIX
Product: vdsm
Classification: oVirt
Component: General (Show other bugs)
4.17.19
x86_64 Linux
high Severity high (vote)
: ovirt-4.0.7
: ---
Assigned To: Edward Haas
Michael Burman
network
: FutureFeature
Depends On: 1346122 1160423 vdsm_config_NetworkMgr_to_be_passive 1333983 1344411 1345919 1347958 1355656 1362358 1364126 1367378 1368650 1368761 1368764 1369291 1370048 1370225 1390474 1390667 1395108 1400874 1400891 1403717
Blocks: 1330138 1379144
  Show dependency treegraph
 
Reported: 2016-02-03 16:01 EST by Nikolai Sednev
Modified: 2016-12-25 05:45 EST (History)
14 users (show)

See Also:
Fixed In Version: v4.18.10 (ovirt-4.0.2-6)
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-25 05:45:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.0.z+
rule-engine: exception+
mavital: testing_plan_complete-
ylavi: planning_ack+
danken: devel_ack+
myakove: testing_ack+


Attachments (Terms of Use)
sosreport from host (6.74 MB, application/x-xz)
2016-02-03 16:07 EST, Nikolai Sednev
no flags Details
sosreport from engine (7.74 MB, application/x-xz)
2016-02-03 16:08 EST, Nikolai Sednev
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 56059 master ABANDONED tests: let VDSM consume a bond or a VLAN created by NetworkManager 2016-11-12 20:58 EST
oVirt gerrit 56364 master MERGED ifcfg: consume bond slaves owned by NetworkManager 2016-04-28 03:37 EDT
oVirt gerrit 56365 master MERGED NetworkManager: configure to monitor ifcfg/connection files 2016-04-28 03:36 EDT
oVirt gerrit 57186 ovirt-3.6 MERGED ifcfg: consume bond slaves owned by NetworkManager 2016-05-16 06:31 EDT

  None (edit)
Description Nikolai Sednev 2016-02-03 16:01:28 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):
Engine:
rhevm-3.6.3-0.1.el6.noarch
rhevm-setup-plugin-vmconsole-proxy-helper-3.6.3-0.1.el6.noarch
jboss-as-console-2.5.11-1.Final_redhat_1.1.ep6.el6.noarch
ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch
rhevm-vmconsole-proxy-helper-3.6.3-0.1.el6.noarch
ovirt-vmconsole-1.0.0-1.el6ev.noarch
Linux version 2.6.32-573.8.1.el6.x86_64 (mockbuild@x86-033.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Fri Sep 25 19:24:22 EDT 2015

Host:
sanlock-3.2.4-2.el7_2.x86_64
mom-0.5.2-1.el7ev.noarch
libvirt-client-1.2.17-13.el7_2.3.x86_64
vdsm-4.17.19-0.el7ev.noarch
qemu-kvm-rhev-2.3.0-31.el7_2.7.x86_64
ovirt-vmconsole-host-1.0.0-1.el7ev.noarch
ovirt-vmconsole-1.0.0-1.el7ev.noarch
Linux version 3.10.0-327.10.1.el7.x86_64 (mockbuild@x86-021.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Sat Jan 23 04:54:55 EST 2016


How reproducible:
100%

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.
3.

Actual results:
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.

Expected results:
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.

Additional info:
See sosreports attached from the engine and host.
Comment 1 Nikolai Sednev 2016-02-03 16:07 EST
Created attachment 1120900 [details]
sosreport from host
Comment 2 Nikolai Sednev 2016-02-03 16:08 EST
Created attachment 1120901 [details]
sosreport from engine
Comment 3 Nikolai Sednev 2016-02-10 07:45:16 EST
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.
Comment 4 Dan Kenigsberg 2016-05-08 06:06:41 EDT
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.
Comment 5 Red Hat Bugzilla Rules Engine 2016-06-15 04:17:02 EDT
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.
Comment 6 Yaniv Kaul 2016-07-14 09:00:21 EDT
(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?
Comment 7 Dan Kenigsberg 2016-07-17 04:02:31 EDT
(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.
Comment 8 Yaniv Kaul 2016-08-04 08:07:27 EDT
Can we do it, now the dep bug has been released?
Comment 9 Dan Kenigsberg 2016-08-07 05:51:34 EDT
correct it should have been moved to ON_QA  with bug 1326798
Comment 10 Meni Yakove 2016-08-10 06:34:25 EDT
Is this bug depend on bug 1364126? if so then this bug should be moved to modify.
Comment 11 Yaniv Lavi 2016-08-10 07:59:06 EDT
(In reply to Meni Yakove from comment #10)
> Is this bug depend on bug 1364126? if so then this bug should be moved to
> modify.

It's not related this is a different issue.
Comment 12 Michael Burman 2016-08-10 08:31:11 EDT
If it's not related, so what should be tested here in order to verify this bug?
Comment 13 Yaniv Lavi 2016-08-10 10:12:00 EDT
(In reply to Michael Burman from comment #12)
> If it's not related, so what should be tested here in order to verify this
> bug?

The flow described in the description.
Comment 14 Michael Burman 2016-08-11 07:27:19 EDT
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.
Comment 15 Nikolai Sednev 2016-08-21 05:13:57 EDT
(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.
Comment 16 Dan Kenigsberg 2016-08-22 03:25:52 EDT
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.
Comment 17 Sandro Bonazzola 2016-10-05 08:35:10 EDT
Any update on this?
Comment 18 Yaniv Kaul 2016-10-25 04:31:11 EDT
(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.

Any news?
Comment 19 Ryan Barry 2016-10-25 05:36:18 EDT
We are still waiting on rhbz#1368764, as far as I know, which is currently slated for 7.3.1
Comment 20 Sandro Bonazzola 2016-10-25 07:35:56 EDT
(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.
Comment 21 Dan Kenigsberg 2016-10-25 10:14:59 EDT
Actually, we are blocked on bug 1371126 which is yet to be cloned to to 7.3.z
Comment 22 Dan Kenigsberg 2016-11-28 08:46:42 EST
Must be verified only after http://errata.devel.redhat.com/advisory/25497 is released
Comment 23 Michael Burman 2016-12-12 02:00:08 EST
Test results for  redhat-virtualization-host-4.0-20161206.0 and rhel7.3 using 
NetworkManager-1.4.0-13.el7_3
vdsm-4.18.18-1.el7ev.x86_64
cockpit-122-3

* Scenarios tested and PASS:
[1] - vlan device configured in cockpit,  add host PASS
[2] - vlan device configured via nmcli, add host PASS
[3] - bond device using nmcli, add host PASS
[4] - vlan bond device configured via nmcli, add host PASS

* Blocked:
[1] - bond device via cockpit
[2] - 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?
Comment 24 Michael Burman 2016-12-12 05:15:53 EST
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 - 4.0.6.3-0.1.el7ev and 
vdsm-4.18.18-1.el7ev.x86_64
rhvh-4.0-0.20161206.0+1
NetworkManager-1.4.0-13.el7_3.x86_64
cockpit-ws-122-3.el7.x86_64
Comment 26 Dan Kenigsberg 2016-12-25 05:45:31 EST
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).

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