I manage RHEL 8 systems where both NetworkManager and the legacy network-scripts packages are installed. Things generally work, but I'm concerned about edge cases when both are present. Restarting the network service also causes a brief outage. Is it better to migrate fully to NetworkManager, and how can I handle that transition when external automation still edits network-scripts? If both must remain for now, what's the safest way to operate them together?
3 Answers
Systemd-networkd is another networking option, but it doesn’t really provide a practical middle ground here. For RHEL 8, the supported migration path is NetworkManager, and newer RHEL versions are even more firmly centered on it. Keep the legacy setup only as a temporary compatibility measure and plan the automation migration.
The long-term answer is to move everything to NetworkManager. It’s the supported networking stack on current RHEL releases, while network-scripts are legacy and should be treated as a migration dependency rather than the future design. Update the automation to use NetworkManager profiles or its command-line/API tools, then remove the legacy service once nothing depends on it.
If you have to keep both installed temporarily, avoid having both manage the same interfaces. Choose one owner for each connection and make sure the other stack ignores it. Mixing configuration files and restarting the legacy network service can produce unexpected state changes, so test carefully and prefer targeted connection changes over restarting the entire network.
The brief outage is probably from restarting the whole network service. Updating or reactivating only the affected NetworkManager connection is usually less disruptive, though any change to a live interface can still interrupt traffic.
That’s the direction I’m considering, but changing the external automation will take time. I’m mainly looking for a safe interim approach on RHEL 8.