プベスム(1)

多くのストレージと QEMU イメージフォーマットqcow2 はシンプロビジョニングをサポートしています。 シンプロビジョニングを有効にすると、ゲストシステムが実際に使用するブロックのみがストレージに書き込まれます。

例えば、32GBのハードディスクでVMを作成し、ゲストシステムOSをインストールした後、VMのルートファイルシステムに3GBのデータが含まれているとします。 この場合、ゲストVMが32GBのハードディスクを見ていたとしても、ストレージには3GBしか書き込まれません。このように、シンプロビジョニングでは、現在利用可能なストレージブロックよりも大きなディスクイメージを作成することができます。VMのために大きなディスクイメージを作成し、必要性が生じたときに、VMのファイルシステムのサイズを変更することなく、ストレージにディスクを追加することができます。

スナップショット」機能を持つすべてのストレージタイプは、シンプロビジョニングもサポートしています。

各ストレージプールは<type>を持ち、<STORAGE_ID>で一意に識別されます。プール構成は次のようになります：

<type>: <STORAGE_ID>行がプール定義を開始し、その後にプロパティのリストが続きます。ほとんどのプロパティは値を必要とします。いくつかのプロパティは、妥当なデフォルトを持ち、その場合、値を省略することができます。

具体的には、インストール後のデフォルトのストレージ構成を見てください。local という名前の特別なローカルストレージプールが 1 つ含まれ、これは/var/lib/vzディレクトリを参照し、常に使用可能です。Proxmox VEのインストーラは、インストール時に選択したストレージタイプに応じて、追加のストレージエントリを作成します。

いくつかのストレージ特性は、異なるストレージタイプ間で共通です。

イメージ・タイプのボリュームには所有関係が存在します。このようなボリュームは、それぞれVMまたはコンテナによって所有されます。例えば、ボリュームlocal:230/example-image.rawは VM 230 が所有します。ほとんどのストレージバックエンドは、この所有者情報をボリューム名にエンコードします。

VMまたはコンテナを削除すると、そのVMまたはコンテナが所有する関連ボリュームもすべて削除されます。

ストレージプールの追加

ストレージプールの無効化

ストレージプールの有効化

ストレージオプションの変更/設定

ストレージプールを削除します。これはいかなるデータも削除しませんし、何かを切断したりアンマウントしたりもしません。ストレージ構成を削除するだけです。

ボリュームの割り当て

ローカル・ストレージに4Gボリュームを割り当てます。<name>に空の文字列を渡すと、名前が自動生成されます。

全巻無料

保管状況一覧

収納内容一覧

VMID によって割り当てられたボリュームの一覧

リストisoイメージ

リスト・コンテナ・テンプレート

ボリュームのファイルシステムのパスを表示

ボリュームlocal:103/vm-103-disk-0.qcow2をファイルターゲットにエクスポートします。 これは主にpvesmインポートで内部的に使用されます。 ストリーム形式qcow2+sizeはqcow2形式とは異なるため、エクスポートしたファイルをVMにアタッチすることはできません。 これは他の形式でも同様です。

このバックエンドは、一般的なストレージ・プロパティをすべてサポートしており、さらに 2 つのプロパティを追加しています。pathプロパティはディレクトリを指定するために使用します。これはファイルシステムの絶対パスである必要があります。

オプションのcontent-dirsプロパティでは、デフォルトのレイアウトを変更できます。このプロパティは、コンマで区切られた識別子のリストで構成されます：

vtypeはストレージに許可されるコンテンツ・タイプの1つで、pathはストレージのマウントポイントからの相対パスです。

上記の構成では、backup というストレージ・プールを定義しています。このプールは、VMごとに最大7つの通常バックアップ(keep-last=7)と3つの保護バックアップを保存するために使用できます。バックアップ・ファイルの実際のパスは、/mnt/backup/custom/backup/dir/... です。

このバックエンドは、VMイメージに対して明確に定義された命名スキームを使用します：

VM テンプレートを作成すると、すべての VM イメージの名前が変更され、読み取り専用になり、クローンのベースイメージとして使用できるようになります：

上述したように、ほとんどのファイルシステムはスナップショットをサポートしていません。この問題を回避するために、このバックエンドはqcow2内部のスナップショット機能を使うことができます。

クローンも同様です。バックエンドはqcow2のベースイメージ機能を使ってクローンを作成します。

以下のコマンドを使用して、ローカル・ストレージに4GBのイメージを割り当ててください：

実際のファイルシステムのパスは

で画像を削除できます：

バックエンドは、常に設定される共有フラグを除く、すべての一般的なストレージ・プロパティをサポートしています。さらに、以下のプロパティがNFSサーバの設定に使用されます：

NFSマウントオプションも設定できます：

NFSはスナップショットをサポートしていませんが、バックエンドはqcow2の機能を使ってスナップショットとクローンを実装しています。

でエクスポートされたNFS共有のリストを取得できます：

バックエンドは、常に設定される共有フラグを除く、すべての一般的なストレージプロパティをサポートしています。さらに、以下の CIFS 特別プロパティが使用可能です：

CIFSはストレージレベルでのスナップショットをサポートしていません。しかし、スナップショットやクローン機能を使用したい場合は、qcow2バッキングファイルを使用することができます。

でエクスポートされたCIFS共有のリストを取得できます：

そして、この共有をProxmox VEクラスタ全体のストレージとして追加します：

バックエンドは、常に設定される共有フラグを除く、すべての一般的なストレージプロパティを サポートしています。さらに、Proxmox Backup Serverには以下の特別なプロパティがあります：

Proxmox Backup Serverはブロックレベルまたはファイルレベルのバックアップのみをサポートします。Proxmox VEは仮想マシンにブロックレベル、コンテナにファイルレベルを使用します。

オプションとして、GCM モードで AES-256 によるクライアント側の暗号化を設定することができます。 暗号化は、Web インターフェース、またはencryption-keyオプション（上記参照）を使用して CLI で設定できます。キーは、root ユーザのみがアクセスできる/etc/pve/priv/storage/<STORAGE-ID>.enc ファイルに保存されます。

迅速な災害復旧のために、鍵は安全な場所に保管し、簡単にアクセスできるようにしておくことをお勧めします。そのため、すぐに復旧できるパスワード・マネージャー内に保管するのが最適です。このバックアップとして、キーをUSBフラッシュドライブに保存し、安全な場所に保管してください。こうすることで、どのシステムからも切り離された状態になりますが、それでも緊急時には簡単に復旧できます。最後に、最悪のシナリオに備えて、キーの紙コピーを安全な場所に保管しておくことも検討してください。paperkeyサブコマンドを使えば、QRコード化された鍵のバージョンを作成することができます。次のコマンドは、paperkeyコマンドの出力をテキストファイルに送信し、簡単に印刷できるようにします。

暗号化バックアップを行うすべてのクライアントが単一のパブリック・マスター・キーを使用するように設定すると、それ以降のすべての暗号化バックアップには、使用されたAES暗号化キーのRSA暗号化コピーが含まれます。対応するプライベート・マスター・キーは、クライアント・システムが利用できなくなった場合でも、AESキーの復元とバックアップの復号化を可能にします。

暗号化はクライアント側で管理されるため、暗号化されていないバックアップと暗号化されたバックアップが異なるキーで暗号化されていても、サーバ上の同じデータストアを使用することができます。ただし、異なるキーで暗号化されたバックアップ間の重複排除はできないため、データストアは別々に作成した方がよい場合が多いです。

そして、この共有をProxmox VEクラスタ全体のストレージとして追加します：

バックエンドはすべての一般的なストレージプロパティをサポートし、以下のGlusterFS固有のオプションを追加します：

ディレクトリのレイアウトとファイルの命名規則はdirバックエンドから継承しています。

ストレージはファイルレベルのインターフェイスを提供しますが、ネイティブのスナップショット/クローン実装はありません。

バックエンドは、一般的なストレージ・プロパティであるcontent、nodes、disableと、以下のZFS固有のプロパティをサポートしています：

バックエンドでは、VMイメージに以下のような命名スキームを使用します：

ZFSは、スナップショットとクローニングに関して、おそらく最も先進的なストレージタイプです。バックエンドは、VMイメージ（フォーマットraw）とコンテナデータ（フォーマットsubvol）の両方にZFSデータセットを使用します。ZFSプロパティは親データセットから継承されるので、親データセットにデフォルトを設定するだけです。

VMイメージを保存するために、追加のZFSファイルシステムを作成することをお勧めします：

新しく割り当てられたファイルシステムで圧縮を有効にするには：

で利用可能なZFSファイルシステムのリストを取得できます：

LVMバックエンドは、一般的なストレージ・プロパティであるcontent、nodes、disableと、以下のLVM固有のプロパティをサポートしています：

バックエンドは、基本的にZFSプールのバックエンドと同じ命名規則を使用します。

LVMは典型的なブロックストレージですが、このバックエンドはスナップショットとクローンをサポートしていません。残念ながら、通常のLVMスナップショットは、スナップショット時間中にボリュームグループ全体のすべての書き込みを妨害するため、かなり非効率的です。

大きな利点は、iSCSI LUNなどの共有ストレージの上で使用できることです。バックエンド自体が適切なクラスタ全体のロックを実装しています。

利用可能なボリュームグループを一覧表示します：

LVMシンバックエンドは、一般的なストレージプロパティであるcontent、nodes、disableと、以下のLVM固有のプロパティをサポートします：

バックエンドは、基本的にZFSプールのバックエンドと同じ命名規則を使用します。

LVM thinはブロックストレージですが、スナップショットやクローンを効率的にサポートします。新しいボリュームは自動的にゼロで初期化されます。

LVMシン・プールは複数のノードで共有できないため、ローカル・ストレージとしてのみ使用できます。

ボリュームグループpveで利用可能なLVMシンプールをリストします：

バックエンドは、一般的なストレージ・プロパティであるcontent、nodes、disable、および以下のiSCSI固有のプロパティをサポートしています：

iSCSIプロトコルは、データを割り当てたり削除したりするインターフェースを定義していません。代わりに、それはターゲット側で行われる必要があり、ベンダー固有です。ターゲットは単に番号付きLUNとしてエクスポートします。そのため、Proxmox VEのiSCSIボリューム名は、Linuxカーネルから見たLUNに関する情報をエンコードしているだけです。

iSCSIはブロック・レベル・タイプのストレージで、管理インターフェイスを提供しません。 そのため、通常は1つの大きなLUNをエクスポートし、そのLUNの上にLVMをセットアップするのが最善です。その後、LVMプラグインを使ってiSCSI LUN上のストレージを管理することができます。

リモートのiSCSIポータルをスキャンし、可能なターゲットのリストを返します：

ユーザーモード iSCSI バックエンドは、Open-iSCSI バックエンドと同じ設定オプションを使用します。

このバックエンドは、一般的なストレージプロパティであるnode、disable、contentと、以下のrbd固有のプロパティをサポートしています：

デフォルトで有効になっているcephx認証を使用する場合、外部のCephクラスタからキーリングを提供する必要があります。

CLIでストレージを構成するには、まず、キーリングを含むファイルを利用できるようにする必要があります。1つの方法は、外部CephクラスタからProxmox VEノードの1つにファイルを直接コピーすることです。次の例では、実行するノードの/rootディレクトリにコピーします：

次に、pvesmCLIツールを使用して外部RBDストレージを設定します。--keyringパラメータを使用し、コピーしたキーリング・ファイルへのパスを指定します。 たとえば、以下のようになります：

GUIで外部RBDストレージを設定する場合、キーリングをコピーして適切なフィールドに貼り付けることができます。

キーホルダーは

外部Cephストレージに接続しても、外部クラスタ上のconfig DBでクライアント固有のオプションを設定できるとは限りません。Cephキーリングの横にceph.confを追加して、ストレージのCephクライアント設定を変更できます。

ceph.confはストレージと同じ名前にする必要があります。

可能な設定については、RBD設定リファレンス
[RBD configuration referencehttps://docs.ceph.com/en/quincy/rbd/rbd-config-ref/]
を参照してください。

rbdバックエンドはブロックレベルのストレージで、完全なスナップショットとクローン機能を実装しています。

このバックエンドは、一般的なストレージプロパティのnodes、disable、contentのほか、以下のcephfs固有のプロパティもサポートしています：

デフォルトで有効になっているcephx認証を使用する場合は、外部のCephクラスタからシークレットを提供する必要があります。

CLIでストレージを設定するには、まず、シークレットを含むファイルを利用できるようにする必要があります。1つの方法は、外部CephクラスタからProxmox VEノードの1つにファイルを直接コピーすることです。次の例では、実行するノードの/rootディレクトリにコピーします：

次に、pvesmCLIツールを使用して外部RBDストレージを設定します。--keyringパラメータを使用し、コピーしたシークレットファイルへのパスを指定します。 たとえば、以下のようになります：

GUIで外部RBDストレージを設定する場合、該当するフィールドにシークレットをコピー&ペーストできます。

rbdバックエンドは[client.userid]セクションも含んでいるのとは対照的に、シークレットはキーそのものだけです。

秘密は

useridはクラスタにアクセスするように設定されているクライアントIDです。Cephユーザ管理の詳細については、Cephのドキュメントを参照してください。
[cephusermgmt]

cephfsバックエンドは、Cephクラスタ上のPOSIX準拠ファイルシステムです。

[^1]既知のバグは存在しませんが、スナップショットは十分なテストが行われていないため、安定性は保証されていません。

このバックエンドは、ディレクトリ・ストレージと同様に設定します。それ自身がマウントポイントでもないディレクトリを BTRFS ストレージとして追加する場合は、is_mountpointオプションで実際のマウントポイントを指定することを強くお勧めします。

たとえば、BTRFS ファイルシステムが/mnt/data2にマウントされ、そのpve-storage/サブディレクトリ（スナップショットである可能性があり、これを推奨）をdata2 というストレージプールとして追加する場合、次のエントリを使用できます：

サブボリュームまたはRAWファイルのスナップショットを作成する場合、スナップショットは、同じパスに@とスナップショット名を付けた読み取り専用のサブボリュームとして作成されます。

ZFS over iSCSI プラグインを使用するには、リモートマシン (ターゲット) が Proxmox VE ノードからのssh接続を受け付けるように設定する必要があります。Proxmox VEはターゲットに接続してZVOLを作成し、iSCSI経由でエクスポートします。 認証は/etc/pve/priv/zfs/<target_ip>_id_rsaに保存されたsshキー(パスワード保護なし)を介して行われます。

以下の手順でsshキーを作成し、IP 192.0.2.1のストレージマシンに配布します：

バックエンドは、一般的なストレージ・プロパティであるcontent、nodes、disable、および以下のZFS over ISCSI固有のプロパティをサポートします：

ZFS over iSCSIプラグインは、スナップショットが可能な共有ストレージを提供します。ZFSアプライアンスが導入における単一障害点にならないようにする必要があります。