はじめに

NTT西日本の平岡です。

Proxmox VEは、オープンソースの仮想化プラットフォームとして、企業や教育機関を中心に広く採用されています。特に、複数ノードで構成するクラスタ環境では、高可用性とライブマイグレーション機能により、ダウンタイムを最小限に抑えたVM（Virtual Machine、仮想マシン）運用が可能です。

しかし、クラスタ構成で共有ストレージを使用する際、ストレージの種類によって利用できる機能に制限がありました。特に、iSCSIやFCといったブロックストレージを使用する場合、共有LVM（Logical Volume Manager）ストレージ上ではWebUIからスナップショット機能を利用できないという制約があり、長年にわたり運用上の課題となっていました。

本記事では、この課題の背景と、Proxmox VE 9.0で導入された新機能による改善効果を、実際の検証データをもとに報告します。まずは、Proxmox VEクラスタにおける共有ストレージの構成と、そこで生じていた問題について説明します。

対象読者

Proxmox VEを運用中、または導入検討中のインフラエンジニア
iSCSI/FCベースの共有ストレージ環境でスナップショット運用に課題を感じている方

1. 検証の背景と目的
2. Proxmox VEクラスタにおける共有ストレージ
3. LVMスナップショット方式の性能評価(Proxmox VE 8.4系)
4. Snapshot as Volume Chain方式の概要(Proxmox VE 9.0系)
5. Snapshot as Volume Chain方式の性能評価(Proxmox VE 9.0系)
- 5.1. 設定手順
  - 5.1.1. storage.cfgの編集
  - 5.1.2. WebUIでの確認
- 5.2. ファイルI/O性能測定結果
  - 5.2.1. ファイル作成性能
  - 5.2.2. システムリソース使用状況
6. 性能比較
- 6.1. ファイルI/O性能の比較
  - 6.1.1. ファイル作成速度
  - 6.1.2. I/Oレイテンシ
- 6.1.3. Write IOPS
7. 運用上の考慮事項
- 7.1. 容量設計
  - 7.1.1. 推奨容量計算式
  - 7.1.2. 容量不足時の挙動
- 7.2. 最適化設定(saferemove)
  - 7.2.1. 単一テナント環境向け設定
  - 7.2.2. セキュリティ重視環境向け設定
8. 注意点
9. まとめ
9.4. 今後の展望
10. 参考情報
- 10.1. 公式ドキュメント
11. 商標について
12. 免責事項
- 12.1. データ損失に関する注意事項
- 13. 執筆者

1. 検証の背景と目的

1.1. LVMスナップショット問題

1.1.1. 共有LVMストレージでの制約

Proxmox VE 8.4系以前では、クラスタ構成で使用する共有LVMストレージ（iSCSI/FC経由のLUN上のLVM）に対して、WebUIからスナップショットを作成することができませんでした。この制約により、システム変更前の保護ポイント作成が困難という運用上の課題がありました。

1.1.2. 8.4系での手動検証（サポート外）

本記事では、この制約が技術的にどの程度の性能問題を引き起こすのかを定量的に確認するため、Proxmox公式サポート対象外の手動LVMスナップショット(lvcreate -s)を使用した検証を実施しました。

注意: この方法はProxmox VEの公式サポート対象外であり、以下のリスクがあります。

Proxmox管理データベースとの不整合の可能性
WebUIでの可視化不可
自動管理機能の対象外
トラブル時のサポート対象外

あくまで性能特性を把握するための検証目的での実施です。

1.2. Proxmox VE 9.0での改善

2025年8月、Proxmox VE 9.0のリリースにより状況が大きく変わりました。

1.2.1. Snapshot as Volume Chain方式の導入

Proxmox VE 9.0では、新たにSnapshot as Volume Chain方式がTechnology Preview機能として導入されました。これは、従来のCoW方式とは根本的に異なるアプローチです。

各スナップショットを独立したLogical Volumeとして管理
qcow2のbacking file機能を活用したチェーン構造
ボリュームグループ全体ではなく個別ボリューム単位での管理

1.2.2. 公式サポート化の意義

8.4系では「クラスタ構成の共有LVMでWebUIから使えない機能」だったスナップショットが、9.0系では「Technology Previewとして提供される機能」として扱われるようになりました。これにより、iSCSIやFCを使用するブロックストレージ環境でも、NFSと同様のスナップショット運用が可能になる道が開かれました。

WebUIから簡単にスナップショット作成が可能に
Proxmox CLIツール(qm snapshot)での統合管理
公式ドキュメントでの設定手順提供
コミュニティフォーラムでのサポート対象化

1.3. 本検証の目的

本記事では、以下の点を明らかにします。

8.4系での手動スナップショット検証結果の詳細
- サポート外手法による性能測定データ
- 性能劣化の定量的証拠
9.0系の新方式による性能改善効果
- 公式サポートされたSnapshot as Volume Chain方式の実測性能
- 従来方式との直接比較
実運用適用可能性の評価
- Technology Preview段階での制約事項
- 運用上の注意点と推奨設定

筆者が8.4系でサポート対象外の手法により実施した検証結果と、9.0系で公式にサポートされた新機能の性能を比較します。これにより、Proxmox VEのスナップショット機能がどのように進化したかを示します。

1.4. 検証環境

本記事の検証は、以下のハードウェア環境で実施しました。

2. Proxmox VEクラスタにおける共有ストレージ

2.1. Proxmox VEクラスタにおける共有ストレージの役割

Proxmox VEクラスタでは、複数ノード間でVMを自由に移動させるライブマイグレーション機能や、ノード障害時の自動フェイルオーバー機能を実現するために、全ノードからアクセスできる共有ストレージが必須となります。この共有ストレージの実装方式には、大きく分けて2つのアプローチがあります。

2.2. 2つのストレージアプローチとその特性

2.2.1. ファイルベースストレージ (NFS/CIFS)

特徴:

NFSやCIFSプロトコルでファイル共有を実現
ファイルシステムレベルでの機能をそのまま利用可能
VMディスクはqcow2やraw形式のファイルとして保存

スナップショット機能:

WebUIから利用可能
qcow2形式の内部スナップショット機能を活用
VMクローンやロールバックが容易に実現可能

2.2.2. ブロックベースストレージ (iSCSI/FC)

特徴:

iSCSIやFCプロトコルでLUNを提供
ブロックデバイスとして認識されるため、Proxmox VE側でボリューム管理が必要
一般的にLVM(Logical Volume Manager)を使用して論理ボリュームを管理

LVMを使用する理由:

複数VMで1つのLUNを共有するための論理的な分割
ボリュームサイズの柔軟な割り当てと変更

スナップショット機能:

Proxmox VE 8.4系以前では、共有LVM上でWebUIから利用不可
手動でLVMコマンドを実行する必要があった（サポート外）

2.3. ブロックストレージでのスナップショット制限

このように、同じクラスタ構成であっても、NFSストレージではスナップショット機能がフルに利用できる一方で、iSCSI/FCのブロックストレージでは利用できないという、ストレージタイプによる機能差が存在していました。

2.3.1. 具体的な運用上の影響

Proxmox VE 8.4系以前では、クラスタ構成における共有LVMストレージでWebUIからスナップショットを作成できないことで、以下のような運用上の問題が発生していました。

システム変更前の保護ポイント作成ができない
アプリケーション更新やOS設定変更前に、瞬時に戻せる保護ポイントを作成できませんでした。

2.3.2. 回避手段とその限界

スナップショット機能が利用できない問題に対し、以下のような回避手段が取られていましたが、いずれも制約がありました。

NFSストレージへの移行: スナップショット機能は使えるが、ブロックストレージと比較して性能面で不利になるケースがある
手動でのLVMコマンド実行: Proxmoxの管理対象外となり、サポート対象外の操作となる
バックアップツールでの代替: スナップショットと比較して時間がかかり、瞬時的な保護ポイントとしては不向き

このように、iSCSIやFCといったブロックストレージを使用する環境特有の制約として、長年認識されていました。

2.4. Proxmox VE 9.0での転換点と本記事の目的

2025年8月、Proxmox VE 9.0のリリースにより、この長年の課題に対する解決策が提供されました。Snapshot as Volume Chain方式と呼ばれる新技術が、Technology Preview（技術プレビュー、正式版リリース前の試験的機能）として導入されました。

本記事では、以下の内容を報告します。

Proxmox VE 8.4系での手動スナップショット検証
サポート外の手段である手動LVMスナップショットの性能を実測し、性能劣化を定量的に確認
Proxmox VE 9.0系の新方式による性能改善
Snapshot as Volume Chain方式の実測性能を評価し、従来方式と比較
Proxmox VE 9.1での状況と今後の展望
最新バージョンでの改善状況と、実運用適用に向けた考察

まずは、これまでの問題の詳細と、筆者が実施した検証の背景から説明します。

3. LVMスナップショット方式の性能評価(Proxmox VE 8.4系)

3.1. 手動でのLVMスナップショット作成方法

Proxmox VE 8.4系では、共有LVMストレージに対してqm snapshotコマンドが対応していなかったため、以下の手順でLVMのlvcreate -sコマンドを直接実行してスナップショットを作成しました（サポート外操作）。

# VMを停止
qm stop 101

# LVMコマンドで直接スナップショットを作成（サポート外）
lvcreate -L 30G -s -n vm-101-disk-0-backup-$(date +%Y%m%d-%H%M%S) \
  /dev/iSCSI-LVM-VG/vm-101-disk-0

# VMを起動
qm start 101

注意: この方法は、Proxmox VEの公式サポート対象外です。8.4系では共有LVMに対するProxmox標準のスナップショット機能が利用できなかったため、性能検証を目的としてこの手法を採用しています。

この方法はProxmox公式サポート外であり、以下のリスクがあります。

Proxmox管理データベースとの不整合の可能性
WebUIでの可視化不可
自動管理機能の対象外
トラブル時のサポート対象外

3.2. 測定方法

3.2.1. ベンチマークの設計思想

本検証では、LVM CoWスナップショットの性能劣化を最大限に引き出すことを意図したベンチマークを設計しました。

CoW（Copy-on-Write）方式の特性:

スナップショット作成後、元のデータブロックへの書き込みが発生すると、書き込み前に元データをスナップショット領域にコピーする処理が発生
この「コピー→書き込み」という2段階の処理が性能劣化の主要因
特に、多数の異なるブロックへの書き込みが発生すると、CoW処理の回数が増加し、劣化が顕著になる

3.2.2. ベンチマークスクリプトの構成

検証には以下の3つのスクリプトを使用しました:

1. ファイル作成スクリプト

目的: 多数のディレクトリに分散した大量ファイルの作成により、広範囲のデータブロックへの書き込みを発生させる
処理内容:
- 1,048個のディレクトリを階層的に作成
- 各ディレクトリに約100個のファイル(100KB/個)を配置
- 総ファイル数: 104,857個
- 総データ量: 約10GB
CoW負荷の発生メカニズム: ディレクトリが分散しているため、ファイル作成時のメタデータ更新とデータ書き込みが広範囲のブロックに分散し、CoW処理が頻発

2. ファイル更新スクリプト

目的: 既存ファイルの上書き更新により、意図的にCoW処理を大量発生させる
処理内容:
- 作成済みの全ファイル(104,857個)を段階的に更新
- 更新パターン:
  - 初回作成: 0x00パターン（全てゼロ）
  - 1回目更新: 0xFFパターン（全て1）
  - 2回目更新: 0x55パターン（01010101の交互パターン）
  - 3回目更新: 0xAAパターン（10101010の交互パターン）
CoW負荷の発生メカニズム: 既存データへの上書きのため、スナップショット環境では全ての書き込みでCoW処理が発生

3. リアルタイムモニタリングスクリプト

目的: ベンチマーク実行中のシステムリソース使用状況を継続監視
監視項目: CPU使用率、メモリ使用量、Write IOPS、I/Oレイテンシ、ディスク書き込み速度
取得間隔: 1秒
出力形式: CSV形式でログ保存

3.2.3. このベンチマークが意図する検証

8.4系（従来CoW方式）での予想:

スナップショット作成後、ファイル更新のたびにCoW処理が発生
104,857個のファイルへの書き込み = 104,857回のCoW処理
性能劣化が発生するはず

9.0系（Snapshot as Volume Chain）での予想:

qcow2のbacking file構造により、CoW処理の影響を最小化
スナップショット数が増えても性能劣化がほぼ発生しないはず

3.2.4. 測定条件

総データ量: 10GB
ファイル数: 104,857個(100KB/ファイル)
フォルダ数: 1,048個
測定項目: ファイル作成時間、ファイル作成速度、I/Oレイテンシ、Write IOPS
測定タイミング: スナップショット0個、1個、2個作成後にそれぞれ測定

3.3. 性能測定結果

3.3.1. ファイル作成性能

スナップショット数	ファイル作成速度（ファイル/秒）	作成時間	性能劣化率
0個(ベースライン)	9,236.5 ファイル/秒	11.35秒	-
1個	313.5 ファイル/秒	334.51秒	29.5倍劣化
2個	199.2 ファイル/秒	526.34秒	46.4倍劣化

3.3.2. システムリソース使用状況

項目	0個	1個	2個
CPU使用率(平均)	5.56%	2.58%	2.20%
メモリ使用量	0.79GB	0.78GB	0.86GB
Write IOPS(平均)	3,675	1,709	1,324
I/Oレイテンシ(平均)	22.5ms	209.2ms	309.9ms
ディスク書き込み(平均)	271.36MB/s	124.26MB/s	94.67MB/s
Load Average(平均)	1.08	1.72	2.14

3.4. 性能劣化の分析

検証の結果、Proxmox VEが共有LVMストレージでスナップショット機能をWebUIから利用できないようにしていた背景が理解できました。従来のLVMスナップショット方式は、実運用には適さない性能劣化を引き起こすためです。

3.4.1. 性能劣化の原因とベンチマーク設計の妥当性

本検証で確認された性能劣化は、ベンチマーク設計の意図通り、CoW処理の本質的な問題を浮き彫りにした結果です。

Copy-on-Write処理のオーバーヘッド
- ベンチマークの効果: 1,048個のディレクトリに分散した104,857個のファイル作成により、広範囲のデータブロックへの書き込みを強制
- 結果: 元データへの書き込みごとにCoW処理が発生し、スナップショット数に比例して劣化が加速
- 数値: スナップショット1個で29.5倍、2個で46.4倍という加速度的な劣化を観測
I/Oレイテンシの急増
- ベンチマークの効果: 多数のディレクトリへの分散書き込みにより、メタデータ更新とデータ書き込みが複雑化
- 結果: スナップショット2個時で309.9ms（ベースライン比13.8倍）
- 実用影響: アプリケーションレベルでの体感速度低下が顕著に
Write IOPSの急減
- ベンチマークの効果: 104,857個の小ファイルへの書き込みにより、IOPS負荷を最大化
- 結果: 3,675 → 1,323（64%減少）
- 実用影響: データベースや頻繁な書き込みを行うアプリケーションでの影響
なぜこのベンチマークが有効だったか
- 広範囲ブロック書き込み: ディレクトリ分散により、CoW処理が広範囲のブロックで発生
- メタデータ負荷: ディレクトリ構造の更新により、メタデータへのCoW処理も頻発
- 実環境の再現: ファイルサーバーやアプリケーションサーバーの実際の負荷パターンに近い状況を再現

3.4.2. 実運用での問題点

この性能劣化により、以下の運用上の問題が想定されます。

通常業務への性能影響
スナップショット保持中の運用制約
スナップショット削除時の負荷集中

4. Snapshot as Volume Chain方式の概要(Proxmox VE 9.0系)

4.1. 公式サポート機能としての登場

Proxmox VE 9.0では、Snapshot as Volume Chain方式がTechnology Preview機能として正式に実装されました。これは、8.4系でWebUIから利用できなかった機能が、技術的改善により利用可能な機能として提供されたことを意味します。

4.1.1. WebUIからの操作が可能に

最も大きな変化は、WebUIから直接スナップショットを管理できるようになったことです。

Datacenter → Storage → LVMストレージ → Edit
Advanced設定で「Enable Snapshots as Volume Chains」を有効化
VM単位でのスナップショット作成・削除・ロールバックが可能

4.1.2. 公式CLIツールでの統合管理（9.0系での改善）

9.0系での大きな変化: Proxmox標準のqmコマンドで、共有LVMストレージ上のスナップショットを管理できるようになりました。

# スナップショット作成
qm snapshot <vmid> <snapshot-name> --description "説明"

# スナップショット一覧
qm listsnapshot <vmid>

# ロールバック
qm rollback <vmid> <snapshot-name>

# スナップショット削除
qm delsnapshot <vmid> <snapshot-name>

4.2. 新方式の技術的特徴

Snapshot as Volume Chain方式は、従来のCoW方式とは根本的に異なるアプローチを採用しています。

4.2.1. 独立したLogical Volumeとしての管理

従来方式では、スナップショットは元ボリュームに依存する形で作成されました。新方式では、各スナップショットが独立したLVとして存在します。

# スナップショット作成後のLV構成例
lvs
  LV                                   VG           Attr       LSize   
  vm-105-disk-0.qcow2                  iSCSI-LVM-VG -wi-a----- <100.02g
  snap_vm-105-disk-0_baseline.qcow2    iSCSI-LVM-VG -wi-a----- <100.02g

4.2.2. qcow2のbacking file機能の活用

新方式では、qcow2フォーマットのbacking file機能を使用してチェーン構造を構築します。

qemu-img info /dev/iSCSI-LVM-VG/vm-105-disk-0.qcow2
image: /dev/iSCSI-LVM-VG/vm-105-disk-0.qcow2
file format: qcow2
virtual size: 100 GiB
backing file: snap_vm-105-disk-0_baseline.qcow2

この構造により、現在のボリュームはスナップショットボリュームを参照し、差分のみを保持します。

4.2.3. ボリューム単位での性能最適化

従来のCoW方式では、ボリュームグループ全体に性能影響が及んでいた可能性があります。新方式では、各ボリュームが独立して管理されるため、影響範囲が限定されると考えられます。

4.3. 従来方式との違い

項目	従来CoW方式(8.4)	Volume Chain方式(9.0)
Proxmoxサポート	WebUI非対応	公式サポート(TP)
作成方法	手動(`lvcreate`)	WebUI / `qm snapshot`
スナップショット管理	単一ボリューム内	独立したLV
書き込み処理	CoWオーバーヘッド大	個別ボリューム単位
性能影響範囲	VG全体	個別ボリューム
Proxmox管理DB	非連携	完全連携

4.4. Technology Previewとしての位置づけ

Snapshot as Volume Chain方式は、Proxmox VE 9.0においてTechnology Preview機能です。

4.4.1. Technology Previewの意味

正式機能としてリリース予定だが、現時点では試験段階
本番環境での使用は慎重な評価後に判断すべき
仕様変更や改善が今後のバージョンで行われる可能性
コミュニティフォーラムでのフィードバック収集中

4.4.2. 公式サポートされる機能への期待

Technology Previewではあるものの、Proxmox公式が提供する機能であることの意義は大きいです。

公式ドキュメントでの設定手順提供
バグ報告・機能要望の正式ルート確保
将来のProxmox VE 9.x / 10.xでの正式版化への道筋

8.4系でWebUIから利用できなかった機能が、9.0系では公式に提供される機能として扱われるようになったことは、技術的な前進と言えます。

5. Snapshot as Volume Chain方式の性能評価(Proxmox VE 9.0系)

5.1. 設定手順

5.1.1. storage.cfgの編集

/etc/pve/storage.cfgに以下を追加します。

lvm: iSCSI-LVM
        vgname iSCSI-LVM-VG
        base TrueNAS:0.0.0.scsi-xxxxx
        content images,rootdir
        saferemove 0
        shared 1
        snapshot-as-volume-chain 1

設定パラメータの説明

snapshot-as-volume-chain 1: Snapshot as Volume Chain方式を有効化
saferemove 0: ゼロクリア処理を無効化(単一テナント環境向け最適化)

5.1.2. WebUIでの確認

Datacenter → Storage → iSCSI-LVM → Edit → Advanced にて、「Enable Snapshots as Volume Chains (Technology Preview)」がチェックされていることを確認します。

5.2. ファイルI/O性能測定結果

8.4系と同じ測定方法(104,857ファイル、10GB)で検証しました。

5.2.1. ファイル作成性能

スナップショット数	ファイル作成速度（ファイル/秒）	作成時間	対ベースライン比
0個(ベースライン)	11,288.2 ファイル/秒	9.29秒	-
1個	11,928.8 ファイル/秒	8.79秒	1.06倍
2個	10,928.6 ファイル/秒	9.59秒	0.97倍

スナップショット1個時に性能が微増しています。これは測定誤差の範囲とも考えられますが、少なくとも性能劣化がほぼ発生していないことを示しています。

5.2.2. システムリソース使用状況

項目	0個	1個	2個
CPU使用率(平均)	2.56%	5.15%	5.19%
メモリ使用量	1.11GB	1.30GB	1.40GB
Write IOPS(平均)	1,457	3,617	3,538
I/Oレイテンシ(平均)	11.3ms	23.7ms	24.6ms
ディスク書き込み(平均)	108MB/s	268MB/s	261MB/s
Load Average(平均)	0.60	0.94	1.09

注目すべき点

I/Oレイテンシがスナップショット使用時でも20ms台に抑制
Write IOPSがスナップショット使用時に増加
Load Averageの増加が軽微

6. 性能比較

8.4系（従来のLVMスナップショット方式）と9.0系（Snapshot as Volume Chain方式）の性能を、スナップショット操作とファイルI/O性能の両面から比較します。

6.1. ファイルI/O性能の比較

6.1.1. ファイル作成速度

スナップショット数	8.4系	9.0系	9.0系の改善率
0個（ベースライン）	9,236.5 ファイル/秒	11,288.2 ファイル/秒	1.22倍
1個	313.5 ファイル/秒	11,928.8 ファイル/秒	38.10倍
2個	199.2 ファイル/秒	10,928.6 ファイル/秒	54.88倍

8.4系の特徴:

スナップショット1個で約29.5倍の性能劣化（9,236.5 → 313.5）
スナップショット2個で約46.4倍の性能劣化（9,236.5 → 199.2）
スナップショット数に比例して劣化が深刻化
CoW処理によるオーバーヘッドの影響が顕著

9.0系の特徴:

ファイル作成速度の低下がないことから、スナップショット有無による性能低下がほぼない
ファイル作成速度は8.4系と比較して38-55倍に改善

6.1.2. I/Oレイテンシ

スナップショット数	8.4系	9.0系	9.0系の改善率
0個	22.5 ms	11.3 ms	約2倍改善
1個	209.2 ms	23.7 ms	8.8倍改善
2個	309.9 ms	24.6 ms	12.6倍改善

8.4系の特徴:

スナップショット使用時に大幅なレイテンシ悪化
実運用に耐えられないレベルの遅延

9.0系の特徴:

スナップショット使用時でもレイテンシは約2倍程度に抑制
8.4系と比較して大幅なレイテンシ改善

6.1.3. Write IOPS

スナップショット数	8.4系 Write IOPS	9.0系 Write IOPS
0個	3,675	1,457
1個	1,709	3,617
2個	1,324	3,538

8.4系の特徴:

スナップショット0個時のIOPSが最も高い（3,675）
スナップショット数増加に伴いIOPSが減少

9.0系の特徴:

ベースライン（0個）のIOPSが8.4系より低い（1,457）
スナップショット1個、2個時のIOPSは8.4系を大幅に上回る
スナップショット数増加に伴うIOPSの低下はほぼ見られない

7. 運用上の考慮事項

7.1. 容量設計

Snapshot as Volume Chain方式でも、スナップショット作成時に元ディスクサイズ分の空き容量が必要です。

7.1.1. 推奨容量計算式

推奨VG容量 = ディスクサイズ × (計画スナップショット数 + 1) × 1.5

計算例

ディスクサイズ: 100GB
計画スナップショット数: 2個
推奨VG容量: 100GB × (2 + 1) × 1.5 = 450GB以上

7.1.2. 容量不足時の挙動

容量不足の場合、スナップショット作成は失敗し、自動的にcleanup処理が実行されます。

lvcreate 'iSCSI-LVM-VG/vm-105-disk-0.qcow2' error: 
  Volume group "iSCSI-LVM-VG" has insufficient free space
snapshot create failed: starting cleanup

7.2. 最適化設定(saferemove)

7.2.1. 単一テナント環境向け設定

saferemove 0

削除時のゼロクリア処理を無効化します。

効果: 98%の処理時間短縮(102秒 → 1.8秒)
リスク: 削除データが物理的に残存
推奨環境: 単一組織・単一テナント環境

7.2.2. セキュリティ重視環境向け設定

saferemove 1
saferemove_throughput 50M

ゼロクリア処理速度を高速化（デフォルト10M）します。

効果: 70%の処理時間短縮(102秒 → 30秒)
セキュリティ: データ完全消去を維持
推奨環境: マルチテナント環境、コンプライアンス要件がある環境

8. 注意点

8.1. Technology Preview機能としての制約

Technology Preview機能であることに伴い、以下のリスクを理解する必要があります。

8.1.1. 理解すべきリスク

開発段階の機能であり、予期しない不具合が存在する可能性
今後のバージョンでの仕様変更の可能性
正式版リリースまでの期間は未定

8.2. 容量に関する制限事項

8.2.1. スナップショット作成時の空き容量要件

作成時に元ディスクサイズ分の空き容量が必須
容量不足時はエラーで作成失敗
計画的な容量設計が必要

8.2.2. スナップショット容量の設計

スナップショット自体のサイズは、元ボリュームと同じサイズで作成されます。従来のLVMスナップショットのように、変更差分のみを保持するサイズ指定はできません。

8.3. セキュリティ上の考慮点

8.3.1. saferemove 0設定のリスク

削除データが物理的に残存します。

許容可能な環境: 単一組織・単一テナント
不適切な環境: マルチテナント、コンプライアンス要件厳格
推奨対応: 環境に応じてsaferemove 1またはsaferemove_throughputを使用

8.4. 既存環境への適用制限

8.4.1. 新規VM作成時のみ適用

Snapshot as Volume Chain方式は、設定有効化後に作成する新規VMのみに適用されます。

8.4.2. 既存VMへの適用方法

既存VMにこの機能を適用するには、VMの再作成が必要です。

既存VMのバックアップ取得
VMの削除
Snapshot as Volume Chain有効化
バックアップからのリストア

注意: ダウンタイムが発生するため、計画的な実施が必要です。

9. まとめ

9.1. 8.4系から9.0系への進化

Proxmox VE 8.4系では、LVMスナップショットは「WebUIから利用できない」機能でした。筆者がサポート外の手動操作で検証した結果、29-46倍という性能劣化が確認され、WebUIで利用できない状態になっていたことには合理性があると考えられます。

Proxmox VE 9.0系では、Snapshot as Volume Chain方式という新技術により、この問題が改善されました。公式サポート機能(Technology Preview)として提供され、WebUIから簡単に使用できるようになったことは、大きな進化です。

9.2. 性能改善効果の総括

本検証により、以下の改善効果が定量的に確認されました。

ファイル作成性能: 38-55倍の改善
I/Oレイテンシ: 8.8-12.6倍の改善
スナップショット数増加による性能劣化: 8.4系は最大46倍劣化 → 9.0系はほぼ劣化なし（±3%）

8.4系で実運用に適さなかった機能が、9.0系で実運用可能なレベルに到達しました。

9.3. Proxmox VE 9.1での状況

2025年11月19日にリリースされたProxmox VE 9.1においても、Snapshot as Volume Chain機能は引き続きTechnology Previewとして位置づけられています。

9.1での主な改善点

TPMステートのスナップショット対応: TPMを使用するVMのオフラインスナップショット取得が可能に
バグ修正: ディスク移動後のスナップショット失敗、スナップショットからのVM複製失敗、共有LVMストレージでのクラスタロック問題など
運用上の改善: qcow2イメージが存在する場合にvolume-chain snapshotsの無効化を禁止
性能改善: より高速なblkdiscardを使用したボリューム削除処理

Technology Preview継続の意味

9.0系での検証結果は良好でしたが、9.1でも正式版機能としてはリリースされていません。コミュニティフォーラムでは削除時のバグなども報告されており、実運用導入には引き続き慎重な判断が必要です。

9.4. 今後の展望

Proxmox VE 9.x系での正式版化、あるいは10.x系でのさらなる改善が期待されます。現時点では検証環境での評価を推奨しますが、将来的にはiSCSI/FC環境でのスナップショット運用が標準的な選択肢となる可能性があります。

8.4系で筆者が実施したサポート外検証から、9.0系での公式サポート機能への進化は、Proxmox VEの技術的成熟を示す好例と言えます。

10. 参考情報

10.1. 公式ドキュメント

11. 商標について

本記事で使用している以下の名称は、各社の商標または登録商標です。

Proxmox、Proxmox VEは、Proxmox Server Solutions GmbHの商標です。
Red Hat、Red Hat Enterprise Linux、RHELは、Red Hat, Inc.の米国およびその他の地域における登録商標または商標です。
TrueNASは、iXsystems, Inc.の商標です。
Intel、Intel Xeonは、Intel Corporationまたはその子会社の商標です。
AMD、AMD Ryzenは、Advanced Micro Devices, Inc.の商標です。
その他、本記事中に記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。