Description of problem: To my understanding NM can be running alongside of vdsm, it should just not mess with devices by itself. This can be achieved (IIUIC) by setting the no-auto-default=* configuration directive. If this works, then the benefit would be that NM could run alongside vdsm and projects integrating with NM (like Cockpit) would continue to work.
Note: If this works, then we do not need to disbale NM during host-deploy.
Adjusting priority to high, because having NM enabled is currently blocking the normal he-flow. he-setuo expects NM to be disabled, and this is conflicting with the idea of using Cockpit for initial network configuration.
Can you try if pulling NetworkManager-config-server does the trick?
It does not. hosted-engine setup checks for the explicitly. Simone is testing right now.
First attempt to deploy hosted-engine with active NetworkManager on the simplest case (just one interface, static addressing) was OK. Danken, should we completely remove the NetworkManager check on hosted-engine side cause we are sure that VDSM is fully compatible with it?
One thing to note here is that it seems thast vdsm still requires the legacy network.service. Dan, would it be possible to let NM handle the ifcfg files?
(In reply to Simone Tiraboschi from comment #5) > Danken, should we completely remove the NetworkManager check on > hosted-engine side cause we are sure that VDSM is fully compatible with it? I'm not sure what does hosted-engine-setup do with regards to NM, but if Vdsm works fine in parallel to NM, we should stop disabling NM in ovirt-host-deploy and elsewhere. (In reply to Fabian Deutsch from comment #6) > One thing to note here is that it seems thast vdsm still requires the legacy > network.service. > > Dan, would it be possible to let NM handle the ifcfg files? I think that what you're suggesting is writing an NM configurator to Vdsm. This is possible, but not on our roadmap for 4.0.
(In reply to Dan Kenigsberg from comment #7) > (In reply to Fabian Deutsch from comment #6) > > One thing to note here is that it seems thast vdsm still requires the legacy > > network.service. > > > > Dan, would it be possible to let NM handle the ifcfg files? > > I think that what you're suggesting is writing an NM configurator to Vdsm. > This is possible, but not on our roadmap for 4.0. No, I'm not suggesting to write an NM configurator. I'm suggesting to let NM handle the ifcfg files. Currentl the network.service (legacy) is enforced by vdsm to handle the ifcfg files, but NM can do this as well (with the - by default enabled - ifcfg-rh plugin)
(In reply to Fabian Deutsch from comment #8) > I'm suggesting to let NM handle the ifcfg files. > Currentl the network.service (legacy) is enforced by vdsm to handle the > ifcfg files, but NM can do this as well (with the - by default enabled - > ifcfg-rh plugin) We used to have nasty races with NM_CONTROLLED=yes; we should research if they still exist.
I'm granting devel_ack for allowing NM to run side-by-side to Vdsm. We are NOT going to manager networking via NM in 4.0.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
*** Bug 1330128 has been marked as a duplicate of this bug. ***
All referenced patches are merged, is something missing to keep this in POST?
Meni, could you approve testing that Vdsm is working fine when NM is running?
Tier1 PASS with NM up and with the patch
Simone, I'm actually missing a patch in master which is changing the default to ohostedcons.NetworkEnv.REFUSE_DEPLOYING_WITH_NM to False. Do you plan to add this for master and ovirt-4.0, now with the backing in comment 16?
This bug has failed QA due to bug 1344411: NM is not really passive.
Network tier2 pass with NM service enabled but this bug failed QE on bug 1344411 which in NEW status. Should we verify this bug or not?
NM is not passive yet. We still have issue with DNS. For now don't verify.
So it shouldn't be ON_QA, please set it to depends on or move to modified.
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.
The best we can have in 4.0.z is consuming NM-controlled interfaces (bug 1304509); I am not sure we can keep NM running.
Edy is now working on consuming NM-created interfaces while NM is running, slated for 4.0.7.
*** Bug 1406820 has been marked as a duplicate of this bug. ***
Nothing to be done on ovirt side for 4.1.
rhevm-4.1.1.3-0.1.el7.noarch