【2026年11月7日時点の情報です】
自宅サーバー（AlmaLinux 9 の KVM のホスト）を、NVMe の SSD ごと新しい PC に差し替えました（前の記事）。AlmaLinux は起きてログインの画面まで来ましたが、ブログ（仮想マシンの WordPress）も NAS も、外とつながりませんでした。
原因は、KVM のブリッジ（br0）の部下になる LAN の口の設定が、前の PC の口の名前と MAC アドレスの両方を名指ししていたことでした。この記事では、それを見つけて直すまでと、同じときに見つけた「時計が9時間進んでいた」件を書きます。ブリッジを作ったときの話はこちらの記事です。
登場するユーザー名、ホスト名、IP アドレスなどは、セキュリティのため実際とは異なる架空のものに置き換えています。MAC アドレスは伏せています。
場面1：口が2つあった
ログインして、LAN の口と、NetworkManager の設定の一覧を見ました。
ip -br link
nmcli -f NAME,DEVICE,TYPE connection show- ip -br link：
この機械の LAN の口の一覧。-brは1行ずつの短い形 - nmcli -f NAME,DEVICE,TYPE connection show：
NetworkManager の設定の一覧と、どの口に付いているか。-fは出す欄を選ぶ
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp2s0 DOWN xx:xx:xx:xx:xx:xx <NO-CARRIER,BROADCAST,MULTICAST,UP>
enp3s0 UP xx:xx:xx:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>
br0 UP xx:xx:xx:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>
virbr0 DOWN xx:xx:xx:xx:xx:xx <NO-CARRIER,BROADCAST,MULTICAST,UP>
vnet0 UNKNOWN xx:xx:xx:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>
NAME DEVICE TYPE
有線接続 2 enp3s0 ethernet
br0 br0 bridge
lo lo loopback
virbr0 virbr0 bridge
vnet0 vnet0 tun
bridge-slave-enp1s0 -- ethernet
enp1s0 -- ethernet
有線接続 1 -- ethernet読み取れたことは次の3つです。
| No. | 見えたこと | 意味 |
|---|---|---|
| 1 | 口が enp2s0（ケーブルなし）と enp3s0（ケーブルあり）の2つ | 前の PC の口は enp1s0 だった。新しい PC では名前が変わった |
| 2 | br0 の部下の設定 enp1s0 の DEVICE が -- | どの口にも付いていない。br0 は外とつながっておらず、仮想マシンも外に出られない |
| 3 | 有線接続 2 が enp3s0 に付いている | NetworkManager が新しい口を見つけて自動で作った設定。DHCP で別の IP をもらっていた |
口の名前の enp3s0 は「PCI の3番のバスにつながった有線の口」という意味で、つながっている場所から決まります。組み込みで言えば、デバイスのアドレスがボードごとに変わるのと同じで、PC を替えると名前も変わります。
2つの口が何の部品かは、lspci で見ました。
lspci -nn | grep -i ether- lspci -nn：
PCI につながった部品の一覧。-nnはメーカーと部品の番号も出す - grep -i ether：
LAN の部品（Ethernet controller）の行だけを出す
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05)enp2s0 は本体の 1G の口、enp3s0 は 2.5G の LAN カードでした。届いた PC に買って取り付けた 2.5G の LAN カードです。家のハブは 2.5G にしてある（こちらの記事）ので、ケーブルを挿していた enp3s0 をそのまま br0 の部下にすることにしました。
場面2：口の名前を付け替えたら断られた
br0 の部下の設定 enp1s0 が名指ししている口の名前を、enp3s0 に変えました。自動で作られた 有線接続 2 は、次に起動したときにぶつからないよう、自動でつながらないようにしました（消さずに残す）。変える前に、NetworkManager の設定のフォルダを丸ごと控えています。
sudo cp -a /etc/NetworkManager/system-connections /root/nm-connections.20261107
sudo nmcli connection modify enp1s0 connection.interface-name enp3s0
sudo nmcli connection modify "有線接続 2" connection.autoconnect no
sudo nmcli connection up enp1s0
ip -br addr show br0- sudo cp -a … /root/nm-connections.20261107：
設定のフォルダの控え。-aは中身と日付・権限をそのまま写す。戻すときは、これを元の場所に戻してsudo nmcli connection reload - nmcli connection modify enp1s0 connection.interface-name enp3s0：
設定enp1s0（br0 の部下）が名指しする口をenp3s0に変える。設定の名前はenp1s0のまま残る（名前と口は別のもの） - nmcli connection modify “有線接続 2” connection.autoconnect no：
自動で作られた設定を、起動のときに自動でつながらないようにする - nmcli connection up enp1s0：
設定を今つなぐ - ip -br addr show br0：
br0 の IP アドレス
エラー: 接続のアクティベーションに失敗: No suitable device found for this connection (device enp2s0 not available because profile is not compatible with device (mismatching interface name)).
br0 UP 192.168.0.20/24 fe80::xxxx:xxxx:xxxx:xxxx/64「この設定に合う口がない（口の名前が合わない）」と断られました。名前は enp3s0 に変えたのに、合わないと言われます。br0 には IP アドレスが付いていますが、部下の口がないので、外とはつながっていません。
場面3：MAC も名指ししていた
設定 enp1s0 の中の、照合に使う項目を出してみました。
nmcli -f connection.interface-name,802-3-ethernet.mac-address,connection.master,connection.slave-type connection show enp1s0
nmcli -f connection.autoconnect,ipv4.method connection show "有線接続 2"- nmcli -f … connection show enp1s0：
設定enp1s0の中の、名指ししている口の名前・MAC アドレス・部下の先・部下の種類だけを出す - nmcli -f … connection show “有線接続 2”：
自動で作られた設定が、自動でつながらない（いいえ）になったかと、IP のもらい方（auto は DHCP）
connection.interface-name: enp3s0
802-3-ethernet.mac-address: xx:xx:xx:xx:xx:xx
connection.master: br0
connection.slave-type: bridge
connection.autoconnect: いいえ
ipv4.method: auto802-3-ethernet.mac-address に、前の PC の口の MAC アドレスが入っていました。NetworkManager は口の名前と MAC の両方で照合するので、名前を変えても、MAC がちがう新しい口は「合わない」と断られていたのです。組み込みで言えば、ドライバの設定がデバイスの番号に加えて製造番号でも照合していて、同じ番号の別の基板を弾いたような状態です。
MAC の欄を空にして、口の名前だけで照合するようにしました。
sudo nmcli connection modify enp1s0 802-3-ethernet.mac-address ""
sudo nmcli connection up enp1s0- nmcli connection modify enp1s0 802-3-ethernet.mac-address “”：
MAC の名指しを空にする - nmcli connection up enp1s0：
直した設定で、enp3s0を br0 の部下としてつなぐ
SSH が切れた
この2行は、ほかの PC から SSH で入って実行しました。connection up のところで画面が止まり、何も返ってこなくなりました。
今の SSH は、有線接続 2 が DHCP でもらった IP アドレスを通っていました。enp3s0 が br0 の部下になった時点で、その道がなくなったのです。組み込みで言えば、デバッグ用の UART をつないだまま、そのピンを別の機能に割り当て直したような状態で、命令は実行されたが、結果を返す線がなくなりました。
SSH の窓を閉じ、1分ほど待ってから、br0 の IP アドレス（192.168.0.20）に入り直しました。入れた時点で、br0 が外とつながったことになります。
場面4：つながった
入り直したところで、br0 の部下と、口の速さ、NAS まで届くかを見ました。
nmcli -f NAME,DEVICE connection show --active
bridge link
ethtool enp3s0 | grep -E 'Speed|Link detected'
ping -c 3 192.168.0.30- nmcli -f NAME,DEVICE connection show –active：
今つながっている設定だけの一覧 - bridge link：
ブリッジの部下の一覧。master br0の行が部下 - ethtool enp3s0 | grep -E ‘Speed|Link detected’：
口の速さと、つながっているか - ping -c 3 192.168.0.30：
NAS に3回届くか
NAME DEVICE
br0 br0
enp1s0 enp3s0
lo lo
virbr0 virbr0
vnet0 vnet0
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100
6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100
netlink error: Operation not permitted
Speed: 2500Mb/s
Link detected: yes
--- 192.168.0.30 ping 統計 ---
送信パケット数 3, 受信パケット数 3, 0% packet loss, time 2030ms| No. | 見えたこと | 意味 |
|---|---|---|
| 1 | 設定 enp1s0 が enp3s0 に付いた | br0 の部下になった |
| 2 | bridge link に enp3s0 と vnet0 | 実際の口と、仮想マシンの口の2つが br0 につながり、通している（forwarding） |
| 3 | Speed: 2500Mb/s | 自宅サーバーも 2.5G でつながった |
| 4 | ping が3回とも届いた | br0 から外に出られる |
netlink error: Operation not permitted は、ethtool を sudo なしで動かしたので、root だけが読める項目（Wake-on-LAN の設定など）を読めなかった、というだけです。速さとつながりは読めています。
ブラウザでブログも開きました。仮想マシンは何も変えていないので、br0 がつながれば、そのまま外に出られます。
場面5：時計が9時間進んでいた
つながったあと、起きてから出たエラーを見たところ、時刻がおかしいことに気づきました。昼すぎに起こしたのに、記録の時刻が 23:44 になっています。
sudo journalctl -b -p err --no-pager | tail -n 15- sudo journalctl -b -p err –no-pager：
今回の起動（-b）のうち、エラー以上（-p err）の記録 - tail -n 15：
最後の15行だけ
11月 07 23:44:07 kvmhost kernel: x86/cpu: SGX disabled or unsupported by BIOS.
11月 07 23:44:13 kvmhost kernel: Warning: Deprecated Driver is detected: nft_compat will not be maintained in a future major release and may be disabledエラーの中身は、どちらも心配のないものでした（SGX は使わない CPU の機能、nft_compat はファイアウォールの古い形の部品の予告）。問題は時刻のほうです。
見立て：BIOS の時計が日本の時刻だった
この自宅サーバーは「BIOS の時計は UTC（世界の標準の時刻）」として使っています。新しい PC の BIOS の時計は、前の Windows の使い方のまま日本の時刻になっていたと見ています。Linux はそれを UTC と読んで、日本の時刻に直すために9時間足したので、9時間進みました。LAN がつながると、NTP（chrony）で正しい時刻に戻ります。
timedatectl
chronyc tracking | grep -E 'Reference|System time|Leap'
[ "$(timedatectl show -p NTPSynchronized --value)" = yes ] && sudo hwclock --systohc --utc && echo "BIOS の時計を UTC で書き直した"
sudo hwclock --show
sudo journalctl -b --no-pager -t backup.sh -t tripwire-filter -t CROND -t anacron | head -n 20- timedatectl：
今の時刻、NTP で合っているか（System clock synchronized）、BIOS の時計を日本の時刻として扱っているか（RTC in local TZ） - chronyc tracking | grep …：
どこの時計に合わせているかと、ずれの大きさ - [ “$(timedatectl show -p NTPSynchronized –value)” = yes ] && …：
NTP で合っているときだけ、次へ進む書き方（C のif (synced) { … }と同じ） - sudo hwclock –systohc –utc：
今の正しい時刻を、UTC で BIOS の時計に書く - sudo hwclock –show：
BIOS の時計を読む（日本の時刻に直して出る） - sudo journalctl -b … -t backup.sh -t tripwire-filter -t CROND -t anacron：
時計が進んでいたあいだに、夜の仕事（控え・改ざんの検査・cron）が動いてしまっていないか
Local time : 土 2026-11-07 14:51:59 JST
Universal time: 土 2026-11-07 05:51:59 UTC
RTC time: 土 2026-11-07 05:51:59
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Reference ID : xxxxxxxx (xx.xx.xx.xx)
System time : 0.000007624 seconds fast of NTP time
Leap status : Normal
BIOS の時計を UTC で書き直した
2026-11-07 14:52:00.507846+09:00
-- No entries --見たときには、NTP で時刻が合い、BIOS の時計（RTC time）も正しい UTC になっていました。念のため UTC で書き直し、読み直しても合っていました。時計が進んでいたあいだに、夜の仕事は動いていませんでした（-- No entries --）。
新しい PC に移したときは、LAN だけでなく、BIOS の時計が日本の時刻か UTC かも見ておくと安心です。
まとめ
SSD をそのまま新しい PC に移すと、KVM のブリッジの部下の設定が、前の PC の口を名前と MAC の2つで名指ししたままになっていて、外とつながりませんでした。両方を直すと、2.5G でつながりました。
| No. | 直したところ | 前 | 後 | コマンド |
|---|---|---|---|---|
| 1 | 部下の設定が名指しする口の名前 | enp1s0（前の PC の口） | enp3s0（新しい PC の 2.5G の口） | nmcli connection modify enp1s0 connection.interface-name enp3s0 |
| 2 | 部下の設定が名指しする MAC | 前の PC の口の MAC | 空（名前だけで照合） | nmcli connection modify enp1s0 802-3-ethernet.mac-address "" |
| 3 | 自動で作られた 有線接続 2 | 起動のとき自動でつながる | つながらない（消さずに残す） | nmcli connection modify "有線接続 2" connection.autoconnect no |
| 4 | BIOS の時計 | 日本の時刻（と見ている） | UTC | hwclock --systohc --utc |
SSH で入って nmcli connection up を動かすと、今の SSH が通っている道が付け替わって切れることがあります。切れても設定は進むので、少し待って、ブリッジの IP アドレスに入り直せば大丈夫です。心配なら、画面とキーボードをつないだ本体の前で作業すると確実です。
移す前に、万一に備えて SSD を USB の HDD に丸ごと控えました。その控えから起こしたときにつまずいた話は、③の記事に書きます。
コメント