Ubuntu 17.10を使用してHyper-Vで複数の仮想マシンを設定し、誤って設定されていることを発見しました。つまり、VHDXファイルのデフォルトのブロックサイズに設定されており、必要以上に多くのスペースを使用していました。 VHDHXのサイズが望むよりも大きい。一例では、約50GBのドライブがありましたが、データ容量は15GBしか含まれていませんでした。
より合理的な設定で新しいVHDHXファイルを作成し、ドライブのすべてのエントリを新しく作成されたドライブに複製しようとすると、いくつかの問題が発生します。既存のドライブは次のように2つのパーティションとして表示され、より大きなパーティションには2つの論理ボリューム（データ用の1つとスワップ用の1つ）があります。
このドライブを複製しようとしているドライブは30GBのVHDHXファイルになり、これを行う最善の方法についてのアドバイスが必要です。私は最初にddを試しましたが、ソースがターゲットよりも大きいため、エラーが発生しました。その後、gpartedを使用して大きなドライブのサイズを変更しようとしましたが、gpartedがLVMパーティションに空き領域がないものとして扱ったため、サイズ変更できませんでした。また、LVMパーティションのサイズを小さくしてgpartedを試しましたが、エラーが発生しました。 LVMパーティションのサイズを正常に縮小し、ddを使用してLVMボリュームを新しいドライブに作成した別のLVMボリュームに複製することができました。ただし、lvreduceを使用して元のパーティションのサイズを変更すると、データが連続せずドライブに分散されていると、データが切り捨てられる可能性があります。
私はこの分野に慣れていないので、何を見落としているのか、これを行うときに何を考慮する必要があるのかわかりませんが、基本的に新しいドライブに既存のドライブのすべての項目が含まれるようにするために必要な手順についてのガイドラインを探しています。その場合は起動できます。たとえば、lvreduceを使用して大容量ボリュームのサイズを必要なサイズに変更した場合、この操作の実行中に何も失わないことをどのように確認できますか？これは正しいアプローチですか？
これまでの私の計画は次のとおりです。
- この手順を実行するには、新しいUbuntu VMを作成してください。
- データをコピーする元のドライブ+新しいドライブを接続します。
- 元のドライブの論理ボリュームを縮小します。
- 新しいドライブに同じパーティションとボリュームを作成します。
- dd を使用して、論理ボリュームを新しいドライブの同等の論理ボリュームにコピーします。
これを行うより良い方法がありますか、それとも何かが欠けていますか？ /注意すべき落とし穴は？
答え1
誰もがこれを見つけて同じ問題が発生した場合、私に役立つ解決策は主に上記の解決策でした。次の例では、元のドライブには2つのパーティション、つまりブートパーティションと2つの論理ボリュームを持つデータパーティションがあり、ターゲットドライブは論理ボリュームを持たないブートパーティションとデータパーティションで始まります。
- 2つのディスクが接続されているVMを設定し、Linux Live CDを使用して起動します。
- ソースディスクでファイルシステムチェックを実行します
sudo e2fsck -f /dev/mapper/ubuntu--1704--base--vg-root。ボリューム名は出力で見つけることができます。sudo fdisk -l - 論理ボリュームのサイズを変更する前に、ファイルシステムを最小サイズに縮小してください。これは次の方法で行うことができます。
sudo resize2fs -M /dev/mapper/ubuntu--1704--base--vg-root - 論理ボリュームのサイズを目的のサイズ（この場合は28.5GiB）に調整します。
sudo lvreduce --resizefs -L 28.5G /dev/mapper/ubuntu--1704--base--vg-root - 新しいドライブで同じ名前を使用するため、既存のドライブのボリュームグループの名前を変更します。
sudo vgrename ubuntu-1704-base-vg ubuntu-1704-base-vg-2 - 新しい物理ボリュームを作成します。
sudo pvcreate /dev/sda2 - ソースドライブの元のボリュームグループから取得した名前を使用して、新しいボリュームグループを作成します。
sudo vgcreate ubuntu-1704-base-vg /dev/sda2 - 古いドライブの論理ボリュームと一致するように、新しいドライブに論理ボリュームを作成します。私の場合、交換用のものとデータ用のものがあります。報告された「Current LE」属性から各論理範囲に割り当てられたサイズを取得し、
sudo lvdisplayそれをlvcreateコマンドへの入力として使用しました。たとえば、次のようになります。sudo lvcreate --extents 7296 --stripes 1 --name root ubuntu-1704-base-vgsudo lvcreate --extents 255 --stripes 1 --name swap_1 ubuntu-1704-base-vg
- 既存のドライブのデータを新しいドライブにコピーします。ソースドライブのブートパーティションを新しいドライブのブートパーティションにコピーし、データドライブの論理ボリュームをターゲットドライブの新しい論理ボリュームにコピーしてこれを実行しました。たとえば、
sudo dd if=/dev/sdb1 of=/dev/sda1 bs=64M status=progresssudo dd if=/dev/mapper/ubuntu--1704--base--vg--2-root of=/dev/mapper/ubuntu--1704--base--vg-root bs=64M status=progress
最後に、ファイルシステムチェックを実行してドライブが正常であることを確認します。修正する必要があるエラーがある可能性がありますが、これを実行した後にコピーされたドライブから正常に起動でき、内容は予想通りです。
sudo e2fsck -f /dev/mapper/ubuntu--1704--base--vg-root
使用された参考資料： https://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safely/ https://docs.microsoft.com/en-us/azure/virtual-machines/linux/configure-lvm
答え2
私が理解している場合、実際に達成する必要があるのは、VMイメージをより小さなスペースを持つイメージにコピーしながら、まだHyper-V（したがってVHDX形式）で使用することです。
この場合、新しい仮想マシンは必要ないと思います。
VMディスクイメージは、固定サイズまたは動的サイズで作成できます。固定サイズを使用すると、イメージ作成時にスペース全体が割り当てられ、VMイメージは実際に最終サイズを使用します。動的フォーマットを使用すると、ディスク容量は仮想マシンの物理ディスク使用量に応じて増加します。
したがって、実際にどの形式が使用されているかを最初に確認する必要があります。イメージファイルは50 Gbを公開することができますが、実際にはより少なく使用できます（OSでサポートされている場合は、スパースファイルが原因でこの問題が発生する可能性があります）。
画像が固定画像の場合、LVMやパーティションを変更せずに固定画像から新しい動的画像を作成するには、コンバータツール（StarWind V2V Converterなど）を探す必要があります。
注：まず、Ubuntu VMの各ファイルシステムで未使用のスペースをすべて消去する必要があります（ dd if=/dev/zero of=/zerofile ; rm -f /zerofile ）。