Network vs NetworkManager -- Best Practices?

[tycoonbob]

Hi all.

I'm somewhat new to the Linux world, and have been working a lot with RHEL 6.x and Centos 6.x. In EL6 I always used the Network service, and avoided NetworkManager but I've never really understand why they both exist. It seems a lot of people would rather disable NM and just use Network, but I'm wondering if that is the wrong thing to do. With EL7, I'm looking to spend a lot more time properly learning to use Linux the right way, so I am redocumenting my normal build and want to do things the right way. 99% of my CentOS 7 build will be minimal installs (no desktop) virtual machines with a single NIC, running under Hyper-V on Server 2012 R2 (Generation 2 VM).

So I guess here are my questions:
1) What is the difference/purpose of Network and NetworkManager?
2) Would the proper (i.e., best practice) thing be to keep Network disabled and configure NetworkManager via nmcli for static IPs?
3) Are network scripts used with NetworkManager too?

I kinda get the feeling that NetworkManager isn't used if you have a simple networking setup (single NIC, static IP, etc). I'm just looking for some clarification.

Thanks!

[gerald_clark]

NetworkManager still does not properly support bridging, so if you are going to run virtual machines, turn it off.
The only time I have found NetworkManager useful was when I was using wireless.

[tycoonbob]

I'll only be running CentOS 7 as a guest VM, and not as a host so I won't be needing any network bridges.

I just started reading the RHEL network guide, and according to this:
https://access.redhat.com/documentation ... ripts.html

It seems like NetworkManager is the primary networking service, but you can still use network scripts. However, it also seems like NetworkManager will call the Network service, if using these scripts, and utilizes the Network service as a fallback.
[...]
In previous Red Hat Enterprise Linux releases, the default way to configure networking was using network scripts. The term network scripts is commonly used for the script /etc/init.d/network and any other installed scripts it calls. The user supplied files are typically viewed as configuration, but can also be interpreted as an amendment to the scripts.
Although NetworkManager provides the default networking service, Red Hat developers have worked hard to ensure that scripts and NetworkManager cooperate with each other. Administrators who are used to the scripts can certainly continue to use them. We expect both systems to be able to run in parallel and work well together. It is expected that most user shell scripts from previous releases will still work. Red Hat recommends that you test them first.
[...]

I have always configured network scripts, but I don't have any kickstart files or any sort of automation that relies on these network scripts, so I am using this as an opportunity to re-design how I configured networking on a Linux build (with EL7).

Also, the network guide provides this for network bridges:
https://access.redhat.com/documentation ... rface.html

Which is clearly using the Network service (and network scripts) to configure bridges.



Based on these findings it would seem that the ideal thing to do would be to use NetworkManager as my primary network service, and let NM use the Network service where NM falls short (i.e., Bridging)...but it's still all controlled with NetworkManager. I'm just wanting to use best practices as it seems NM is going to replace Network at somepoint in the future; or am I completely wrong about this?

[gerald_clark]

Well, virt-manager automatically configured the bridges, but they would not start on boot with NetworkManager enabled.

[vonskippy]

or am I completely wrong about this?

Yes - you're wrong.

Avoid NM like the plague.

It's another effort from the developers to Fisher-Price the UI for the lowest common denominator (in otherwords, the devs think you're too dumb to manage networking via a config file).

Browse thru the forums, NM is the cause of almost all of the network problems described in this forum. Turning NM OFF is the solution to most of those problems. NM is a unneeded tool that performs worse then wobbly training wheels.

[bertan]

The default (NetworkManager) works for me. CentOS 7 host (KVM/QEMU), Windows 2012 R2 guest, NIC configured as network bridge. The Windows guest gets a real IP address, accessible from the outside world. I could even RDP to it.

[jlehtone]

It's another effort from the developers to Fisher-Price the UI for the lowest common denominator (in otherwords, the devs think you're too dumb to manage networking via a config file).

There is a Fisher-Price group of computers, where NM supposedly is ok: laptops and other single-NIC systems that rely on DHCP (and might not be continuously connected). They are either plug-n-play, or then no amount of configuration by any means will bring them online. VM guest can fall into that heap.

Using both NM and Network simultaneously is worse than having just NM. The plague must grow much stronger, before it can break into my systems.

[nigerag]

I would not call the NetworkManager the plague. On the Server installation, without question, the network service would be the best choice. However, on the Desktops and especially laptops the NetworkManager serves it's purpose - provides easy and user friendly way to configure your network connection, especially wireless. In pre-NetworkManager time configuring wireless devices without 3rd party software (like wifi-radar) was a real nightmare, unless you were very fluent with low level configuration files.

[altiris]

The default (NetworkManager) works for me. CentOS 7 host (KVM/QEMU), Windows 2012 R2 guest, NIC configured as network bridge. The Windows guest gets a real IP address, accessible from the outside world. I could even RDP to it.

How did you set up bridging or its done automatically? I am beginning to set up KVM and was concerned whether or not NM supports bridging or to revert back and use network like on c6.

[gerald_clark]

The RHEL7 administrators guidel states that NetworkManager does not support bridging.