Description of problem: oVirt currently manually hacks files in /etc/sysconfig/network-scripts/ifcfg-* to configure the ovirtmgmtbridge interface. This needs to be improved as manually editing those files is unsafe. First, NetworkManager has a "keyfile" mode that will store connection information in INI-style files in /etc/NetworkManager/system-connections/. Second, NetworkManager includes a proper API, via DBus, to configure and check connections. `hosted-engine --deploy` will fail with a poor error message if the selected network interface does not have a /etc/sysconfig/network-scripts/ifcfg-* file with the message: Failed to execute stage 'Misc configuration': 'BOOTPROTO' There's no indication that the failure was caused by the file missing. Version-Release number of selected component (if applicable): 3.4 How reproducible: Always Steps to Reproduce: 1. Enable NetworkManager keyfile in /etc/NetworkManager/NetworkManager.conf 2. Configure connection, so it saves to /etc/NetworkManager/system-connections/ 3. If necessary, remove old config from /etc/sysconfig/network-scripts/ifcfg-* 4. Run `hosted-engine --deploy`. Actual results: Installation fails because oVirt cannot modify the non-existant ifcfg config file. Expected results: oVirt uses NetworkManager's DBus API whenever possible to configure and detect settings of network interfaces. It can fallback to manually changing ifcfg files if NM is not available.
Antoni, do VDSM still rely on ifcfg filesJustin, hosted-engine --deploy rely on vdsm for configuring network, doesn't use ifcfg files directly.
Justin, can you attach hosted-engine and vdsm logs?
Yes, bug 987813 is not yet solved, and we still depend on pre-existing ifcfg files.
I've been working today on not depending on pre-existing ifcfg files. With the new ovirt-hosted-engine-setup patch I posted and a couple of vdsm patches it should work (NM would still interfere if the right policies are not set for it).
Antoni, Is that going to work with NM Keyfiles? If the Keyfile plugin is activated, ovirt can't just drop newly created ifcfg scripts in /etc/sysconfig/network-scripts/. NM will never load them. The people commenting on bug 987813 don't seem to understand this. It seems like they were using the ifcfg-rh plugin, but hadn't set up a connection for that interface so the file was missing (or was named something like ifcfg-Wired_Profile_1 that NM likes to do). oVirt shouldn't be touching NM files at all. It should be using the DBus API to set everything up, which allows NM to handle writing the files in the manner and location it wants. The reason that this is a RFE and not a bug report is because I want to rip out how ovirt does file-based network configuration and replace it with a programmatic method via DBus. The file-based configuration should only run on systems without DBus or NM.
Justin, there are two different issues: one (tracked by bug 987813) is to let ovirt install (and later run) on a host in which NM is running and handling unrelated interfaces. As you say, this requires NM to use the ifcfg-rh plugin, and to be configured for a server (so it does not try to own any device that pops to life). A second issue is what you request: to have an NM configurator for Vdsm. Vdsm's current architecture supports that, but at the moment it is not on our roadmap. We would, however, love to see a contribution like that of http://gerrit.ovirt.org/27745/
Thanks Dan. Yeah, I opened this RFE with the expectation that I'll submit the enhancement patches. I'll update this report as I make progress.
Thanks Justin. Please, add me as a reviewer for the NM configurator patches and make sure to contact me in IRC should you have any doubt or comment: irc.freenode.net #vdsm (apuimedo)
(In reply to Antoni Segura Puimedon from comment #8) > Thanks Justin. Please, add me as a reviewer for the NM configurator patches > and make sure to contact me in IRC should you have any doubt or comment: > > irc.freenode.net #vdsm (apuimedo) Reassigning to Antoni as per above comment
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
We should really revisit this.
Fabian, I was going to close this as EOL, please set version to the version you want this RFE in.
It's actually an RFE which doesn't have a target release set.
Cockpit is using NM's dbus API for exposing network administration capabilities. For better over all integration with cockpit, this RFE should get a higher priority.
I see that NetworkManager get's completely disabled on hosts: https://gerrit.ovirt.org/#/c/55184/ This will make the Cockpit UI useless for configuring or monitoring networking post host-addition.
We plan to add a configurable use_nmstate, false by default, to use NM via nmstate.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
This is in for quite some time, 4.4 is using nmstate for everything (and sure, there are followup bugs to track)
Verified on and with: nmstate-0.2.6-6.el8.noarch vdsm-4.40.11-1.el8ev.x86_64 NetworkManager-1.22.8-4.el8.x86_64 rhvm-4.4.0-0.31.master.el8ev.noarch
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
LGTM, thanks.