Blog / Article #119

Proxmox et le ballooning

Le ballooning sur Proxmox, c’est un peu comme ces matelas gonflables qu’on sort pour les invités : ça promet de l’espace, mais si on souffle trop fort, tout le monde finit par terre. Officiellement, c’est une technique pour optimiser la mémoire vive entre l’hôte et ses machines virtuelles (VM). Officieusement, c’est une danse délicate entre efficacité et catastrophe potentielle. Voyons quand ça vaut le coup de jouer les souffleurs de ballons.

Le ballooning c’est quoi ,  un sport olympique ? 

Dans l’univers de la virtualisation, le ballooning est une fonctionnalité de KVM (via QEMU) qui permet à une VM de « rendre » de la mémoire à l’hôte quand elle n’en a pas besoin. Concrètement, le pilote virtio_balloon dans la VM gonfle un « ballon » en réservant de la RAM, que l’hôte peut ensuite réallouer à d’autres VM. Quand la VM a de nouveau besoin de mémoire, le ballon se dégonfle et la RAM est restituée.

Sur Proxmox, cette option est activée par défaut pour les VM Linux (via le pilote virtio) et peut être configurée manuellement pour les autres. L’idée est séduisante : pourquoi gaspiller de la RAM inutilisée quand on peut la partager dynamiquement ? Sauf que, comme souvent en informatique, la théorie et la pratique s’entendent comme deux chats dans un sac.

Quand le ballooning est (vraiment) utile

Le ballooning brille dans deux scénarios précis, où il évite de transformer votre serveur en passoire à RAM :

• Des VM avec des pics d’activité décalés : si vos VM ont des cycles d’utilisation qui ne se chevauchent pas (ex : un serveur web qui tourne la journée et un batch qui s’exécute la nuit), le ballooning permet de mutualiser la RAM sans sur-allouer. C’est le cas d’usage idéal, où tout le monde y gagne sans se marcher dessus.
• Un hôte avec des ressources limitées : quand votre serveur physique a juste assez de RAM pour faire tourner vos VM en théorie, mais pas assez pour les laisser toutes respirer en même temps. Le ballooning agit alors comme un filet de sécurité, évitant les OOM killer (Out Of Memory killer) qui feraient passer vos VM pour des figurants dans un film d’horreur.

Dans ces situations, le ballooning est une solution élégante, à condition de ne pas tomber dans le piège de la sur-allocation. Parce que oui, il y a un piège.

Quand le ballooning devient un piège à cons (et comment l’éviter)

Le ballooning, c’est comme les régimes : ça marche si on suit les règles, mais si on abuse, ça finit en crise de foie. Voici les erreurs à ne pas commettre :

• Sur-allouer la RAM comme un trader en 2008 : si vous allouez 100 Go de RAM à vos VM alors que votre hôte n’en a que 64, le ballooning ne fera pas de miracle. Quand toutes les VM auront besoin de leur RAM en même temps, l’hôte va commencer à swapper, et là, c’est le drame. Les performances chutent, les logs se remplissent de kswapd en crise, et vos utilisateurs se demandent pourquoi leur application met 30 secondes à répondre à un SELECT * FROM users.
• Activer le ballooning sur des VM critiques : une base de données ou un serveur de production qui a besoin de performances stables n’a pas à jouer à la loterie de la RAM. Si le ballon se gonfle au mauvais moment, les latences explosent. Pour ces cas-là, mieux vaut allouer une RAM fixe et désactiver le ballooning (balloon: 0 dans la config Proxmox).
• Négliger le monitoring : le ballooning, ça se surveille. Proxmox fournit des métriques via pveperf et l’interface web, mais si vous ne regardez pas, vous ne verrez pas venir la catastrophe. Un ballon qui reste gonflé trop longtemps, c’est le signe que votre VM étouffe. À vous de jouer les pompiers avant que ça ne sente le brûlé.

Autre point noir : le ballooning ne fonctionne bien qu’avec des VM Linux équipées du pilote virtio_balloon. Pour les VM Windows, c’est plus aléatoire (le pilote existe, mais il est moins fiable), et pour les autres OS, c’est souvent la loterie. Si vous mixez des VM Linux et Windows sur le même hôte, préparez-vous à des comportements imprévisibles.

Comment configurer le ballooning sur Proxmox (sans se tirer une balle dans le pied)

Si vous êtes toujours chaud pour tenter l’aventure, voici comment activer et configurer le ballooning proprement :

1. Dans l’interface Proxmox, éditez la configuration de votre VM (Options > Memory). Vous verrez deux champs : Memory (la RAM allouée) et Ballooning Device (la RAM minimale garantie). Par exemple :

memory: 8192
balloon: 2048

Ici, la VM a 8 Go de RAM alloués, mais l’hôte peut lui en reprendre jusqu’à 6 Go via le ballooning (8 Go - 2 Go).

2. Pour les VM Linux, assurez-vous que le module virtio_balloon est chargé :

lsmod | grep virtio_balloon

Si ce n’est pas le cas, chargez-le :

modprobe virtio_balloon

3. Surveillez l’activité du ballooning via l’interface Proxmox ou en ligne de commande :

qm monitor <vmid>
info balloon

Cela vous donnera la quantité de RAM actuellement « ballonnée ». Si le chiffre est proche de la RAM allouée, c’est que votre VM étouffe.

Conclusion : le ballooning, oui, mais avec modération

Le ballooning sur Proxmox, c’est un outil puissant, mais comme un couteau suisse : utile dans certaines situations, dangereux si on s’en sert n’importe comment. Il excelle pour optimiser des environnements avec des VM aux cycles d’activité décalés ou des ressources limitées, mais il devient un cauchemar si on sur-alloue ou qu’on l’utilise sur des VM critiques.

La règle d’or ? Testez, surveillez, et n’ayez pas les yeux plus gros que le ventre. Si votre hôte a 64 Go de RAM, ne vous amusez pas à allouer 128 Go en comptant sur le ballooning pour sauver la mise. Parce qu’au final, personne n’aime se réveiller avec un OOM killer en guise de réveil-matin.