web-dev-qa-db-ja.com

KVM + LVM：LVMをどこに置くか？

こんにちは、私は現在libvirt + kvmを使用して新しいサーバーをセットアップしています。その後、このサーバー上で約5台の仮想マシンが実行されているはずです（+いくつかのテストマシン）。

ストレージは、LVMを使用してセットアップされたraid-5デバイスに配置されます。 KVMは、一部のLVM-論理ボリュームで実行されるようになりました。

問題は次のとおりです。仮想マシン内でlvmを再度（2回目）使用してスペースを分割することの欠点はありますか？つまり、次のようになります：ハードディスク-> RaidControler->物理サーバーのLVM->各VM内の1つの論理ボリュームVM->各VM内のLVM VM->各VM内の複数の論理ボリューム。

仮想マシン内に動的パーティションが必要な場合、他に可能性はありますか？

ありがとう

partitionlvmkvm-virtualization
4
theomega

LVMのパフォーマンスのオーバーヘッドは些細なものであり、2回使用してもそれは変わりません。 RAID-5デバイスは、lvmよりもはるかに大きな影響を及ぼします。

4
cagenut

http://hyperthese.net/post/kvmized-debian-on-lvm/ のブログ記事では、ホスト（物理サーバー）上にLVM論理ボリュームを作成し、それら上に直接ファイルシステムを作成することを提案しています。パーティションを作成せずに、仮想マシンを作成する前に。

私はそれを試してみましたが、簡単に言えば、うまくいったようで、LVとその上のファイルシステムを拡大することができました。

これが長い話です、つまり私がしたこと：

ホスト（Ubuntu 10.04を実行）上に、VMのルート、変数、およびスワップ用のLVM論理ボリュームを作成しました。

me@Host:~$ Sudo lvcreate -L4G -n test-root vg1
me@Host:~$ Sudo lvcreate -L20G -n test-var vg1
me@Host:~$ Sudo lvcreate -L2G -n test-swap vg1

作成されたファイルシステムとLVでのスワップ：

me@Host:~$ Sudo mkfs.ext3 /dev/mapper/vg1-test--root
me@Host:~$ Sudo mkfs.ext3 /dev/mapper/vg1-test--var
me@Host:~$ Sudo mkswap -f /dev/mapper/vg1-test--swap

VMを作成しました：

me@Host:~$ Sudo virt-install --name=test --ram=2048 --os-type=linux --os-variant=ubuntulucid --cdrom=ubuntu-server-10.04-lts-64bit.iso --disk path=/dev/mapper/vg1-test--root --disk path=/dev/mapper/vg1-test--var --disk path=/dev/mapper/vg1-test--swap --network bridge=br0 --vnc --noautoconsole

次に、virt-viewerを使用して新しいVMに接続し、Ubuntuインストーラーが待機していました。「最小限の仮想マシンをインストールする」（F4キー）モードを選択しました。

パーティショニングフェーズでは、手動パーティショニングを選択しました。インストーラーは仮想ディスクvda、vdb、vdcを検出し、最初の2つがext3で、最後がスワップであると認識しました。私はext3パーティションを選択し、それらをext3パーティションとして使用するように指示しました（デフォルトは「使用しない」でした）。「いいえ、既存のデータを保持します」とマウントポイントを最初のパーティションには/、2番目のパーティションには/ varとして使用します。スワップはデフォルトで正しく設定されていました。次に、最初のディスクにgrubをインストールすることにしました。

VMは正常に稼働しています。Fdiskはvdaに空のパーティションテーブルがあることを示し、vdbとvdcに有効なパーティションテーブルがないことを示しています。あるかどうかはわかりません。パーティションテーブルは問題です。それについては https://unix.stackexchange.com/questions/5162/how-to-install-grub-to-a-whole-ext4-disk-without-）でいくつかの議論があります。パーティションテーブル 。

最後に、varディスクのサイズを変更してみました。まず、ホスト上で：

me@Host:~$ Sudo lvextend -L24G /dev/vg1/test-var

次に、VMを再起動し、VM上のファイルシステムのサイズを変更しました。

me@test:~$ Sudo resize2fs /dev/vdb

そしてそれはそれをうまくサイズ変更しました。

これが良い方法かどうかはわかりませんが、今のところうまくいくようです。コメントはありますか？

2
jarnoan

2回目のLVMの使用はパフォーマンスには良くないと思いますが、ネットワークファイルシステムを除いて、動的パーティションを使用した別の安定したソリューションを考えることはできません（Fuseまたはbtrfsでzfsを試すことはできますが生産準備ができていません）。

LVMをVM内に保持する場合は、各VMのパーティションごとにホスト上にLVを作成できます。

0
Wiflye81

一般に、より多くの部品を使用することは、より多くの破損を意味します。 LVMが2回必要にならないように、何をしているのかを再考することをお勧めします。おそらく、KVMの代わりにOpenVZのようなものを使用します。OpenVZは、仮想パーティションのサイズ変更をすばやくオンザフライでサポートします。

0
davr