LVMパーティションは仮想マシンイメージで使用する必要がありますか？
VMイメージ（たとえば、KVMイメージ））を作成する場合、パーティションにLVMを使用する必要がありますか？たとえば、マウントしたい場合、複雑さが増すようですイメージにLVMパーティションがある場合、ホスト内のqcow2イメージ。
一方、VMイメージでは、LVMパーティションの利点はそれほど重要ではないようです。VMオフラインにし、物理システムよりもパーティションのサイズを変更します。
"場合によります。"
制御している環境（vmwareまたはkvmなど）を使用していて、ディスクパフォーマンスQoSについて独自に決定できる場合は、VM内でLVMを使用しないことをお勧めします。ハイパーバイザーレベルでは得られなかったほどの柔軟性は得られません。
ハイパーバイザーはこれらのタスクをすでに効果的に実行していることを覚えておいてください。ファイルシステムのサイズを任意に変更できるようにしたい場合（すばらしいアイデア）、ファイルシステムごとに個別の仮想ディスクを作成するだけです。
この道を行くとき、あなたが考えるかもしれない一つのこと。この方法で仮想ディスクにパーティションを配置する必要は必ずしもありません。たとえば、/homeの仮想ディスクを作成できます。それはあなたのVMの中の/dev/vdcです。ファイルシステムを作成するときは、パーティションを指定する代わりに、mke2fs -j /dev/vdcのようなことを行ってください。
これはすばらしいアイデアですが、...ほとんどのツール（およびあなたの後を追う他の管理者）は、すべてのディスクにパーティションが表示されることを期待しています。私はディスクに単一のパーティションを置くだけでそれで完了することをお勧めします。ただし、ファイルシステムのサイズを変更する場合は、もう1つ手順が必要です。そして、パーティションを適切に調整することを忘れないでください-最初のパーティションを1MBから開始するのが良い目安です。
つまり、ハイパーバイザーレベルでこれをすべて実行すると、おそらくVMパーティションのサイズを変更する必要があります。LVMを使用すると、仮想ディスクをホットアドできるようになります（ハイパーバイザー/ OSの組み合わせによってこれが可能になり、再起動せずにファイルシステムを拡張できます。
一方、クラウドプロバイダーを使用している場合は、より微妙です。
AzureやGCP、その他の小さなプレーヤーについてはあまり知りませんので、私はそれを手伝うことができません。
AWSを使用すると、上記の私のアドバイスに従うことができ、たいていは問題ありません。 EBSボリューム（仮想ディスク）のサイズをその場で増やしたり、パーティションのサイズを変更したりできます（現在）。
ただし、一般的なケースでは、すべてを1つの大きなEBSボリュームに配置し、LVM（または、おそらく単純なパーティション）を使用することは理にかなっています。 Amazonでは、各ボリュームにIOPS制限を設けています。デフォルトでは、この制限はボリュームのサイズに比例します。たとえば、gp2ボリュームの場合、GiB（最小100 IOPS）ごとに3 IOPSを取得します。 https://docs.aws.Amazon.com/AWSEC2/を参照） latest/UserGuide/EBSVolumeTypes.html
ほとんどのワークロードでは、現時点での必要性に応じて、使用可能なすべてのIOPSを任意のファイルシステムで使用できるようにする必要があります。したがって、1つの大きなEBSボリュームを作成し、すべてのIOPSを1つのバケットにまとめ、それを分割/ LVMすることは理にかなっています。
例：
独立したファイルシステム/スワップ領域を持つ3つのディスク、サイズはそれぞれ100GB。それぞれ300 IOPSを取得します。パフォーマンスは、各ディスクで300 IOPSに制限されています。
1つのディスク、サイズは300GB。それぞれ100 GBのディスク上のLVMパーティション。ディスクは900 IOPSを取得します。どのパーティションでも、900 IOPSをすべて使用できます。
論理ボリュームは、オンザフライで作成、サイズ変更、削除が簡単です。
「to LVM or not」の質問には常に同じ答えがあります。それは依存します:)
ディスクレベル、パーティションレベルで柔軟性が必要な場合は、理にかなっています。
LVMが提供する柔軟性が必要ない場合、または他のL-VM機能を利用したくない場合は、あまり意味がありません LVM機能
Virt-serverから簡単にアクセスできないため、実際にはLVを使用するのが好きです。したがって、これらのファイルは偶然に簡単に破壊/移動することはできません。
LVの他の重要な機能：
- スナップショットを作成できます
- ディスクを分析できますIO LVに基づいて（
iostat） - サイズ変更が簡単
- スナップショットを使用すると、実行中のシステムの一貫したクローンを作成できます
複雑さを減らすために、LVを（パーティションとしてではなく）ディスクとして使用します。欠点は、「ディスク」の最後のパーティションのサイズを簡単にしか変更できないことです。ただし、私の標準のVM-disk-layoutはそれを考慮に入れています（したがって、最後のパーティションには重要なアプリケーションデータが含まれています）。
柔軟性に加えて、LVMベースのVMイメージは、ファイルシステムを介してアクセスされないため、オーバーヘッドが少なくなる可能性があります。一方、イメージの移動が簡単になります。ファイルを使用します。不可能ではありませんが、もう少し複雑です
私自身の経験....
Ext4ファイルシステムのlvm2で論理ボリューム（lv）を使用したいと思いました。ディスクとしてではなく、単にfsのパーティション化されていないrawディスクとして。
私が見つけたのは、VMの起動がinitrdステージで停止することです。コメントした場合、/etc/fstabエントリ、マシンが起動します。 /etc/fstabコメントされたエントリは、私が共存して満足した解決策ではありませんでした。そこで、通常のディスクイメージ（まだ論理ボリューム）を作成し、fdiskを使用して1つのパーティションでパーティション化し、その上にファイルシステムを作成しました。これ以上の問題はありません。
私の関連するマウント/etc/fstabはUUIDを使用していました。
私はファイルまたはファイルシステムの使用を考えましたが、それを拒否しました。
私の場合、私はDebian Jessieベースのシステムを使用しています Devuan
ここでの他の良い答えに加えて、VM内でLVMを使用する本当に良い理由は、LVMを実際に試して実際に体験するためのテスト環境が欲しいということです。
さまざまなHOWTOやチュートリアルを体験し、一般的な（それほど一般的ではない）LVM管理タスクを練習し、さまざまな障害シナリオを設定し、それらの対処方法を学ぶことができます。
つまり、自己学習補助として。
私は実際にはハイパーバイザーレベルのバッキングストレージにLVMのみを使用しています。イメージファイルは鳥用です。ゲストレベルでも使用することをお勧めします。異なるストレージソースをプールするメリットはなく、利用可能な総ディスク容量を増やすのも簡単ではありませんが（ハイパーバイザーが提示するサイズを変更することで同じように簡単に取得できるため）、場合によっては、1つのファイルシステムに割り当てすぎます。たとえば、/ optから1ギガを取り出して/ varに渡す簡単な方法が必要な場合があります（たとえば）。 VM自体の内部で通常のパーティションを実行している場合、サイズ変更の側面がそれだけ難しくなります。
編集：以下は当てはまりません。 VMディスクイメージに対してLVMによって提供されるシンプロビジョニングを使用することの価値は、おそらく状況に応じて異なります。
ラップトップで開発VMを実行していますか？そうすれば、おそらくQCow2の方が良いでしょう。
複数のディスクにわたって膨大な量のストレージを使用する可能性のあるVMのファームを管理していますか？ LVMは、おそらくそのストレージを管理するための良い方法です。
lvmを使用する1つの理由notは、lvmを使用してストレージをオーバーコミットできないためです。 100 GBのストレージを持つ10個のVMを作成する場合、たとえ10個のVMのうち9個がファイルシステムの20 GBしか使用しない場合でも、実際のディスクは1000 GB必要です。スパースディスクイメージまたはqcow2形式のイメージは、ゲストが実際に使用するストレージのみを割り当てる必要があることを意味します。
これが実際に役立つかどうかは、ストレージから何が必要かによって異なります。