生の仮想マシン ディスク イメージ (kvm) のサイズを縮小するにはどうすればよいですか?

Question

たとえば、linux-vm-image.rawサイズが 10 GB だとします。内部には、etx4ボリューム全体に広がるプライマリ パーティション (GPT ではなく、「従来の」MS-DOS のようなパーティション テーブルを使用) (LVM は使用されていません) が 1 つあります。そのパーティションに割り当てられる実際のデータは、たとえば 3 GB です。

このイメージは、何らかの仮想化環境 (私の場合は kvm+OpenStack) で使用するために用意されており、このイメージから作成された VM は、ユーザーの選択に応じて、ターゲットの仮想ディスク サイズに合わせてサイズが変更されます。そのため、そのディスク イメージ内に空きディスク領域を保持する必要はありません。

この生のディスク イメージのサイズを最小限 (10 GB から約 3 GB) に縮小するにはどうすればよいですか?

があるいくつかの 説明書ディスク イメージの場合、イメージのみqcow2を使用する必要があります。、、その他は使用できません。rawqcowOVF

私の推測では、

• このイメージをブロックデバイスとしてどこかにマウントする
• ext4 パーティション内のすべてのファイルをその「先頭」に移動するためのメンテナンスを実行します。言い換えると、空き領域のデフラグを実行します。
• イメージをアンマウントする
• ファイルシステムのサイズをイメージに縮小する（内部のデータのサイズと一致させるため）
• イメージのサイズを縮小する（イメージ内のファイルシステムのサイズと一致するように）
• 新しいパーティションサイズに合わせてイメージのパーティションテーブルを更新します

でも、自転車を発明しようとは思わないのですか? 私が望むことを実行するには、1 行のコマンドや特別なソフトウェアがあるのでしょうか?

Answer 1

生の画像は、実際にはサイズ変更に適していません。ただし、zerofree(マウントされていない) ファイルシステムで試してから、結果の画像ファイルを圧縮することはできます。

また、ターゲット環境が圧縮されたディスク イメージを可能にする OVF コンテナー形式をサポートしているかどうかも確認してください (zerofree は引き続き適用されます)。

Answer 2

正解です。ブロック デバイスとしてマウント (ループ マウント) できる場合は、おそらく gparted で動作させることができるでしょう。

gparted は、必要な作業の大部分を実行します:
1. FS データをパーティションの先頭に移動する (FS を縮小する)
2. パーティションを縮小し、パーティション テーブルを調整する
3. 更新されたパーティション テーブルを印刷すると、残りの「ディスク」サイズがわかる場合もあります (最後のパーティションの最後のセクターなど)。

これが難しい部分です。その後、マウントを解除します。「ディスク」の正確なサイズを手動で計算する必要があるかもしれませんが、その後は、ファイルを単純に切り捨てるだけで済みます。

更新: パーティション テーブルが MBR タイプであれば問題ありません。GPT の場合、ディスクの最後にミラー コピーがあります。そのため、gparted は十分にスマートではない可能性があるので注意してください (raw イメージを直接渡すことができる場合を除く)。問題がある場合は、切り捨て後の手順として gdisk を検討してください。いくつかの追加ブロックで切り捨て、gdisk/equiv でミラー コピーを再構築します (おそらく 2 回目のループ マウントが必要になります)。