Clever Geek Handbook

LibvirtKVMでのqcow2イメージの縮小

KVM-QEMU仮想マシンで使用されるqcow2ディスクイメージのサイズを縮小したことがありますか？ご存知のように、画像のサイズを大きくするプロセスは非常に簡単で高速ですが、縮小についてはどうでしょうか。



この記事では、KVM仮想マシンのqcow2イメージをできるだけ早く縮小する必要がある状況について説明します。



ブロックデバイスフォーマット-qcow2



しかし、それにもかかわらず、このスキームは生の画像で行うことができ、qcow2に変換するだけで十分です。一般に、この命令はqcow2に変換されるすべてのものに関連します。



KVMでディスクを縮小する簡単な方法は次のとおりです。



  1. qcow2ブロックデバイス（VMディスク）の圧縮
  2. 小さいディスクを作る
  3. gpartedイメージ、古いディスクと新しいディスクのマウント
  4. OSを起動する準備
  5. VMとホストマシンの仕様：


ホスト：CentOS 7 + QEMU 2.12 + LIBVIRT 4.5.0+カーネルUEK5v。 4.14

VM：CentOS 7 + 80GB HDD +カーネル標準v。 3.10

実際には20ギガバイトと80ギガバイトを物理的によって占め80ギガバイトのハードディスクイメージを持つA CentOSの7の仮想マシンは、ドナーとして機能します。 40GBに削減します。



画像サイズ、実際のサイズと物理的なサイズの違いは何ですか？

qcow2イメージが80GBのサイズで作成され、それについて知っているとしましょう。操作中に画像がデータで詰まり、一部のデータが削除されました。一般的に、データの書き込みと削除のプロセスの特殊性のために、OSの場合、削除されたデータは存在しないように見えますが、他のデータによって上書きされるまで画像に記録されたままになります。したがって、実際に占有されている20GBのデータが表示されるOSでも、KVMホストはそのようなすばらしい画像を表示します（qemu-imgユーティリティを使用して情報を取得します）。 



qemu-img info qcow2_image.img
image: qcow2_image.img
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16


仮想サイズ=ディスクサイズであることがわかります。また、画像のdu -shは、実際の80Gを占有していることを示しています。 



du -sh qcow2_image.img
80G    qcow2_image.img


そして、画像サイズを40GBに縮小する必要があるので、プロセスを開始しましょう。



ステージ1-ブロックデバイスの圧縮（画像）



ディスク削減手順を開始する前に、OS内の占有スペースが、何らかの方法でディスクが削減されるボリュームよりも小さいことを確認する必要があります。 



df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        80G   18G   63G  22% /


ご覧のとおり、18GBが占有されています。これは40GB未満です。コマンドでVMをオフにします 



shutdown -h now


そして、ホストマシンに移動し、以下を確認します。



  • 画像は物理的にどのくらいかかりますか
  • 実際にいくら


# qemu-img info qcow_shrink
image: qcow_shrink
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16
# virt-df -h qcow_shrink
du -sh Filesystem                                Size       Used  Available  Use%
qcow_shrink:/dev/sda1                     488M       101M       351M   21%
qcow_shrink:/dev/sda2                      79G        17G        62G   22%
# du -sh qcow_shrink
80G     qcow_shrink


画像を圧縮するには、virt-sparsifyという簡単なユーティリティが必要です。VMが機能していないことを確認し、ディスクイメージと一緒にディレクトリでコマンドを実行します（重要な注意：virt-sparsifyを開始する前に、/ tmpとイメージストレージに操作を実行するのに十分な空き領域があることを確認してください） 



virt-sparsify qcow_shrink qcow_shrink-new


操作が正常に完了すると、次の出力が得られます。 



[   0.0] Create overlay file in /tmp to protect source disk
[   0.1] Examine source disk
[   1.2] Fill free space in /dev/sda1 with zero
[   1.5] Fill free space in /dev/sda2 with zero
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
[  72.5] Copy to destination and make sparse
[  81.9] Sparsify operation completed with no errors.
virt-sparsify: Before deleting the old disk, carefully check that the
target disk boots and works correctly.


次に、ディスクを交換します（qcow_shrinkを横に移動します。たとえば、qcow_shrink-old、qcow_shrink-newをその場所に移動します--qcow_shrink）。 



mv qcow_shrink qcow_shrink-old && mv qcow_shrink-new qcow_shrink


VMを起動します。すべてが開始されたら、VMを消滅させ、作業を続行します。



ステージ2-より小さなディスクを作成する



たった1つのコマンドで簡単な手順： 



qemu-img create -f qcow2 -o preallocation=metadata qcow_shrinked 40G


qcow_shrinked -新しいイメージの名前

40G -新しいサイズ



ステージ3-接続gparted



管理者が問題を解決するためのより簡単な方法を好むことがあるため、タンバリンは脇に置き（kpartx）、ISOとVNCが代わりに使用されます。幸い、KVMで接続することはそれほど難しくありません。



私たちは何をしていますか：



  • ISOGPartedイメージを接続します
  • qcow2_shrinkedをVMに接続します
  • VMを起動し、ISOから起動します


これを行う方法は、これらすべてを実行する人がそれがどのように発生するかをすでに知っていると想定されるため、この記事から省略しますが、結果は次のように



画像



なります。VMを起動してGPartedブート画面を表示します。



画像



最初の項目を選択し、画面の指示に従います。私は通常、Enterキーを最後まで押します。



画像



GParted自体を見て、行動に移りましょう。素早くチェックパーティションテーブルは/ dev / VDAはあり- MSDOSやGPTを。これは重要です



画像



。2番目のdisk / dev / vdbに切り替えて、パーティションテーブルを



画像



画像



作成します。テーブルを作成するときは、前に学習したようにmsdosタイプを選択します。



次に、/ dev / vdaに切り替えますそして順番に、最初のディスクからパーティションのコピーを開始し、vdaとvdbを切り替えます



画像



。最終結果は次のようになります。[



画像



適用]を押して結果が完了するのを待ち ます。



画像



結果：



画像



それはすでに真実のように見えます。ただし、ディスクのUUIDの変更につながる操作を行ったため、OSを起動しない可能性があります。どうして？ CentOS 7はfstabでディスクUUIDを使用し、Grub2はディスクUUIDを使用するため、コンソールにジャンプしてブラックマジックを実行します。



私たちはコマンドでルートの下にジャンプしてGPartedのは、ユーザーとして最初に働く須藤秀-ルート：



画像



レッツ・BLKIDパーティションのUUIDが変更されたことを確認するために



画像



UUID vda1 = vdb1であることがわかりますが、vdb2では変更されています。それは大丈夫です-あなたはそれと一緒に暮らすことができます。



/ bootパーティションとともにvdbを完全にマウントし、便宜上いくつかのパーティションをマウントします。 



mkdir vdb2
mount /dev/vdb2 vdb2
mount /dev/vdb1 vdb2/boot
cd vdb2
mount --bind /dev dev
mount --bind /sys sys
mount --bind /proc proc
chroot .


fstabから始めましょう-VNCでUUIDを入力するのはあまり便利ではないため、使い慣れたデバイス名に置き換えます。



画像



私たちは、UUIDを持つ行を置き換える= ...で、注意：我々は



指定の/ dev / vdb2古いディスクがされている場合、切断を予定していない私たちは、

指定の/ dev / VDA2古いディスクがあれば、切断されます



、我々はので外して古いディスクを、その後の書き込み、OSをロードする前には/ dev / VDA2



次へブートローダーを変更して、整理しましょう。すべてが/ boot / grub2にあり、grub.cfgが同じ場所にあるが、efiはそうではないと仮定しましょう（msdosテーブル、つまりefi :)）： 



grub2-install /dev/vdb
cd /boot/grub2
grub2-mkconfig -o grub.cfg


これであなたは自分自身に満足することができ、gpartedを無効にすることでOSを起動します。



ステージ4-OSを起動します



OSをロードする前に、古いディスクをサーバーから切断することをお勧めします。したがって、前の段階では、vda2をfstabに登録する必要がありましたが、注意深いPCユーザーであり、何も切断していなければ、問題はありません。古いディスクでは、そこから起動する可能性が非常に高くなります。



起動プロセス中に問題は発生しませんでした。サーバーは期待どおりに起動しました。これを確認しましょう： 



[root@shrink ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        484M     0  484M   0% /dev
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           496M  6.7M  489M   2% /run
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/vdb2        40G   18G   23G  44% /
/dev/vdb1       488M  101M  352M  23% /boot
tmpfs           100M     0  100M   0% /run/user/0

[root@shrink ~]# blkid
/dev/vda1: UUID="ea505196-32fb-4df6-8bed-0a0ab2d0b726" TYPE="ext4"
/dev/vda2: UUID="30ec1bc6-658f-4611-8708-5e3b7ebaa467" TYPE="xfs"
/dev/vdb1: UUID="ea505196-32fb-4df6-8bed-0a0ab2d0b726" TYPE="ext4"
/dev/vdb2: UUID="c8548834-272b-4331-a9bf-aa99fb41a434" TYPE="xfs"
/dev/sr0: UUID="2019-03-21-13-42-32-00" LABEL="GParted-live" TYPE="iso9660" PTTYPE="dos"


/ bootと/が必要で、サイズが40GBで、OSが実行されていることがわかります。幸福、そうでなければ！



ボーナス



あなたがいくつかの状況で直面しなければならない何か。



  1. VM Windows, virt-sparsify . , , ( blkid), Windows , . ( ) fixmbr + rebuildbcd. — man
  2. — xfs Superblock has unknown read-only compatible features (0x4) enabled. read-only, . :


ほとんどの場合、すべてがgpartedまたは別の環境で行われたとき、この環境のカーネルのバージョンは新しすぎて、xfsがわずかに変更されました。つまり、メタデータとそのバージョンが異なります。その結果、新しいカーネルで作成されたxfsは、古いカーネルではカボチャに変わります。私たちが行うことは、rescue gpartedを再起動し、このレスキュー環境でネットワークを立ち上げ、OSに最新のカーネルをインストールすることです。CentOS 7に5.xをインストールしましたが、おそらく4.xで十分です。テストはしていませんが、最終的にはすべて機能しました。また、問題なく。



それで全部です！



ご覧のとおり、複雑なことは何もありません。もちろん、LVM、resize2fsなどを使用できますが、それでもqcow2は別の場所で使用され、誰かが必要とすることさえあります。



さらに簡単な方法を知っている場合は、コメントにそれについて書いてください。


More articles:


All Articles