web-dev-qa-db-ja.com

kvm / vmbuilderパーティションが本来よりも小さく、論理ボリュームの10％が常に割り当てられていない

Vmbuilderツールを使用して、ubuntuホストシステム上にKVM仮想マシンを作成します。 vmごとに、vmのパーティションサイズが定義されているvmbuilder.partitionsテキストファイルを設定します。

単純な：

root 100000
swap 4000

次に、定義されたすべてのパーティションのサイズとまったく同じサイズのvm用の新しい論理ボリュームを作成します。 （この例では、lvcreate -L 104G ...を実行します）

その結果、LVのサイズは正確に104 GiBになります。しかし、私の100 G（i？）Bルートパーティションは、93.13 GiBしか埋めていません。そして、約3.72GiBを交換します。 LVには約7 GiBの未割り当て領域があります。

これは非常に奇妙なことです。vmbuilder.partitionsの数を1024バイト/メガバイトで計算しても、ルートパーティションは約93ではなく97.65 GiBである必要があります。また、スワップは約3.9 GiBである必要があります。 3.72。 （残念ながら、これらの数値はスケールアップします。1TBの定義では、976ではなく約930 GiBしかありません。）

これは、経験則による推定バイト数をLVから手動で削除することで修正できます。しかし、私は最初から正気の価値を持ちたいと思っています。また、すべてのVMでスペースの10％が割り当てられていないことは、明らかに受け入れられません。

誰かがこれの背後にある論理を知っていますか？どうもありがとう。

kvm-virtualizationlvmpartitionvmbuilder
2
Karma Fusebox

まあ、本当の答えが見つかるまで、gpartedのLiveCDを使って次の回避策に固執します。結局のところ、パーティションはLV自体に触れることなく簡単に修正できます。 LVM/libvirt/KVM/QEMUコンボを使用する場合は、以下を使用できます。

  • gparted LiveCD-isoを読み取り可能な場所に配置します（つまり、/ rootではありません）
  • virsh edit <vmname> 変化する <boot dev="hd" />から<boot dev="cdrom" />
  • 他のディスクブロックの横に追加します。

<disk type='file' device='cdrom'></ code>
<driver name='qemu' type='raw'/></ code>
<source file='/some/vm-readable/path/gparted-live-0.14.0-1.iso'/></ code>
<target dev='hdc' bus='ide'/></ code>
<readonly/></ code>
<address type='drive' controller='0' bus='1' unit='0'/></ code>
</disk></ code>

  • vmを再定義して再起動し、VNC経由で接続します（たとえば、virt-viewerを使用）

Gparted GUIを使用すると、パーティションをドラッグアンドドロップして、LVの最後のバイトをすべて埋めることができます。

VMのブートデバイスを「hd」に戻すことを忘れないでください。再定義して再起動し、パーティションのサイズに満足してください。

0
Karma Fusebox