Convertir une image disque de machine virtuelle au format qcow2

Cet article a été publié il y a 9 ans 8 mois 13 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Il y a deux semaines, une grosse panne a impacté le serveur de la Team-Original Criminel, dont je fais partie. C’est notamment sur cette machine que j’ai fait mes armes avec la libvirt, dont je vous avais déjà parlé. Le problème était grave : il a fallu réinstaller tout le serveur, fort heureusement pas les machines virtuelles, qu’il a suffi de déplacer puis de rapatrier. Problème, ça a pris beaucoup, beaucoup de temps (le serveur est tombé à 14h, rétabli à 23h). Description des causes, des conséquences, et des solutions, principalement celle décrite dans le titre.

Un mal qui remonte à l’apprentissage de Proxmox

Je ne pourrais malheureusement pas décrire précisément pourquoi, après un plantage/redémarrage de la machine, libvirt refusait de démarrer en prétextant une absence de « module » KVM (l’infrastructure de virtualisation intégrée au noyau Linux, compilée en dur dans le noyau fourni par OVH). Mon problème a été le temps qu’il a fallu pour transférer les images disques des machines virtuelles sur un stockage externe, puis leur rapatriement, puisque la réinstallation de Debian n’a pris à peine qu’une dizaine de minutes. Ce sont 96Go qu’il fallait manipuler.

Les images disques sont au format RAW, qui imposent de préallouer l’espace en fonction de la taille voulue. C’est le format que l’on avait choisi un peu par défaut lors de notre première approche de la virtualisation, avec Proxmox (notre deuxième étape en fait, suite à des soucis de performances–oui, étrange je sais– avec les conteneurs OpenVZ). Dans le cas de la machine destinée au VPN, un disque de 16Go signifie un fichier de 16Go. 30Go pour la machine « web/voix », et 60Go pour la machine « jeux ». Je me rend compte qu’en fait, je deviens mauvais en calcul, puisque ce sont un peu plus de 100Go que nous avons dû « déplacer » le temps de formater le serveur. Bref, c’est long, très long. Imaginez en plus que vous prenez du temps pour compresser et transférer ces mêmes images toutes les semaines à titre de sauvegarde. Le temps de « downtime » (qui a du coup concerné ce blog, qui est hébergé sur la machine virtuelle « web ») est trop long, il faut donc trouver des solutions. L’une d’elles, qui est en cours de « déploiement », est de réduire la taille des images, sans devoir tout refaire de zéro.

Un format pour les gouverner tous ?

Si vous avez bien relu l’introduction à la libvirt, vous aurez remarqué que l’image disque créée pour l’occasion était au format qcow2. Ce format, principalement utilisé par qemu, qui est le « lanceur » de machines virtuelles attitré (d’ailleurs utilisé par libvirt pour lancer les machines KVM), possède plusieurs avantages sur le format RAW : un support des snapshots, c’est à dire des instantanés, permettant de revenir notamment à un état antérieur, un support d’images dérivées (une image de base commune, puis des images distinctes pour les changements de chaque VM) et surtout, l’allocation dynamique (ce que permet aussi le vmdk, format de disque utilisé chez VMWare, un autre hyperviseur, très prisé dans le monde professionnel, mais très propriétaire et très vite cher). C’est cette caractéristique qui nous intéresse ici, car elle permet de disposer d’images disque qui ne pèsent que le poids réel des données qu’elle contiennent.

Pour reprendre le disque de 16Go du VPN, vous imaginez bien qu’un OpenVPN sur une base Debian Wheezy ne prend pas ces 16Go, mais bien moins. Avec une image au format qcow2, ces 16Go ne représentent que la limite de taille que peut atteindre l’image. Le système invité lui, voit quand même bien un disque de 16Go. magie. Imaginez dès lors le gain de temps sur les compressions et les transferts.  Les coupures de services seront dès lors plus courtes.

Et on peut convertir sans tout perdre !

Fort heureusement, il n’est pas nécessaire de repartir de zéro, et je vais évidemment vous dire comment faire. Je me suis servi de la fameuse machine « VPN » comme cobaye, puisque c’est la moins critique, et surtout la plus légère, donc la moins longue à retaper. J’ai commencé par « éteindre » proprement la VM à l’aide la commande halt (on peut lui préférer poweroff pour atteindre le me résultat). J’ai préféré ensuite faire une copie du disque, pour être sûr de ne rien casser :

 Pour convertir l’image disque, c’est presque trop simple, une seule commande suffira, et elle n’est pas très compliquée :

 Petit tour des options utilisées :

• convert se passe de commentaire
• -c permet de compresser l’image cible
• -f raw spécifie le format de l’image d’origine
• -O qcow2 spécifie le format de l’image cible

Je vous invite à lire la page de manuel pour voire la liste des options disponibles (il est notamment possible de faire une vérification des images).

Une fois l’opération terminée, je vous laisse apprécier le gain de place que ça permet d’obtenir :

Oui, l’image ne fait plus que 2Go. Impressionnant non ? Le gain sera évidemment variable suivant le taux de remplissage des partitions qui composent le disque « virtuel ». En l’occurrence, je sais qu’avec 80% d’utilisation de la plus grosse partition de la machine « jeux », le gain sera plus faible (de l’ordre d’une dizaine de Go, pas trop mal quand même). Reste maintenant à s’en servir.

Utilisation de la nouvelle image

Il faut maintenant modifier la configuration de la machine virtuelle pour prendre en compte la « nouvelle » image. Un petit coup de virsh edit kvm_vpn, et il suffit de chercher cette section :

 Deux choses à modifier :

• type=’raw’ à changer en type=’qcow2′
• file=’/home/kvm_vpn/kv_vpn.raw’ en file=’/home/kvm_vpn/kvm_vpn_1.qcow2′

Une fois terminé, vous pouvez relancer la commande avec virsh start kvm_vpn, et admirer le résultat.

Un petit mot rapide sur les snapshots

On traduit généralement les snapshots par « instantanés ». Ce sont donc des photos de la machine virtuelle à un instant T. Elles permettent notamment de revenir à un état antérieur si d’aventure vous tentiez de péter votre système. C’est plus rapide qu’une sauvegarde complète, et moins lourd à gérer. Attention tout de même, si vous faites trop de snapshots, la consommation d’espace disque risque d’exploser.

Pour faire très court, et en reprenant l’exemple du VPN, on crée un snapshot avec la commande :

 Pour revenir à l’état du snapshot après une modification, c’est à peu près aussi court :

Je vous invite à relire plus en détail la page de man de virsh qui permet de voir toutes les options disponibles, ainsi que les commandes annexes (notamment pour gérer plusieurs snapshots).