NetworkManagerからsystemd-networkdへ移行する｜設定変換と無停止切替の手順

なぜ今、systemd-networkdへ移行するのか

NetworkManagerはWi-Fi・VPN・モバイルブロードバンドなど、動的に変わるネットワーク接続を管理するために設計されたデーモンです。デスクトップ環境では非常に優秀ですが、サーバー運用の観点からは「設定の予測可能性が低い」「DBus依存が重い」「ファイルベースの設定管理と相性が悪い」といった指摘が現場でも聞かれます。

一方、systemd-networkdはsystemdスイートに統合されたネットワーク設定デーモンです。シンプルなINI形式の設定ファイルで管理でき、journaldとの親和性が高く、コンテナ・仮想マシンが混在する環境でも動作が安定しています。Ubuntu Serverの22.04以降ではNetplanのバックエンドとしてデフォルトで採用されており、RHEL 9系でも補助的に使用できます。2026年時点では、クラウドインスタンスや最小インストールのサーバー環境でNetworkManagerを置き換える動きが定着しつつあります。

本記事では、既存のNetworkManager環境からsystemd-networkdへ移行する際の設定変換方法と、サービス停止時間を最小化した切替手順を解説します。

移行前の現状把握と事前準備

移行作業は「現在の設定を完全に把握してから」始めるのが大原則です。NetworkManagerが管理している接続情報は以下のコマンドで確認できます。

# アクティブな接続一覧
nmcli connection show --active

# 特定接続の詳細（eth0 の例）
nmcli connection show eth0

# 現在の IP アドレスとルート情報
ip addr show
ip route show
cat /etc/resolv.conf

確認すべき項目は、インターフェース名・IPアドレス（静的かDHCPか）・デフォルトゲートウェイ・DNSサーバー・MTUやボンディング設定の有無です。これらを手元のメモかスクリプトの出力ファイルとして残しておくと、切り戻し時に迷わずに済みます。

NetworkManagerの接続設定ファイルは /etc/NetworkManager/system-connections/ 以下にINI形式で保存されています。移行前にこのディレクトリを丸ごとバックアップしておきましょう。

sudo cp -r /etc/NetworkManager/system-connections/ ~/nm-backup-$(date +%Y%m%d)

設定ファイルの変換：NetworkManager形式からsystemd-networkd形式へ

systemd-networkdの設定ファイルは /etc/systemd/network/ 以下に配置します。ファイル名は 10-eth0.network のように、優先度プレフィックス（数字）＋インターフェース名＋.network という形式が一般的です。

以下に、静的IPを設定したNetworkManagerの接続設定ファイルと、それに対応するsystemd-networkdの設定ファイルを対比します。

NetworkManager側（/etc/NetworkManager/system-connections/eth0.nmconnection）の主要項目：

[connection]
id=eth0-static
type=ethernet
interface-name=eth0

[ipv4]
method=manual
address1=192.168.1.100/24,192.168.1.1
dns=8.8.8.8;8.8.4.4;
dns-search=example.local;

対応するsystemd-networkdの設定（/etc/systemd/network/10-eth0.network）：

[Match]
Name=eth0

[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1
DNS=8.8.8.8
DNS=8.8.4.4
Domains=example.local

DHCPを使用している場合は [Network] セクションに DHCP=yes と記述するだけです。複数インターフェースがある場合は [Match] セクションの Name= を変えたファイルをインターフェース分だけ用意します。

DNS解決はsystemd-resolvedと連携させるのが現在の標準的な構成です。[Network] セクションに DNS= を記述しつつ、/etc/resolv.conf を /run/systemd/resolve/stub-resolv.conf へのシンボリックリンクに変更します（後述の切替手順で実施）。

無停止切替の実行手順

設定ファイルが用意できたら、切替を実施します。NetworkManagerを停止してからsystemd-networkdを起動する間に、ネットワーク疎通が数秒〜十数秒断絶します。SSH接続中の場合はセッションが切断されるリスクがあるため、コンソールアクセスやiPMI・KVM over IP、あるいはクラウドの場合はシリアルコンソールを確保した状態で実施することを推奨します。

切替コマンドを1つのスクリプトにまとめておくと、実行ミスを減らせます。

#!/bin/bash
set -e

# systemd-networkd と systemd-resolved を有効化
systemctl enable systemd-networkd
systemctl enable systemd-resolved

# NetworkManager を停止・無効化
systemctl stop NetworkManager
systemctl disable NetworkManager

# systemd-networkd と systemd-resolved を起動
systemctl start systemd-networkd
systemctl start systemd-resolved

# resolv.conf をスタブリゾルバーに切替
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

echo "切替完了"

スクリプトは実行前に chmod +x で実行権を付与し、sudo で実行します。SSH接続中の場合、tmux や screen セッション内で実行すると、接続断後もスクリプトが継続されるため安全です。どちらも使えない場合は nohup でバックグラウンド実行する方法もあります。

sudo nohup bash /path/to/switch-to-networkd.sh > /tmp/switch.log 2>&1 &

ネットワークが復旧したら再度SSHで接続し、/tmp/switch.log の内容を確認します。エラーが出力されていた場合は次節の検証コマンドで状態を把握してから対処してください。

切替後の検証と切り戻し手順

切替直後は以下のコマンドで状態を確認します。

# インターフェース状態の確認
networkctl list
networkctl status eth0

# IP アドレスとルートの確認
ip addr show
ip route show

# DNS 解決の確認（systemd v245 以降は resolvectl が推奨）
resolvectl status

# 疎通確認
ping -c 3 8.8.8.8
curl -s https://example.com -o /dev/null -w "%{http_code}\n"

networkctl list でインターフェースが routable または configured 状態になっていれば正常です。no-carrier や failed が表示された場合は、設定ファイルの [Match] セクションにおけるインターフェース名のタイポや、物理リンクの問題を疑います。networkctl status eth0 の出力末尾にはjournaldのログが含まれており、エラーの原因を特定しやすくなっています。

切り戻しが必要になった場合は、NetworkManagerを再有効化します。バックアップしておいたNMの設定ファイルはそのまま残っているため、起動後に以前の設定が自動的に読み込まれます。

sudo systemctl stop systemd-networkd systemd-resolved
sudo systemctl disable systemd-networkd systemd-resolved
sudo systemctl enable NetworkManager
sudo systemctl start NetworkManager

# resolv.conf を NetworkManager 管理に戻す
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf

2026年の現行環境と注意点

2026年時点での主要ディストリビューションにおける状況を整理します。

• Ubuntu 22.04 / 24.04 LTS（Server）：Netplanがデフォルトで採用されており、バックエンドとしてsystemd-networkdが使われています。Netplanを経由せずに直接systemd-networkdを設定する場合は、/etc/netplan/ 以下のYAMLファイルと競合しないよう注意が必要です。Cloud-initが有効な環境では、再起動後に設定が上書きされることがあるため、/etc/cloud/cloud.cfg.d/99-disable-network.cfg を作成して network: {config: disabled} を設定しておくことを推奨します。
• RHEL 9 / AlmaLinux 9 / Rocky Linux 9：NetworkManagerが引き続き標準です。systemd-networkdは同梱されていますが、両方を同時に有効化するとインターフェース管理が競合します。移行するならどちらか一方だけを有効化してください。また、firewalldがNetworkManagerのゾーン管理と統合されているため、移行後はfirewalldのインターフェースゾーン設定を個別に確認する必要があります。
• Debian 12（Bookworm）：systemd-networkdはパッケージとして含まれており、有効化するだけで使用できます。NetworkManagerとの共存構成（NMがunmanaged指定したインターフェースをnetworkdが管理する）も技術的には可能ですが、サーバー用途では一方に統一するのが運用上シンプルです。

共通の注意点として、WireGuardやVXLANなどのネットワークオーバーレイを使用している場合は、systemd-networkdの .netdev ファイルで仮想インターフェースを定義する必要があります。NetworkManagerと設定の対応関係が1対1でない場合もあるため、移行前に各仮想インターフェースの設定を個別に把握しておくことが重要です。

systemd v255以降（Ubuntu 24.04相当）では networkctl コマンドの出力フォーマットや一部オプションが変更されており、古いドキュメントをそのまま参照すると混乱することがあります。作業前に networkctl --version でバージョンを確認し、対応するバージョンのmanページ（man networkctl）を参照するのが確実です。

移行の計画段階でテスト環境を用意できる場合は、本番と同じディストリビューション・バージョンで一度試してから本番適用することを強く推奨します。特にクラウド環境では、インスタンスのスナップショットを取得してから作業を開始するのが定石です。静的IPを使ったシンプルな構成であれば移行は比較的スムーズですが、ボンディング・VLAN・ブリッジが絡む構成では事前の検証コストを十分に見込んでおく必要があります。