2025年11月に以下のバージョンがリリースされました。
以下の公式リリース情報をベースにしつつ、実際に手を動かしながら Proxmox VE 9.1の新機能や変更点を確認していきます。
- Proxmox VE 9.1 公式アナウンス
https://www.proxmox.com/en/about/company-details/press-releases/proxmox-virtual-environment-9-1 - Proxmox Backup Server 4.1 公式アナウンス
https://www.proxmox.com/en/about/company-details/press-releases/proxmox-backup-server-4-1
メジャーアップグレード前には
事前にバックアップを取得しておくことが推奨されています。
-
Proxmox VE Upgrade from 8 to 9
https://pve.proxmox.com/wiki/Upgrade_from_8_to_9 -
Proxmox Backup Server Documentation
https://pbs.proxmox.com/docs/
今回
アップグレードで、何ができるようになったのかを確認していきます。
- Proxmox VE 8.4(以下 PVE8.4) → Proxmox VE 9.1(以下 PVE9.1)
PVE9.1でできるようになったこと
コンテナ関連(LXC)
新機能:OCI(OCI = Open Container Initiative)イメージ対応
※ OCIイメージ:Dockerなどで使われる標準的なコンテナイメージ形式
※ Docker Hub:コンテナイメージの公式リポジトリで、世界中の開発者・企業が Docker イメージを公開している
アップグレード前(PVE8.4)
- 利用できるコンテナテンプレートは次の 2 種類のみ
- Proxmox が配布している LXC テンプレート(
pveamで取得) - 自作してアップロードした LXC テンプレート
※pveam(Proxmox VE Appliance Manager):「LXCコンテナ用テンプレートを一覧・ダウンロード・管理するためのコマンド」
- Proxmox が配布している LXC テンプレート(
アップグレード後(PVE9.1)
- ストレージ → CT テンプレート に「Pull from OCI Registry」タブ(ボタン)が追加されている
- Docker Hubから
nginxをダウンロードできるかテストしてみる
仮想マシン関連(KVM/QEMU)
新機能:vTPM状態をqcow2形式で保存
※ vTPM:仮想 TPM(virtual TPM)、Windows 11 の要件や BitLocker などで使われる TPM を VM 向けに仮想化したもの。
※ TPM:暗号鍵やブート情報などを安全に保管して PC の改ざん検知や暗号化を支えるための「セキュリティ専用チップ(ハードウェアの鍵箱)」
アップグレード前(PVE8.4)
- VM に vTPM(TPM の状態)を付けること自体はできる
- ただし vTPM の中身は、
vm-101-disk-1.rawのような専用の小さな raw ディスクに保存されており、普通の VM ディスク(qcow2 など)とは別の扱いになっている
※raw:「中身をそのままディスクに書き込んだだけの、一番シンプルな仮想ディスク形式」 - イメージとしては、
アップグレード後(PVE9.1)
-
vTPM を追加するダイアログで
「追加の形式」としてQEMU イメージ(qcow2)を選べるようになった -
QEMU イメージを選ぶと、vTPM の状態が qcow2 形式 のディスクイメージとして保存される -
qcow2 はスナップショットやコピーオンライトなどの機能を持つディスクフォーマットなので、
- VM 本体のディスクと同じ qcow2 形式で TPM 状態も持てる
- バックアップやクローン時に、VM ディスクと vTPM の状態を同じノリで扱いやすくなる
新機能:ネスト仮想化(Nested Virtualization)の細分化制御
※ネスト仮想化:VMの中でさらに仮想化を動かす技術
- PVE8.4 でもネスト仮想化はできていたが、 どの VM にネストを許可するかの制御は、PVE9.1 ほど細かくなかった。
アップグレード前(PVE8.4)
ネストさせるかどうかの制御は、基本的に次の 2 つだけに依存していた
- ホスト側で nested=Y/1 を有効化していること
- ネストさせたい VM(VM100)の CPU 設定で 「種別:ホスト (host)」 を選ぶかどうか
→ vCPU フラグ単位で細かく制御するというより、
「host を丸ごと見せるかどうか」というオン/オフの制御 になっている

ネスト化しているVMの中で次のコマンドを実行すると
ls -l /dev/kvm
egrep -o 'vmx|svm' /proc/cpuinfo | sort -u
-
/dev/kvmデバイスが存在し -
vmx(Intel VT-x のフラグ)が確認できる
これは「VM100 の中からも KVM のハードウェア仮想化(Intel VT-x)が見えている」状態であり、この VM の中でさらに仮想マシンを起動できる(ネスト仮想化が有効)ことを意味している。
実際に VM100 の中で virt-manager などを使う
2 段目の Ubuntu デスクトップのインストーラ画面を表示できている
- 赤枠:PVE 上のゲスト OS(1 段目の Ubuntu デスクトップ, VM100)
- 青枠:その中で動いているネスト化された VM(2 段目の Ubuntu)
※ この状態が「VM の中でさらに VM が動いている」=ネスト仮想化のイメージ
アップグレード後(PVE9.1)
- nested-virtフラグの追加
- ネストされたハイパーバイザーの動作が安定する
- 不要なCPU機能を公開せずに済むため、よりセキュアな環境を構築できる
SDN 関連
新機能:EVPN ゾーンの GUI 表示
- PVE8.4 では EVPN ゾーンは「使えるけど CLI 前提で中身が見えにくい」状態だったのに対し、PVE9.1 では EVPN ゾーンの情報(種別・VNI・関連 VNet など)が Web UI に表示され、SDN の状態を GUI から把握しやすくなった
※EVPN(Ethernet VPN):L3 ネットワークの上に L2 を延ばすための、BGP ベースの VPN
データセンター間やラック間で、同じ L2 セグメント(同じ VLAN 的なもの)を広げるための仕組み
※SDN:ルータやスイッチの設定を、1台ずつポチポチではなく、ソフトウェアからまとめて制御するネットワークの考え方
「8.4 でも EVPN は“できる”が、設定や状態確認は CLI 前提で分かりにくい」
PVE8.4 の時点でも、Datacenter → SDN → ゾーン → 追加 から
- Simple
- VLAN
- QinQ
- VXLAN
- EVPN
といった SDN ゾーン種別を選べる
ただし、この環境では EVPN ゾーンを実際に作ろうとすると、
- Controller / VRF-VXLANTag などの前提設定が必要
- 本気でやるなら
pvesh setや/etc/pve/cluster/sdn/をいじる必要がある
→今回は実施しない
セキュリティ関連
機能強化:Confidential Computing(AMD SEV / Intel TDX)
PVE 8.4 では既に AMD SEV-SNP による Confidential VM が利用可能でしたが、PVE 9.1 ではこれに Intel TDX の初期サポートが追加され、対応 CPU プラットフォームが広がりました。
- VM のメモリをホスト側からも読めないように暗号化する
- ハイパーバイザ(PVE)やホスト OS の root 権限があればゲスト VM のメモリをダンプできる
- デバッガや専用ツールで「VM 内の平文データ」を読むことができる
- つまり インフラ管理者がその気になれば、VM 内の機密情報を“のぞけてしまう” 前提になっている
※残念ながら、今回の検証環境の CPU は対応していないため、 「VM のメモリをホストから隔離する機能(Confidential VM / メモリ暗号化)」は実際には試せていません。。。
仕組みをざっくり説明すると、この機能は
- VM ごとのメモリをハードウェアレベルで暗号化
- 暗号鍵は CPU 内部で管理することでハイパーバイザやホスト OS(= インフラ管理者)がメモリの中身を直接読めないようにする
対応可能モデル
- AMD なら EPYC Rome / Milan 以降(SEV / SEV‑ES / SEV‑SNP 対応の EPYC 7xx2 / 7xx3 / 9xxx 系)
- Intel なら 第4世代 Xeon スケーラブル(Sapphire Rapids)以降の TDX 対応モデル
※いずれも「CPU だけ」ではなく、マザーボード・BIOS 設定・マイクロコードなど プラットフォーム全体が対応している必要がある









