仮想マシンイメージでLVMパーティションを使用する必要がありますか？

VMイメージ（KVMイメージなど）を作成するときに、パーティションにLVMを使用する必要がありますか？たとえば、イメージにLVMパーティションがある場合、ホストにqcow2イメージをマウントする場合、複雑さが増すようです。

一方で、VMをオフラインにしてパーティションのサイズを変更する方が物理システムよりもはるかに簡単であるため、VMイメージではLVMパーティションの利点はそれほど重要ではないようです。

"場合によります。"

制御する環境（vmwareまたはkvmなど）で、ディスクパフォ​​ーマンスQoSについて独自の決定を下せる場合は、VM内でLVMを使用しないことをお勧めします。ハイパーバイザーレベルでは得られなかった柔軟性は得られません。

ハイパーバイザーはすでにこれらのタスクを効果的に実行していることを忘れないでください。ファイルシステムのサイズを任意に変更できるようにしたい場合（良いアイデア）、ファイルシステムごとに個別の仮想ディスクを作成してください。

あなたがこの道を下るとき、あなたが考えるかもしれない一つのこと。このように仮想ディスクにパーティションを配置する必要はありません。たとえば、次の仮想ディスクを作成できます/home。それは/dev/vdcあなたのVM内で。ファイルシステムを作成するときmke2fs -j /dev/vdcは、パーティションを指定する代わりに次のようなことをしてください。

これは良い考えですが、...ほとんどのツール（およびあなたの後に来る他の管理者）は、すべてのディスク上のパーティションを表示することを期待します。ディスクに単一のパーティションを配置して、それで作業を完了することをお勧めします。ただし、ファイルシステムのサイズを変更するときはもう1ステップ必要です。また、パーティションを適切に配置することを忘れないでください。最初のパーティションを1MBから開始することをお勧めします。

つまり、すべてをハイパーバイザーレベルで実行すると、おそらくパーティションサイズを変更するためにVMを再起動する必要があります。LVMを使用すると、仮想ディスクをホットアドでき（ハイパーバイザーとOSの組み合わせがこれを許可すると仮定）、再起動せずにファイルシステムを拡張できます。これは間違いなくプラスです。

一方、クラウドプロバイダーを使用している場合は、より微妙です。

私は、Azure、GCP、または他の小さなプレーヤーについてあまり知りませんので、そこでは助けられません。

AWSを使用すると、上記の私のアドバイスに従うことができ、多くの場合は問題ありません。EBSボリューム（仮想ディスク）のサイズをその場で（今）増やしたり、パーティションのサイズを変更したりできます。

ただし、一般的なケースでは、すべてを単一の大きなEBSボリュームに配置し、LVM（またはプレーンパーティション）を使用するのが理にかなっている場合があります。Amazonでは、各ボリュームにIOPS制限を設けています。デフォルトでは、この制限はボリュームのサイズに合わせて調整されます。たとえば、gp2ボリュームの場合、GiBあたり3 IOPSを取得します（最低100 IOPS）。https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.htmlを参照してください

ほとんどのワークロードでは、現在のニーズに応じて、利用可能なすべてのIOPSを任意のファイルシステムで利用できるようにする必要があります。したがって、1つの大きなEBSボリュームを作成し、すべてのIOPSを1つのバケットに入れて、パーティション化/ LVMすることは理にかなっています。

例：

各サイズが100GBの独立したファイルシステム/スワップ領域を持つ3つのディスク。それぞれが300 IOPSを取得します。パフォーマンスは、各ディスクで300 IOPSに制限されています。

1つのディスク、300GBのサイズ。それぞれ100GBのディスク上のLVMパーティション。ディスクは900 IOPSを取得します。どのパーティションでも900 IOPSをすべて使用できます。

論理ボリュームは、その場で簡単に作成、サイズ変更、削除できます。
「to LVM or not」の質問には常に同じ答えがあり、それは依存します :)
ディスク、パーティションレベルで柔軟性が必要な場合、それは理にかなっています。
LVMが提供する柔軟性を必要としない場合や、他のLVM機能を利用したくない場合は、あまり意味がありません。

LVはvirt-serverから簡単にアクセスできないため、実際にはLVを使用するのが好きです。したがって、これらのファイルは偶然簡単に破壊/移動することはできません。

LVのその他の重要な機能：

• スナップショットを作成できます
• LV（iostat）に基づいてディスクIOを分析できます
• サイズ変更が簡単
• スナップショットを使用することにより、実行中のシステムの一貫したクローンを作成できます

複雑さを軽減するために、LVを（パーティションとしてではなく）ディスクとして使用します。欠点は、「ディスク」の最後のパーティションのサイズを簡単に変更できることです-しかし、私の標準VMディスクレイアウトはそれを考慮します（したがって、最後のパーティションには重要なアプリケーションデータが含まれます）。

柔軟性に加えて、LVMベースのVMイメージはファイルシステムを介してアクセスされないため、潜在的にオーバーヘッドが少なくなります。一方、ファイルの場合のように、画像を簡単に移動する手段がなくなります。不可能ではありませんが、もう少し複雑です

私自身の経験....

ext4ファイルシステムには、lvm2で論理ボリューム（lv）を使用したかった。ディスクとしてではなく、単にfsのパーティション化されていないrawディスクとして。

私が見つけたのは、VMの起動がinitrdステージで停止することです。/etc/fstabエントリをコメントアウトすると、マシンが起動します。/etc/fstabエントリーにコメントを残しておくことは、私が一緒に暮らせることを嬉しかった解決策ではありませんでした。そこで、通常のディスクイメージ（まだ論理ボリューム）fdiskを作成し、それを使用して1つのパーティションでパーティション化し、その上にファイルシステムを作成しました。それ以上の問題はありません。

私の関連するマウントは/etc/fstabUUIDを使用していました。

私はファイルやファイルシステムを使うことを考えましたが、それに反対しました。

私の場合、Debian JessieベースのシステムDevuanを使用しています

実際、ハイパーバイザーレベルのバッキングストレージにはLVMのみを使用し、画像ファイルは鳥用です。ゲストレベルでも使用することをお勧めします。異なるストレージソースをプールすることから利益を得たり、利用可能なディスクスペースの合計を増やすことは簡単ではありません（ハイパーバイザーが提示するもののサイズを変更することで簡単に取得できるため）が、1つのファイルシステムに割り当てすぎる。/ optから1ギガを取得して/ varに渡す簡単な方法が必要な場合があります（たとえば）。VM自体の内部で通常のパーティションを作成している場合、サイズ変更の側面が非常に難しくなります。

ここでの他の良い答えに加えて、VM内でLVMを使用する唯一の本当に良い理由は、テスト環境で実験し、LVMで実際的な実践的な経験を得ることです。

さまざまなHOWTOとチュートリアルを読み、一般的な（あまり一般的ではない）LVM管理タスクを練習し、さまざまな障害シナリオを設定して、それらの対処方法を学ぶことができます。

すなわち、自己学習補助として。

編集：以下は当てはまりません。VMディスクイメージにLVMが提供するシンプロビジョニングを使用することの価値は、おそらく状況に応じたものです。

開発用VMをラップトップで実行していますか？QCow2を使用したほうがおそらく良いでしょう。

複数のディスクで膨大な量のストレージを使用する可能性があるVMのファームを管理しますか？LVMは、おそらくそのストレージを管理するための良い方法です。

lvmを使用しない理由の1つは、lvmを使用してストレージをオーバーコミットできないことです。100GBのストレージで10個のVMを作成する場合、10個のVMのうち9個が20 GBのファイルシステムしか使用しない場合でも、1000 GBの実際のディスクが必要です。スパースディスクイメージまたはqcow2形式のイメージは、ゲストが実際に使用するストレージのみを割り当てる必要があることを意味します。

これが実際に役立つかどうかは、ストレージに必要なものによって異なります。