仮想基盤とVMの一斉アップデートを実施後、メディアサーバー上で稼働していた一部のDockerコンテナに異常が発生。
原因究明から復旧までの経緯、発生していた多層エラーの分析、そして今回の反省点を備忘録として残します。
本記事はGeminiに提供したログやレポート、メモを材料にGeminiに出力させています。
概要
アップデート計画
システムの運用方針が固まってきたため、仮想基盤（Proxmox VE）および各Debian VMの一斉アップデートを実施しました。
| 環境 | 旧バージョン | 新バージョン |
|---|---|---|
| Proxmox VE | 9.2.0 | 9.2.20 |
| Debian VM | 13.5 | 13.7 |
実施したアップデート手順
- スナップショットの取得
- Proxmox VEのバージョンアップ（1台ずつ順次実施）
- Proxmox基盤のシステムテスト
- セカンダリDNSサーバー（Debian VM）のバージョンアップ
- システムテスト
- 残りVMのバージョンアップ（Debian VM）
- 全体システムテスト
発生した問題
アップデート自体は問題なく完了し、直後のテストもパスしてスナップショットを削除しました。
しかし数日後、NVIDIA T400をPCIeパススルーしているメディアサーバー上で、一部のDockerコンテナ（PhotoPrism、FileFlows）が起動していないことを検知しました。
バックアップ取得時に起動失敗でもしたのかと思い、VMを再起動。しかし、再起動後も立ち上がらず。
VM内部で nvidia-smi を叩いてもGPUを認識せず、これはおかしいと思い、対処に乗り出しました。。
結論と根本原因
結論として、Proxmoxホスト上でパススルー対象のGPUがハングアップし、PCIeバスから切断されていた（fallen off the bus） ことが原因でした。
VMの再起動（ソフトリブート）ではGPUのハードウェア状態がリセットされず、物理ホスト（Proxmox）を再起動 することで完全に復旧…
実施した対処が悉く間違っていました。
トラブルシューティングの経緯
1. Dockerの起動失敗を検知
アップデートから数日後、メディアサーバー上でDockerコンテナの自動再起動ループが発生していました。直後のテストエビデンスでは動作していたため、OSアップデートによるカーネル更新の影響を疑う。
2. ソフトウェア層を疑った迷走
「OSアップデート直後」という先入観から、以下のソフトウェア起因を疑って調査を進めてしまいました。
- カーネルヘッダーの不整合
- DKMSによるドライバ再ビルドの失敗
- NVIDIAドライバの非互換性
VMの再起動を行っても認識しなかったため、Geminiと壁打ちをしながらドライバのクリーンインストールやDKMSの再ビルドを繰り返し実施。しかし一向に認識せず、一時はバックアップからのVMリストアを検討する段階まで追い込まれました。リストアしなくてホントによかった
3. 物理ホストの再起動と即時解決
リストア準備の途中で「パススルー元のハードウェア状態がスタックしている可能性」は深く考えず、とりあえず再起動しておこうと思い、仮想基盤（Proxmoxホスト）自体を再起動しました。
再起動後、VM上でコマンドを実行したところ、あっけなく正常復帰しました…
# 正常にT400を認識
nvidia-smi
# コンテナ群も問題なくUP
docker ps
システム階層別のエラー分析
今回のトラブルでは様々なエラーメッセージが出力されましたが、独立した障害ではなく**「最下層のハードウェア停止が上位層へ連鎖した現象」**でした。
[1. アプリケーション層] Docker / PhotoPrism起動失敗 (nvml error)
↑
[2. 管理ツール層] nvidia-smi 通信エラー
↑
[3. カーネル層] modprobe デバイス認識失敗 (No such device)
↑
[4. ハードウェア層] GPUがPCIeバスから脱落 (fallen off the bus) ★根本原因
1. アプリケーション層（Docker / PhotoPrism）
error during container init: error running prestart hook #0: exit status 1
nvidia-container-cli: initialization error: nvml error: driver not loaded
- 状況:
docker compose up -d実行時 - 要因: コンテナ起動時にハードウェアアクセラレーションを割り当てようとしたが、ホストOS側でドライバが動作していないためコンテナ生成が強制終了した。
2. コマンド・管理ツール層
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.
Make sure that the latest NVIDIA driver is installed and running.
- 状況:
nvidia-smi実行時 - 要因: ツールがカーネル内のNVIDIAドライバモジュールと通信不能になり、ドライバ不在または初期化失敗として検知された。
3. カーネルモジュール層
modprobe: ERROR: could not insert 'nvidia_current': No such device
modprobe: ERROR: could not insert 'nvidia': Invalid argument
lsmod: ERROR: could not open '/sys/module/nvidia/holders': No such file or directory
- 状況: 手動でドライバ読み込み（
modprobe）を試みた際 - 要因: モジュールファイル自体は存在するものの、対象のハードウェアデバイス（GPU）が応答しなかったため、カーネルへの組み込みがキャンセルされた。
4. ハードウェア・PCIeバス層（根本原因）
NVRM: The NVIDIA GPU 0000:06:10.0 (PCI ID: 10de:1ff2) installed in this system has fallen off the bus and is not responding to commands.
nvidia 0000:06:10.0: probe with driver nvidia failed with error -1
NVRM: None of the NVIDIA devices were initialized.
- 状況: カーネルログ（
dmesg）確認時 - 要因: カーネル6.12とドライバ550系の初期化通信時、T400がパニックを起こしてPCIeバス（マザーボードとの通信経路）から切断されゾンビ化。物理デバイスへのアクセス自体が拒否されていた。
反省と今後の教訓
1. 「VMの再起動」はハードウェアのリセットではない
PCIeパススルーを行っている場合、ゲストVMのOS再起動（ソフトリブート）では物理カードの通電やPCIeリンクのリセットは行われません。物理ホストを再起動するか、PCIeバスのリセットを行わない限り、ゾンビ化したデバイスは復旧しないという前提を再認識する必要がありました。
2. エラーメッセージは下流（ハードウェア層）から確認する
上位層のエラー（nvml error や nvidia-smi の失敗）に引きずられ、ドライバやDKMSの再インストールといったソフトウェアレイヤーの対処に終始してしまいました。
まず dmesg を確認し、物理層・PCIeリンクで fallen off the bus が出ていないか確認する習慣をつけるべきでした。
3. トラブルシューティングの切り分けフロー
今後同様のトラブルが発生した際は、以下の手順で切り分けを行います。
dmesg | grep -E "NVRM|nvidia|PCI"の確認fallen off the busやprobe failedがあれば、ソフトウェアをいじらず即ホスト基盤側のリセットを検討する。
- ホスト側のPCIeデバイス認識確認
- Proxmoxホスト側で
lspciを確認し、物理デバイス自体のリンク状態を検証する。
- Proxmoxホスト側で
- ドライバ再ビルドは物理層が正常であることを確認してから実施する
余談
上の文も8割ぐらいGeminiに起こしてもらいましたが、きれいにまとめてくれて色々と考えてるように見えています。
実際のところ、システムテストは成功したのになんで起動しないの？？？って感じでした。
再起動で直るだろうという認識はあったのですが、まさか仮想基盤だとは…
原因はわからないですが、以下の流れじゃないかと。
Proxmoxアプデ→OSアプデ→システムテスト実施→稼働確認後、VMのバックアップジョブ走る→
バックアップのためVMシャットダウン→何らかの原因でGPUゾンビ化→起動不能検知
インフラ関連はHA組んでて、かつ再起動ぐらいだったら停まっても問題ないシステムばかりなので、最初から仮想基盤の再起動もしておけよってとこですね。 そこから問題解決すればいい。
あとはバージョンアップ前後のバックアップの大切さを思い知りました。使わなかったですが。