✌🏼 🧑🏽‍🤝‍🧑🏼 🎅🏿 Réduction de l'image qcow2 dans Libvirt KVM 🏑 🐸 💊

Avez-vous déjà réduit la taille de l'image disque qcow2 utilisée dans les machines virtuelles KVM-QEMU? Comme vous le savez, le processus d'augmentation de la taille de l'image est assez simple et rapide, mais qu'en est-il de la réduction?

Dans cet article, je vais vous parler de la situation où vous devez réduire le plus rapidement possible l'image qcow2 de la machine virtuelle KVM.

Bloquer le format de l'appareil - QCOW2

Mais, néanmoins, ce schéma peut être fait avec des images brutes, il suffit de le convertir en qcow2. En général, l'instruction sera pertinente pour tout ce qui est converti en qcow2.

Un moyen simple de réduire le disque sur KVM est le suivant:

Compression d'un périphérique bloc qcow2 (disque VM)
Créer un disque plus petit
Montage de l'image gparted, de l'ancien et du nouveau disque
Préparation au démarrage du système d'exploitation
Spécifications de la machine virtuelle et de la machine hôte:

Hôte: CentOS 7 + QEMU 2.12 + LIBVIRT 4.5.0 + Kernel UEK5 v. 4.14

VM: CentOS 7 + disque dur 80 Go + noyau std v. 3.10

Le donateur sera une machine virtuelle CentOS 7 avec une image de disque dur de 80 Go, occupée en fait par 20 Go et physiquement 80 Go. Nous allons le réduire à 40 Go.

Quelle est la différence entre la taille de l'image, la taille réelle et la taille physique?

Disons que l'image qcow2 a été créée avec une taille de 80 Go et nous le savons. Pendant le fonctionnement, l'image était obstruée par des données, certaines données ont été supprimées. De manière générale, en raison des particularités du processus d'écriture et de suppression de données, pour le système d'exploitation, les données supprimées ne semblent pas exister, mais restent enregistrées dans l'image jusqu'à ce qu'elles soient écrasées par d'autres données. En conséquence, même dans le système d'exploitation, vous verrez 20 Go de données réellement occupées, l'hôte KVM affichera une image magnifique (nous utilisons l'utilitaire qemu-img pour obtenir des informations):

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

Vous pouvez voir que la taille virtuelle = la taille du disque, ainsi que l'image du -sh montrera qu'elle occupe 80G réels:

du -sh qcow2_image.img
80G    qcow2_image.img

Et comme nous devons réduire la taille de l'image à 40 Go, commençons le processus.

Étape 1 - Compression du périphérique bloc (image)

Avant de démarrer la procédure de réduction de disque, vous devez vous assurer que l'espace occupé à l'intérieur du système d'exploitation est inférieur au volume auquel le disque sera réduit d'une manière ou d'une autre.

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

Comme nous pouvons le voir, 18 Go sont occupés, ce qui représente moins de 40 Go. Éteignez la machine virtuelle avec la commande

shutdown -h now

Et allez sur la machine hôte, vérifiez:

combien l'image prend physiquement
combien en fait

# 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

Pour compresser l'image, nous avons besoin d'un utilitaire simple appelé virt-sparsify . Assurez-vous que la machine virtuelle est hors service et exécutez la commande dans le répertoire avec l'image disque (Remarque importante: avant de démarrer virt-sparsify , assurez-vous qu'il y a suffisamment d'espace libre dans / tmp et dans le stockage d'image pour effectuer l'opération)

virt-sparsify qcow_shrink qcow_shrink-new

La réussite de l'opération entraînera le résultat suivant:

[   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.

Ensuite, nous échangeons le disque (déplacez qcow_shrink quelque part sur le côté, par exemple, qcow_shrink-old et qcow_shrink-new à sa place - qcow_shrink ).

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

Nous démarrons la VM. Si tout commence, nous éteignons la VM et continuons à travailler.

Étape 2 - Créer un disque plus petit

Une procédure simple avec une seule commande:

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

qcow_shrinked - nouveau nom d'image

40G - nouvelle taille

Étape 3 - Connexion gparted

Étant donné que parfois les administrateurs préfèrent des moyens plus simples de résoudre le problème, le tambourin est mis de côté (kpartx) et ISO et VNC viennent à sa place. Heureusement, il n'est pas très difficile de le connecter en KVM.

Que faisons-nous:

Monter l'image ISO GParted
Connectez qcow2_shrinked à VM
Lancer la machine virtuelle, démarrer à partir de l'ISO

J'omettrai comment faire cela dans cet article, car il est supposé que la personne qui fait tout cela sait déjà comment cela se passe, mais le résultat sera le suivant:

Démarrez la VM et voyez l'écran de démarrage GParted:

Sélectionnez le premier élément et suivez les instructions à l'écran. J'appuie généralement sur Entrée jusqu'au bout.

Voyant GParted lui-même, passons à l'action. Nous vérifions rapidement si / dev / vda a une table de partition - msdos ou gpt . Ceci est important:

Basculez vers le deuxième disque / dev / vdb et créez la table de partition:

Lors de la création de la table, sélectionnez le type msdos comme nous l'avons appris précédemment.

Revenez ensuite à / dev / vdaet séquentiellement, à partir des premiers disques, nous commençons à copier des partitions, en basculant entre vda et vdb :

Le résultat final sera:

Appuyez sur Appliquer et attendez que le résultat se termine:

En conséquence:

Cela ressemble déjà à la vérité. Mais comme nous avons effectué des manipulations qui conduiront à une modification de l'UUID des disques, nous ne démarrerons potentiellement pas dans le système d'exploitation. Pourquoi? CentOS 7 utilise des UUID de disque dans fstab, Grub2 utilise des UUID de disque, alors sautez dans la console et faites de la magie noire.

Gparted fonctionne initialement en tant qu'utilisateur, nous sautons donc sous root avec la commande sudo su - root :

Let's blkid pour s'assurer que l'UUID des partitions a changé

On peut voir que l'UUID vda1 = vdb1, mais pour vdb2, il a changé. C'est bon - vous pouvez vivre avec.

Montez complètement vdb, avec la partition / boot, et montez certaines partitions pour notre commodité.

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 .

Commençons par fstab - comme il n'est pas très pratique de taper l'UUID dans VNC, nous le remplacerons par le nom familier de l'appareil.

Nous remplaçons la ligne avec UUID = ... avec attention : nous

spécifions / dev / vdb2 , si l'ancien disque est pas prévu d'être déconnecté, nous

spécifions / dev / VDA2 , si l'ancien disque est déconnecté

Comme nous déconnecter l' ancien disque avant de charger le système d' exploitation, puis d' écrire / dev / VDA2

Suivant changeons le bootloader, mettons-le dans l'ordre. Supposons que tout soit dans / boot / grub2, grub.cfg est au même endroit, mais efi ne l'est pas (table msdos, qui est efi :)):

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

Sur ce, vous pouvez être heureux pour vous et en désactivant gparted, démarrez le système d'exploitation.

Étape 4 - Démarrez le système d'exploitation

Avant de charger le système d'exploitation, je recommande toujours de déconnecter l'ancien disque du serveur. Par conséquent, à l'étape précédente, vda2 devait être enregistré dans fstab, mais si vous êtes un utilisateur de PC attentif et que vous n'avez rien déconnecté, aucun problème ne devrait survenir. Avec un ancien disque, il est très probable que vous démarrerez à partir de celui-ci.

Il n'y a eu aucun problème pendant le processus de démarrage, le serveur a démarré comme prévu. Vérifions ceci:

[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"

Nous pouvons voir que / boot et / sont requis, taille 40 Go, le système d'exploitation est en cours d'exécution. Du bonheur, pas autrement!

Prime

Quelque chose que vous devrez affronter dans certaines situations.

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

Très probablement, lorsque tout était fait dans gparted ou dans un autre environnement, la version du noyau de cet environnement était trop récente, dans laquelle xfs était légèrement modifiée, à savoir les métadonnées et leur version diffèrent. En conséquence, les fichiers xfs créés dans le nouveau noyau se transforment en citrouille sur l'ancien. Ce que nous faisons, c'est redémarrer dans rescue gparted, élever le réseau dans cet environnement de secours et installer le noyau le plus récent du système d'exploitation. J'ai installé 5.x sur CentOS 7, peut-être que 4.x fera l'affaire, je ne l'ai pas testé, mais à la fin tout a fonctionné. De plus, sans aucun problème.

C'est tout!

Comme vous pouvez le voir, il n'y a rien de compliqué à ce sujet. Bien sûr, vous pouvez utiliser LVM, resize2fs et d'autres choses, mais qcow2 est toujours utilisé ailleurs et même nécessaire à quelqu'un.

Si vous connaissez une méthode encore plus simple, écrivez-la dans les commentaires.

Réduction de l'image qcow2 dans Libvirt KVM