こんにちは。クララです。
2026年10月にCVE-2026-99999が発表されました。Linuxカーネルの仮想化機能であるKVMの脆弱性で、悪用されるとVMからホスト側へ抜け出せてしまういわゆる「VMエスケープ」につながるおそれのある脆弱性です。対応にはハイパーバイザー側の更新が必要で、近年注目を集めているProxmoxも対象です。
本記事では、脆弱性への対応を想定して、ISOからインストールしたままのProxmox VEクラスターを、VMを止めずに1台ずつ最新の状態まで更新してみます。
この記事でわかること
- 脆弱性が修正されたバージョンと、今動いているバージョンの確認方法
- HAのメンテナンスモードを使ったローリングアップデートの流れ
- アップデート中のVMの動き（通信の途切れ方、所要時間、VMが元のノードに戻るか）
👇あわせて読みたいおすすめ記事
検証環境
今回用意したのはISOからインストールしたままの3ノードのProxmox VEクラスターです。
VMのストレージには、Ceph（各ノードにOSD 2本）と、OSディスク上のZFS（ZFSレプリケーションで他ノードと同期）の2種類を使い、どちらのVMもHAで管理しています。移行用のネットワークには、Cephと同じ10GbEのネットワークを指定しています。
| 項目 | 更新前 | 更新後 |
|---|---|---|
| Proxmox VE | 9.2.2 | 9.2.24 |
| カーネル | 7.0.2-6-pve | 7.0.14-26-pve |
| Ceph | 20.2.1 | 20.2.4 |
事前確認
1. 脆弱性が修正されたバージョンを確認する
まずは、どのバージョンで脆弱性が修正されたかを確認します。Proxmoxの情報は、公式フォーラムの「Proxmox Virtual Environment Security Advisories」にまとまっています。
https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331
今回のCVE-2026-99999は、カーネル7.0.14-24-pveで修正されています。動いているカーネルが7.0.14-24-pve以降になっていることが、今回のゴールです。
2. 今動いているバージョンを確認する
各ノードの「サマリー」から「パッケージのバージョン」をクリックすると、今動いているカーネルのバージョンやインストールされているパッケージの一覧が確認できます。
今回は7.0.2-6-pveで動いていることが確認できました。
3. 修正されたバージョンまで上がるか確認する
ノードの「更新」画面で「再表示」をクリックすると、更新できるパッケージの一覧が更新されます。「new」の欄で、カーネルが7.0.14-24-pve以降まで上がることを確認します。
「Changelog」をクリックすると、パッケージごとの変更内容も確認できます。
修正内容にきちんとCVE-2026-99999に該当するKVMの修正が含まれていることが確認できます。
※今回は、修正が公開されたタイミングとCVEの採番の都合でCVE-2026-99999の番号は記載されていませんでした。
この確認を3台すべてのノードで行います。
ローリングアップデートの手順
クラスターとCephの状態を確認する
作業を始める前に、クラスターとCephが正常であることを確認しておきます。
Cephにnooutフラグを設定する（任意）
Cephは、OSDが一定時間（既定では10分）停止したままになると、そのOSDを外してデータの再配置を始めます。ファームウェアのアップデートを一緒に行うなど、再起動に時間がかかる場合に備えて、nooutフラグを設定しておきます。
※今回は3ノード構成なので、OSDが外れてもデータを移す先のノードがなく、実際には再配置は起きません。
「Ceph」→「OSD」→「グローバルフラグを管理」から、nooutにチェックを入れます。
※nooutを設定すると、Cephの状態に警告が表示されます。それ以外に警告が出ていなければ問題ありません。
ノードをメンテナンスモードに入れる
更新するノードを、HAのメンテナンスモードに入れます。Proxmox VE 9.2ではGUI上でメンテナンスモードに入れることができないため、この操作はCLIで行います。
ha-manager crm-command node-maintenance enable <ノード名>メンテナンスモードに入ると、ノードのアイコンが🔧マークに変わり、HAで管理しているVMがほかのノードへ自動でライブマイグレーションされます。HAに入れていないVM103（testvm-alma10-nonHA）以外のVMは他のノードへ移動しました。
ノードにVMが残っていないことを確認する
メンテナンスモードはHAの仕組みの中の機能なので、HAで管理していないVMは移動しません。ノードに残っているVMがあれば、手動でマイグレーションするか、シャットダウンします。
※HA管理外のVMをそのままにして再起動すると、そのVMはシャットダウンされます。再起動後に自動で起動するのは、「ブート時に起動」が有効なVMだけです。
アップグレードを実行する
ノードの「更新」画面で「アップグレード」をクリックすると、コンソールが開いてアップデートが始まります。
※「アップグレード」ボタンは、root@pamでログインしているときだけ使えます。Proxmox VE上でAdministrator権限を付けたユーザーでも、GUIからはアップグレードできません。
ノードを再起動する
パッケージの更新が終わったら、ノードを再起動します。
アップグレードで開いたシェルの中でqm listでVMがいないことを確認し、rebootを打つのが対象を間違えないのでお勧めです。
再起動後の状態を確認する
ノードが起動してきたら、次の2点を確認します。
- クラスターとCephの状態が正常であること
- noout flag(s) set以外に警告がない
- PGsがすべてactive+cleanである
- ノードの「サマリー」画面で、カーネルが7.0.14-24-pve以降になっていること
今回はCephのHEALTH_ERRの警告が出ました。これはCephxの脆弱性についてCeph 20.2.4で追加された警告で、Cephxが使用する認証用の鍵をaesからaes256kへ移行するよう促す警告です。可用性の問題ではないためアップデートを続けても問題ないと判断しました。この警告対応も別記事にできればと思っています。
本当に気づくべき警告が埋もれてしまわないよう、今回は該当の6つの警告を作業の間Muteすることにしました。
メンテナンスモードを解除する
ha-manager crm-command node-maintenance disable <ノード名>メンテナンスモードを解除すると、HAが他のノードに逃がしていたVMが、元居たノードに自動で戻ってきます。（HAに入れず手動で移動させたVMは戻ってきません。）
残りのノードも同じように更新する
「ノードをメンテナンスモードに入れる」～「メンテナンスモードを解除する」までの手順を、残りのノードでも1台ずつ繰り返します。
nooutフラグを解除する
すべてのノードの更新が終わったら、「グローバルフラグを管理」からnooutのチェックを外します。
クラスター全体の状態を確認する
すべてのノードの更新が終わったら、クラスター全体の状態を確認します。
- クラスターのHEALTHに警告が出ていないこと
- Muteした警告は一時的に非表示にしているだけなので、作業が終わったら対応しましょう。
- Cephのmon・mgr・OSDがすべて新しいバージョン（20.2.4）で動いていること
補足 Cephのメジャーアップグレードについて
Cephのメジャーアップグレード（Squid → Tentacleなど）は、ノード単位ではなく、mon → mgr → OSD → MDSの順にデーモンを入れ替える手順が公式に用意されています。今回のような20.2.1-pve1→20.2.4-pve5のマイナーアップデートでは、ノード単位の再起動で問題なく更新できました。
https://pve.proxmox.com/wiki/Ceph_Squid_to_Tentacle
よくある質問（FAQ）
Q. マイグレーション中、VMの通信はどれくらい途切れますか？
A. 今回の検証では、マイグレーション用のネットワークをCephで使用している10GbEのネットワークに指定しました。移行時にVMが止まる時間（ダウンタイム）は、Cephに置いたVMで十数〜100ms程度、ZFSレプリケーションのVMで45ms程度でした。1秒間隔のPingでは、欠けても1回程度です。
Cephはディスクを共有しているため、移行するのはメモリだけです。ZFSレプリケーションの場合は、移行の前にディスクの差分を送る手順が入るため、移行全体の時間はCephのVM（約9秒）より長く、約21秒かかりました。
※移行に使うネットワークが細い環境では、移行に時間がかかり、途切れる時間も長くなることがあります。検証の途中、100Mbps相当の経路で移行したときは、ZFSレプリケーションのVMでPingが4〜5回途切れました。移行に使うネットワークは、「データセンター」→「オプション」→「移行設定」で指定できます。
Q. 1台あたりどれくらい時間がかかりますか？
A. 1台あたりの所要時間は、「ノード自体の作業（更新と再起動）」と「VMの移行」の合計です。今回の環境では、ノード自体の作業は約15分でした。
VMの移行は、メンテナンスモードに入れるときと解除するときの2回発生します。今回の環境（メモリ2GBのVM）では、1回あたりCephのVMで約9秒、ZFSレプリケーションのVMで約21秒でした。移行にかかる時間は、VMの台数やメモリの量、移行用ネットワークの帯域、同時に移行する台数によって変わります。
Q. VMは何台同時にマイグレーションされますか？
A. 移行元のノードごとに、同時に実行されるのは既定で最大4台です（「データセンター」→「オプション」の「最大Worker/バルク動作数」で変更できます）。移行先のノードの数には関係ありません。VMの台数が多い場合は、この設定と移行用ネットワークの帯域が全体の所要時間に影響します。
Q. メンテナンスモードを解除すると、VMは必ず元のノードに戻りますか？
A. HAで管理しているVMは、元のノードを記憶していて、解除すると自動で戻ります。ただし、メンテナンス中に手動で別のノードへ移したVMや、HAで管理していないVMは戻りません。
Q. ファームウェアも一緒に更新されますか？
A. aptの更新で入るのは、デバイス用のファームウェア（pve-firmware）までです。サーバーのBIOSやBMCのファームウェアは、別途ベンダーの手順で更新する必要があります。
まとめ
Proxmox VEのHAのメンテナンスモードを使うことで、VMを止めずに1台ずつクラスターを更新できました。GUIでほぼ完結できるので、脆弱性の修正が公開されたときにも、手順を決めておけば落ち着いて対応できると思います。
ポイントは以下の通りです。
- 修正されたバージョンと、今動いているカーネルのバージョンを先に確認しておく
- メンテナンスモードで移動するのはHAで管理しているVMだけなので、HA管理外のVMは手動で対応する
- 1台ずつ、クラスターとCephの状態を確認してから次のノードへ進む
オススメ記事はこちらから👇
