9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2025年11月に以下のバージョンがリリースされました。

以下の公式リリース情報をベースにしつつ、実際に手を動かしながら Proxmox VE 9.1の新機能や変更点を確認していきます。

メジャーアップグレード前には

事前にバックアップを取得しておくことが推奨されています。

今回

アップグレードで、何ができるようになったのかを確認していきます。

  • 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コンテナ用テンプレートを一覧・ダウンロード・管理するためのコマンド」
  1. ストレージ
  2. CTテンプレート
  3. テンプレート
  4. 一覧が表示される
    コンテナテンプレート.png

アップグレード後(PVE9.1)

  • ストレージ → CT テンプレート に「Pull from OCI Registry」タブ(ボタン)が追加されている
    • Docker Hub(docker.io)や GitHub Container Registry(ghcr.io)など、OCI 対応コンテナレジストリからイメージを取得できる
      OCIタブ追加.png
  • Docker Hubからnginxをダウンロードできるかテストしてみる
    • Reference:docker.io/library/nginx:latestと入力(タグも勝手にlatestと入力される)
    • ファイル名:任意(ここでは nginx-oci.tar.zst
      OCIテンプレ追加.png
    • 「ダウンロード」をクリックすると、OCI イメージの取得とテンプレート化が実行される
      OCIタスク実行.png
    • ダウンロード完了後、「CTを作成」ウィザードの テンプレート選択画面を見ると、 先ほど Pull した OCI イメージがテンプレートとして選択できるようになっている
      テンプレ確認済み.png

仮想マシン関連(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:「中身をそのままディスクに書き込んだだけの、一番シンプルな仮想ディスク形式」
  • イメージとしては、
    • 「VM 本体のディスク」とは別に「TPM 専用の 4MB くらいの小さいディスク」が 1 枚ぶら下がっているだけ、という状態
      TPM.png
      TPM2.png

アップグレード後(PVE9.1)

  • vTPM を追加するダイアログで
    「追加の形式」として QEMU イメージ(qcow2)を選べるようになった

    QEMU.png

  • QEMU イメージ を選ぶと、vTPM の状態が qcow2 形式 のディスクイメージとして保存される

    QEMU2.png

  • 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 を丸ごと見せるかどうか」というオン/オフの制御 になっている
タイプ:ホスト.png

ネスト化している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 が動いている」=ネスト仮想化のイメージ
    ネスト化.png

アップグレード後(PVE9.1)

  • nested-virtフラグの追加
    • ネストさせたいVMのCPU詳細設定から、nested-virtにチェックを入れることで、「種別:ホスト」を選ばなくてもネスト仮想化に必要な特定の拡張機能だけを個別に有効にできる
      • 内部的には、ホスト CPU に応じて vmx(Intel)や svm(AMD)といったネスト用の CPU フラグだけを有効化するイメージ
        nested.png
  • ネストされたハイパーバイザーの動作が安定する
  • 不要な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 設定・マイクロコードなど プラットフォーム全体が対応している必要がある
9
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?