Un comportement de KVM/qemu quelque peu surprenant de prime abord, et qui ne laisse aucune trace dans les logs : KVM met en pause les machines virtuelles dont l’image qcow2 a été sur-provisionnée et qui viendrait à être à cours d’espace disque sur l’hôte.

Quand l’image disque qcow2 de votre machine virtuelle a une taille dynamique (elle peut s’accroître) on appelle également cela le thin-provisionning. Cela permet de connecter à la machine virtuelle un disque plus grand que la consommation réelle de l’image disque sur l’hôte. Cela présente plusieurs avantages parmi lesquels la souplesse d’utilisation des machines virtuelles, des sauvegardes raccourcies en cas de copie de l’image, un plus grand espace libre pour trimer le SSD hôte, etc.

Le danger des images disques dynamiques, c’est que l’on peut allouer plus d’espace disque qu’il n’en existe réellement sur le pool de stockage. Tant que les machines virtuelles ne cherchent pas à consommer de l’espace disque, tout va bien. Mais elles peuvent très rapidement venir remplir l’espace disque du pool de stockage à 100%.

Dans ces conditions, KVM/qemu aura le réflexe de mettre spontanément la machine virtuelle en pause. La commande virsh resume <vm>  permettant de réveiller des machines virtuelles en pause fonctionne, mais la machine virtuelle pourra se remettre en pause très rapidement. Ce comportement semble se produire avec ou sans libvirtd, donc même en lançant KVM/qemu à la main.

Une seule chose à faire dans ce cas : libérer de l’espace disque sur le pool de stockage de la machine hôte.

Vous vous demandez pourquoi vos machines virtuelles se mettent en pause toutes seules ? Vous avez peut-être là un élément de réponse.

Pour éviter de rencontrer ce problème, on peut faire diminuer la taille des images qcow2 coté hôte en prenant en compte l’espace libéré coté invité. Il existe une méthode hors ligne et une méthode à la volée, ma préférée cet cette dernière qui emploie la commande trim d’une manière détournée.

Liens en rapport :