Created attachment 1184909 [details] all log info Description of problem: Failed to register RHVH to engine with static ip. It report: Host cshao_intel does not comply with the cluster cshao_intel networks, the following networks are missing on host: 'ovirtmgmt' Version-Release number of selected component (if applicable): redhat-virtualization-host-4.0-20160727.1 imgbased-0.7.3-0.1.el7ev.noarch vdsm-4.18.9-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Anaconda interactive install RHVH. 2. Configure network with static ip. 3. Add RHVH to engine 4.0 Actual results: Failed to register RHVH to engine with static ip. Expected results: Register RHVH to engine can successful sith static ip. Additional info:
Created attachment 1184910 [details] failed-register-static-ip
Ondřej, could this be similar to bug 1351095?
Could you retry, but disable and mask NetworkManager before adding the host to Engine? We would like to see if this is the DNS-removal by NM.
(In reply to Dan Kenigsberg from comment #3) > Could you retry, but disable and mask NetworkManager before adding the host > to Engine? We would like to see if this is the DNS-removal by NM. RHVH can up on engine with static ip after disable and mask NetworkManager. # systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: inactive (dead) since Thu 2016-07-28 21:20:25 CST; 4min 19s ago Main PID: 1188 (code=exited, status=0/SUCCESS)
Created attachment 1185105 [details] static-up
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.
Would you be kind to see if this bug, too, can be avoided by turning off NM cfg monitoring? Please comment out the line in /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf and restart NM before adding the host.
(In reply to Dan Kenigsberg from comment #8) > Would you be kind to see if this bug, too, can be avoided by turning off NM > cfg monitoring? > > Please comment out the line in > /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf and restart > NM before adding the host. Yes, RHVH still can up (with static ip) after turning off NM cfg monitoring. # cat /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf [main] monitor-connection-files=false # systemctl restart NetworkManager # systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-08-01 21:28:08 CST; 8s ago Main PID: 19039 (NetworkManager) CGroup: /system.slice/NetworkManager.service └─19039 /usr/sbin/NetworkManager --no-daemon
(In reply to Dan Kenigsberg from comment #8) > Would you be kind to see if this bug, too, can be avoided by turning off NM > cfg monitoring? > > Please comment out the line in > /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf and restart > NM before adding the host. Also confirming that commenting works.
(In reply to Dan Kenigsberg from comment #8) > Would you be kind to see if this bug, too, can be avoided by turning off NM > cfg monitoring? > > Please comment out the line in > /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf and restart > NM before adding the host. Hi Danken, I notice that there is no /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf file at all in the latest RHVH(redhat-virtualization-host-4.0-20160803.3). # cat /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf cat: /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf: No such file or directory # ll /etc/NetworkManager/conf.d/ total 8 -rw-r--r--. 1 root root 752 Jun 7 23:05 00-server.conf -rw-r--r--. 1 root root 399 Jun 7 23:05 10-ibft-plugin.conf Will it effect to this workaround?
the removal of the file causes NM to fall back to its default of monitor-connection-files=false.
(In reply to Dan Kenigsberg from comment #12) > the removal of the file causes NM to fall back to its default of > monitor-connection-files=false. Got it, thanks:)
Hi Dan, I don't see any external trackers to this bug. You moved it to ON_QA, with what version it should be tested? Should we edit any files before adding the host, should we disable NM? - Please note that when adding ngn server(rhvh-4.0-0.20160803.0+1) over a static ip, the name server is removed from /etc/resolv.conf..
Hi Michael, I believe https://gerrit.ovirt.org/#/c/61651/ also concerns this bug. It should remove /etc/NetworkManager/conf.d/90-vdsm-monitor-connection-files.conf and pull fixed initscripts with for you, so you don't need to edit any host configuration. I think you can should deploy with NM enabled, as it the point of the patch. I also believe any build from the ovirt-4.0 which contains the above patch can be used to test the original scenario (try to deploy a host with a statically configured network, should succeed). You can also apply https://gerrit.ovirt.org/#/c/61931/ https://gerrit.ovirt.org/#/c/61932/ and https://gerrit.ovirt.org/#/c/61184 to have the nameserver preserved.
I'm afraid that https://bugzilla.redhat.com/show_bug.cgi?id=1160423#c36 has shown that https://gerrit.ovirt.org/#/c/61651/ is not enough: NM still removes the DNS setting from resolv.conf. This is why we need to disable NM on NGN as well.
I did some testing according relates bug 1364126, test result as following: Test steps: 1. Anaconda interactive install RHVH. 2. Configure network with static ip. 3. Reboot and login RHVH, setting VDSM/disableNetworkManager=bool:True in /etc/ovirt-host-deploy.conf.d/90-ngn-keep-networkmanager.conf 4. Reboot RHVH 5. Add RHVH to engine 4.0 Test result: Register RHVH to engine can successful sith static ip.
moving to VERIFIED based on comment 17.
Don't understand how this is verified, see your comment 16^^. Currently adding rhev-h ngn over static ip removing the name server from resolv.conf.
in comment 17 we were told that disabling NM solves the original problem. But you are perfectly right - we must verify that this works properly out of the box, without manual editing of 90-ngn-keep-networkmanager.conf.
bug 1351095 already tracks the DNS removal issue. *** This bug has been marked as a duplicate of bug 1351095 ***