Proxmox 9.2 のカスタムCPU設定を試す：AES-NI-V2 からどれだけ速くなるか検証
この記事で実現すること
Proxmox VE 9.2では、GUIからカスタムCPUモデルを設定できるようになりました。
これまでVMのCPUタイプは、互換性を重視する場合はx86-64-v2-AESやkvm64などを選び、性能を重視する場合はhostを選ぶ、という考え方が一般的でした。
ただし、host CPUは物理CPUの機能をVMへ大きく公開できる一方で、異なる世代のCPUを持つクラスタではライブマイグレーション時の安全性に注意が必要です。
今回、Proxmox VE 9.2のカスタムCPUモデルを使い、従来利用していたx86-64-v2-AES相当の設定と比較して、暗号処理やI/O性能にどの程度差が出るのかを検証しました。
検証環境
今回の検証環境は以下のとおりです。
| 項目 | 内容 |
|---|---|
| Proxmox VE | 9.2.2 |
| pve1 CPU | AMD Ryzen 9 7900（Zen4） |
| pve2 CPU | AMD Ryzen 5 5600G（Zen3） |
| VM OS | Ubuntu |
| vmファイルシステム | ext4 |
| ストレージ | ZFS mirror（NVMe x2 / rpool） |
| iothread | ON |
今回の主目的はライブマイグレーションそのものではなく、同一VM上でCPUタイプを変更した場合に、AES-NI-V2相当の設定とカスタムCPUモデルでどの程度性能差が出るかを確認することです。
ただし、クラスタ内にZen3とZen4のCPUが混在しているため、CPUフラグの互換性も考慮しています。
カスタムCPUモデルの設定
今回作成したカスタムCPUモデルは以下です。
ポイントは、pve1とpve2の両方でサポートされているCPUフラグのみを明示的に有効化したことです。
また、Zen4のRyzen 9 7900はAVX-512系の機能を持っていますが、Zen3のRyzen 5 5600Gは対応していません。そのため、avx512fは明示的に無効化しています。
| 項目 | 設定値 |
|---|---|
| 名前 | zen3-zen4-compat |
| Base Model | EPYC |
有効化したCPUフラグ
| 操作 | フラグ |
|---|---|
| 有効化 | aes, sha-ni, avx, avx2, bmi1, bmi2, fma, rdrand, vaes |
| 無効化 | avx512f |
Proxmoxで「データセンター」→「カスタムCPUモデル」と進むとそこで設定できます。
環境によってフラグは異なりますが、単一のノードで運用されている方はサポートされているフラグをOnにする、クラスタノードでは両方がそのオプションが使えることを確認の上でOnにするということです。Flgの意味が厳密に理解できなくても、ひたすらぽちぽちと設定していく、そんな感じでしょうか。
Base Model に EPYC を選んだ理由
最初は、より新しいCPUモデルである EPYC-Milan-v3 なども候補にしました。
しかし、実際に試したところ、pcid フラグに関連する起動エラーが発生しました。
一方で、Base Modelを EPYC にした場合は問題なく起動できました。
EPYC はNaples世代、つまりZen1ベースのモデルです。新しいモデルと比べるとデフォルトで有効になるCPUフラグは少なめですが、その分、必要なフラグだけを明示的に追加しやすく、今回のような混在CPU環境では扱いやすいと感じました。
今回の方針は、以下のような考え方です。
- Base Modelは控えめにする
- 必要なCPUフラグだけを追加する
- 片方のノードにしか存在しないフラグは入れない
- AVX-512は明示的に無効化する
結果として、EPYC をベースにしつつ、AES、SHA、AVX2、VAESなどの実用上効果が大きいフラグを追加する構成にしました。
比較対象
今回の比較対象は以下の2つです。
| 区分 | CPU設定 |
|---|---|
| BEFORE | AES-NI-V2 相当 |
| AFTER | カスタムCPUモデル zen3-zen4-compat |
host CPUとの比較ではなく、あくまで従来の互換性重視設定と、Proxmox 9.2のカスタムCPUモデル設定との比較です。
CPUベンチマーク
実行コマンド
CPU性能の確認には、OpenSSL、sysbench、stress-ngを使用しました。
openssl speed -evp aes-256-gcm
openssl speed -evp aes-256-cbc
openssl speed sha256
sysbench cpu –cpu-max-prime=20000 –threads=4 run
stress-ng –matrix 4 –matrix-size 256 –metrics-brief –timeout 10s
結果
8KBブロック基準の結果は以下です。
| テスト | BEFORE（AES-NI-V2） | AFTER（custom EPYC） | 変化 |
|---|---|---|---|
| AES-256-GCM | 803,394 KB/s | 5,668,009 KB/s | 約7倍 |
| AES-256-CBC | 1,517,008 KB/s | 1,516,557 KB/s | ほぼ変化なし |
| SHA-256 | 617,835 KB/s | 2,509,324 KB/s | 約4倍 |
| sysbench | 9,193 events/s | 9,197 events/s | ほぼ変化なし |
| stress-ng matrix | 2,295 bogo ops/s | 2,540 bogo ops/s | 約10%向上 |
AES-256-GCM が大きく伸びた理由
もっとも大きな差が出たのはAES-256-GCMです。
BEFOREでは803,394 KB/sだったものが、AFTERでは5,668,009 KB/sまで向上しました。およそ7倍の差です。
AES-256-GCMはTLS 1.3でも広く使われる暗号方式です。そのため、VPN、TLS終端、SSL/TLSインスペクションなど、暗号処理が多いVMではかなり大きな意味を持つ結果だと思います。
SHA-256 も大きく向上
SHA-256も大きく改善しました。
BEFOREでは617,835 KB/sだったものが、AFTERでは2,509,324 KB/sになりました。こちらはおよそ4倍です。
SHA-256は暗号処理だけでなく、チェックサムやハッシュ計算でも使われます。ZFSのチェックサム処理そのものをVM内で直接行っているわけではありませんが、VM内の処理効率が上がることで、間接的にI/O性能にも影響が出る可能性があります。
まとめ
Proxmox VE 9.2のカスタムCPUモデルを使うことで、従来のAES-NI-V2相当設定と比較して、暗号処理性能を大きく改善できました。
特にAES-256-GCMとSHA-256の改善は非常に大きく、VPN、TLS、暗号処理、ハッシュ処理を多用するVMでは効果が期待できます。
一方で、すべての処理が速くなるわけではありません。sysbenchのような一般的なCPUベンチマークではほぼ変化がなく、AES-256-CBCも大きな差は出ませんでした。
つまり、カスタムCPUモデルの効果は、CPUそのものを速くするというより、VMから利用できるCPU命令を適切に公開することで、対応する処理を大きく高速化するものだと考えています。
個人的には、Proxmox VE 9.2のカスタムCPUモデルは、混在CPUクラスタにおいてかなり実用的な新機能だと感じました。
互換性を重視して x86-64-v2-AES などに寄せすぎると、現代のCPUが持っている命令を活かしきれません。一方で host にすると、混在環境ではライブマイグレーション時の安全性に不安が残ります。
その中間として、必要なCPUフラグだけを明示的に公開するカスタムCPUモデルは、性能と互換性のバランスを取るうえで非常に良い選択肢だと思います。