1. VM KVM versus conteneur LXC — choisir le bon outil

1.1 Deux philosophies de virtualisation : conteneur et machine virtuelle

Proxmox VE propose deux façons radicalement différentes d'exécuter un système : le conteneur LXC, abordé au chapitre précédent, et la machine virtuelle KVM, qui fait l'objet de ce chapitre. Un conteneur partage le noyau Linux de l'hôte Proxmox — il est rapide à démarrer, léger en mémoire, mais limité aux systèmes Linux et exposé à certains risques d'isolation.

Une machine virtuelle KVM, elle, possède son propre noyau, son propre BIOS ou UEFI, son propre espace mémoire entièrement isolé. Le noyau hôte n'est pas partagé : la VM ne sait même pas qu'elle tourne sur Proxmox.

Cette isolation totale a un coût — quelques centaines de mégaoctets de RAM minimum, un démarrage qui prend quelques secondes, et une couche d'émulation matérielle. Mais elle ouvre des possibilités qu'un conteneur ne peut pas offrir : faire tourner Windows, un BSD, un kernel personnalisé. Ou des services qui s'attendent à trouver un vrai matériel sous leurs pieds : Home Assistant OS, pfSense, TrueNAS.

Le schéma ci-dessus résume cette opposition. À gauche, plusieurs conteneurs LXC empilés sur un seul noyau partagé. À droite, plusieurs VMs KVM totalement indépendantes, chacune avec son propre noyau, émulé par QEMU et accéléré par KVM.

En résumé, le conteneur mise sur la légèreté et le partage ; la VM, sur l'isolation et l'indépendance totale vis-à-vis de l'hôte. C'est ce compromis qui guide le choix entre les deux pour chaque nouveau service à déployer.

Le tableau ci-dessous met les deux technologies face à face, sur les critères qui décident réellement du choix. C'est lui qu'on garde en tête au moment de créer une nouvelle ressource :

1.2 Quand utiliser une VM KVM

Utilisez une VM KVM lorsque vous avez besoin de :

• Faire tourner Windows (Server ou Desktop) — impossible dans un LXC
• Exécuter Docker de façon propre, avec son propre noyau
• Déployer une appliance réseau : pfSense, OPNsense, VyOS — ces systèmes sont compilés pour un matériel spécifique
• Tester des noyaux expérimentaux ou des distributions alternatives sans risque pour l'hôte
• Obtenir une isolation maximale pour un service sensible. Un attaquant qui compromet une VM ne peut pas remonter vers l'hôte sans exploiter une vulnérabilité de l'hyperviseur. C'est autrement plus difficile que d'exploiter un espace de noms Linux

En résumé : si ce que vous installez a besoin d'un vrai système d'exploitation indépendant, choisissez une VM KVM. Pour tout ce qui est Linux léger (nginx, MariaDB, Pi-hole, DNS), un LXC reste le bon choix.

La règle pratique à retenir : pour un service Linux standard, sans modules noyau particuliers ni Windows, le conteneur LXC est le bon choix. Pour tout le reste, la VM KVM s'impose. Le choix n'est d'ailleurs jamais exclusif : sur un même nœud, VM et conteneurs cohabitent et partagent les mêmes stockages et les mêmes bridges.

Ils se sauvegardent avec les mêmes outils : vzdump, ou Proxmox Backup Server. Une infrastructure typique mêle donc les deux — des conteneurs pour les petits services Linux, des VM pour Windows, les appliances et tout ce qui exige une isolation forte.

Deux différences pèsent en exploitation et méritent d'être connues dès maintenant. La migration à chaud n'existe que pour les VM : un conteneur se déplace d'un nœud à l'autre en redémarrant. Et une VM utilise la mémoire qu'on lui attribue, plus celle de son propre noyau et de QEMU.

Un conteneur ne consomme que ce que ses processus utilisent réellement. D'où la densité très supérieure des conteneurs sur un même serveur.

À retenir : un conteneur LXC partage le noyau du nœud : léger, rapide, mais Linux seulement. Une VM KVM a son propre noyau et son matériel virtuel : on la choisit pour Windows, un autre noyau, une isolation forte ou une appliance. Pour un service Linux léger, le LXC reste le bon choix.