← logs

Proxmox Cluster 同期エラー (Cannot initialize CMAP service) 復旧手順

2025年12月25日

Proxmox VE クラスタで corosync.conf の config_version がずれ、Cannot initialize CMAP service になったノードを pmxcfs local mode で復旧した記録

tags: Proxmox, Infrastructure, Troubleshooting

Proxmox VEクラスタで、特定ノードだけクラスタ同期が取れなくなった。

pvecm status を実行すると、次のエラーが出た。

Cannot initialize CMAP service

この記事では、時刻同期やCorosyncの状態を確認し、最終的に corosync.conf の config_version ずれとして復旧した手順を残す。

現象

対象ノードで、Proxmox VEクラスタの状態確認ができなくなった。

pvecm status

出力には次のエラーが出る。

Cannot initialize CMAP service

/etc/pve も通常のクラスタ同期状態では扱えず、設定修正がしづらい状態だった。

最初に確認したこと

まず、時刻同期を疑った。

Corosyncやクラスタ系の問題では、ノード間の時刻ずれが原因になることがある。

chronyc sources -v

この時点では、Reachは 377、Offsetも小さく、時刻同期は大きく崩れていなかった。

次に、Corosyncのサービス状態を確認した。

systemctl status corosync

ここでは、プロセスがエラー終了しているというより、code=exited, status=0/SUCCESS で終了しているように見えた。

つまり、Corosyncがクラッシュしているのではなく、何らかの条件を見て自分で止まっている可能性が高い。

決定的なログ

journalctl でCorosyncのログを確認した。

journalctl -b -u corosync

決定的だったのは次のログである。

[CMAP  ] Received config version (6) is different than my config version (5)! Exiting

稼働中クラスタ側のconfig versionは 6 である。 一方で、対象ノードが持っている corosync.conf のconfig versionは 5 だった。

この差分により、Corosyncが安全側に倒れて停止していた。

原因

原因は、対象ノード上の corosync.conf が古い状態のままだったことだった。

cluster side:
  config_version: 6

target node:
  config_version: 5

Proxmoxのクラスタ設定は /etc/pve/corosync.conf にある。

通常、/etc/pve は pmxcfs によって提供されるクラスタファイルシステムである。 しかし、クラスタ同期が正常にできない状態では、通常の方法で書き換えられないことがある。

そのため、pmxcfs をlocal modeで起動し、対象ノード側の設定を修正した。

復旧手順

まず、関連サービスを停止する。

systemctl stop pve-cluster corosync

pmxcfs のプロセスや /etc/pve のmountが残っているとlocal modeに入れないため、確実に止める。

killall pmxcfs
umount /etc/pve

umount /etc/pve は、すでにmountされていなければ not mounted になる。 その場合はそのまま進める。

次に、pmxcfs をlocal modeで起動する。

pmxcfs -l

この状態で、corosync.conf を編集する。

nano /etc/pve/corosync.conf

対象箇所は totem セクションの config_version である。

totem {
  ...
  config_version: 6
  ...
}

今回は 5 になっていた値を、稼働中クラスタ側に合わせて 6 へ変更した。

編集後、local modeの pmxcfs を止める。

killall pmxcfs

最後に、通常モードでサービスを起動する。

systemctl start pve-cluster corosync

確認

復旧後、クラスタ状態を確認する。

pvecm status

Quorate: Yes またはQuorumが取れている状態になり、ノード情報が表示されれば復旧できている。

あわせて、Corosyncのログに同じconfig version mismatchが出ていないことを確認する。

journalctl -b -u corosync

注意点

この手順は、corosync.conf の config_version ずれが原因である場合の復旧手順である。

Cannot initialize CMAP service という表示だけで、必ずこの原因だと決めるべきではない。

最低限、次を確認してから作業する。

時刻同期が大きく崩れていないか
corosync がクラッシュしていないか
journalctl に config version mismatch が出ているか
稼働中クラスタ側の config_version が何か
対象ノード側の config_version が何か

また、corosync.conf はクラスタの重要設定である。 値を合わせるときは、稼働中クラスタ側の設定を確認してから変更する。

まとめ

今回の問題は、Corosyncや時刻同期そのものではなく、corosync.conf の config_version ずれだった。

ログでは次のように見えていた。

Received config version (6) is different than my config version (5)! Exiting

通常の /etc/pve が扱えない状態だったため、pmxcfs -l でlocal modeに入り、対象ノード側の config_version を稼働中クラスタ側に合わせた。

Proxmoxクラスタの復旧では、pvecm status のエラーだけで判断せず、journalctl -b -u corosync のログまで見ることが重要である。

関連ログ