Conteneurs LXC ou VM KVM dans Proxmox : lequel choisir et quand

D'abord la réponse : trois questions tranchent

Pour n'importe quel workload, posez-vous ces questions :

A-t-il besoin de son propre noyau ? Un OS différent (Windows, BSD), une version de noyau spécifique, des modules noyau, ou un réglage fin du noyau → VM. Les conteneurs partagent le noyau de l'hôte, un point c'est tout.
Quel niveau d'isolation est requis ? Code non fiable, séparation entre tenants, frontières de conformité → VM. La frontière de la virtualisation matérielle est catégoriquement plus forte que l'isolation par namespaces.
Devrez-vous le déplacer sans l'arrêter ? La migration à chaud entre nœuds d'un cluster est réservée aux VM ; les conteneurs se déplacent par arrêt-redémarrage.

Si les trois réponses sont « non » (un service fiable, basé sur Linux, redémarrable), un conteneur LXC vous donne le même workload dans une fraction de l'empreinte, avec un démarrage en environ une seconde. Cela décrit une grande partie de l'infrastructure réelle : reverse proxys, DNS, outils internes, instances de service par application. C'est pourquoi le schéma pratique chez Proxmox est mixte : des VM pour les joyaux de la couronne et tout ce qui est étranger, des conteneurs pour la flotte de petits services Linux qui les entourent.

Comment chacun fonctionne réellement

Une VM KVM est un ordinateur complet en logiciel : QEMU présente du matériel virtuel, KVM (le module hyperviseur du noyau) exécute le code de l'invité avec accélération matérielle, et l'invité fait tourner son propre noyau sur ce matériel, depuis sa propre image disque. L'hôte voit un seul processus ; l'invité, en pratique, ne sait pas qu'il est virtualisé (presque : les pilotes paravirtualisés VirtIO existent précisément pour le faire coopérer, question de vitesse).

Un conteneur LXC n'est pas un ordinateur : c'est une vue partitionnée du noyau de l'hôte. Les namespaces lui donnent des arborescences de processus, des piles réseau et des systèmes de fichiers privés ; les cgroups mesurent son CPU et sa mémoire. Il n'y a pas de second noyau, pas de matériel virtuel, pas de processus de démarrage au-delà du lancement d'init. C'est pourquoi un conteneur démarre en une seconde et ajoute un overhead par instance quasi nul, et pourquoi chaque conteneur de l'hôte vit et meurt avec l'unique noyau de cet hôte.

Proxmox traite les deux comme des citoyens de premier rang : même interface, mêmes backends de stockage, mêmes sauvegardes vzdump/PBS, même workflow de pare-feu et de snapshot. Les différences ci-dessous sont inhérentes aux technologies, pas des limitations de Proxmox.

Dimension	VM KVM	Conteneur LXC
OS invité	N'importe lequel (Linux, Windows, BSD…)	Linux uniquement, noyau de l'hôte
Isolation	Frontière de virtualisation matérielle	Namespaces du noyau (plus faible)
Overhead par instance	Noyau invité + RAM réservée + matériel virtuel	Quasi nul
Temps de démarrage	Démarrage d'OS (dizaines de secondes)	~1 seconde
Migration à chaud	Oui	Non, migration par redémarrage uniquement
Mémoire	Allouée à l'invité (le ballooning aide)	Limite cgroup ; la RAM inutilisée reste utilisable par l'hôte
Contrôle du noyau	Total (noyau et modules propres)	Aucun
Passthrough PCIe/GPU	Oui (VFIO)	Au niveau du périphérique seulement, pas de VFIO
Snapshots, sauvegardes, HA	Oui	Oui (HA = redémarrage sur un autre nœud)

Densité et overhead : la version honnête

Proxmox ne publie aucun chiffre officiel du type « X conteneurs par équivalent-VM », et vous devriez vous méfier de quiconque en avance un : la densité dépend entièrement du workload. Mais le mécanisme n'est pas discutable et mérite d'être compris :

Chaque VM paie une taxe fixe : son propre noyau et ses processus système, plus sa mémoire allouée, retenue que l'invité l'utilise ou non (le ballooning en récupère une partie, imparfaitement). Vingt petites VM, ce sont vingt noyaux et vingt réservations de mémoire.
Vingt conteneurs partagent un seul noyau et un seul page cache, et leurs limites de mémoire cgroup sont des plafonds, pas des réservations ; la RAM qu'un conteneur n'utilise pas est simplement de la RAM libre pour l'hôte.

Pour un travail limité par le CPU, la différence de débit est faible : l'exécution assistée par matériel de KVM est efficace, et une VM chargée est presque aussi rapide qu'un conteneur chargé. L'écart apparaît dans l'économie de mémoire et l'overhead par instance : sur un hôte qui fait tourner de nombreux petits services, les conteneuriser multiplie généralement combien en tiennent, moins parce que les conteneurs sont « plus rapides » que parce que les VM réservent ce que des services inactifs n'utilisent jamais. Dimensionnez l'hôte dans les deux cas avec les règles de virtualisation de notre guide de dimensionnement. La RAM est la contrainte limitante dans les deux modèles.

Isolation : ce qu'apporte le mode « non privilégié », et ses limites

Proxmox crée les conteneurs non privilégiés par défaut, et vous devriez le laisser ainsi : le root du conteneur est associé à un UID inoffensif et élevé sur l'hôte, si bien qu'une compromission complète du root du conteneur amène l'attaquant dans un compte hôte non privilégié. Combiné à AppArmor, seccomp et cgroups, un conteneur LXC non privilégié constitue une frontière respectable pour des workloads fiables.

Ce n'est pourtant toujours pas une frontière de VM. Chaque appel système d'un conteneur touche directement le noyau de l'hôte : la surface d'attaque entre le conteneur et l'hôte, c'est toute l'interface du noyau, contre l'interface hyperviseur bien plus étroite d'une VM. Les règles pratiques qui en découlent :

Code non fiable ou exposé à internet et à haut risque, autres tenants, workloads séparés pour conformité → VM. C'est à cela que sert la frontière la plus forte.
Les conteneurs privilégiés (l'option non par défaut) affaiblissent nettement le tableau : traitez-les comme une échappatoire héritée du passé, pas comme une option. Si un workload « a besoin » d'un conteneur privilégié, c'est généralement une VM qu'il veut en réalité.
Les conteneurs avec nesting activé (pour le confort de Docker et systemd) assouplissent encore l'isolation : très bien pour des services internes fiables, un argument de plus contre son usage pour quoi que ce soit de douteux.

La question Docker

La version la plus posée de cette comparaison, c'est en réalité : « où mes conteneurs Docker doivent-ils tourner ? » La recommandation actuelle de Proxmox lui-même, adoucie au fil des années mais constante dans sa direction : pour la production (surtout quand l'isolation ou la migration à chaud comptent), faites tourner Docker dans une VM, pas dans un conteneur LXC. Docker-en-LXC (avec nesting activé) est populaire dans les homelabs parce qu'il évite l'overhead d'une VM, mais il empile deux runtimes de conteneurs sur un seul noyau et a un historique de casse lors des mises à niveau de l'hôte, le genre de fragilité qu'on accepte dans un labo et qu'on regrette en production.

À surveiller à mesure que ça mûrit : depuis PVE 9.1, Proxmox peut créer des conteneurs directement à partir d'images OCI (le format d'image Docker) en tant que technology preview : on récupère une image et on la fait tourner comme un conteneur d'application géré par Proxmox, sans aucun daemon Docker. C'est vraiment prometteur comme future réponse native, mais « technology preview » signifie exactement cela ; l'ennuyeuse VM reste la recommandation pour la production tant que ça ne s'est pas stabilisé.

Donc : une VM « hôte Docker » (ou quelques-unes, par domaine de confiance), Docker à l'intérieur, et Proxmox gère la VM : vous obtenez une isolation de niveau VM, la migration à chaud pour tout le parc Docker, et des mises à niveau d'hôte propres.

Ce que seules les VM peuvent faire, et ce dans quoi LXC excelle

Au-delà des trois questions décisives, la liste concrète de ce que seules les VM permettent : Windows et les autres invités non-Linux, des noyaux personnalisés ou plus récents que celui de l'hôte, des modules noyau (WireGuard est déjà dans le noyau, mais pensez à des modules de stockage spécialisés ou de recherche), le passthrough PCIe via VFIO (GPU pour le transcodage ou l'IA, HBA pour un invité NAS), et, opérationnellement le plus important, la migration à chaud et la portabilité indépendante de l'hyperviseur (une image disque de VM se déplace vers n'importe quel hôte KVM ; la configuration d'un conteneur est plus liée à son hôte).

Le terrain de prédilection de LXC, en retour : le schéma des nombreux petits services. Un conteneur par service (DNS ici, reverse proxy là, un Postgres pour cette appli, une stack de monitoring), chacun snapshotable, sauvegardé, limité en ressources et redémarrable indépendamment, pour un coût par instance assez bas pour que « un service, un conteneur » soit une politique abordable. Les bind mounts ajoutent un super-pouvoir discret : monter des répertoires de l'hôte directement dans les conteneurs, sans système de fichiers réseau, une évidence pour un conteneur qui traite des données qui vivent sur le grand pool ZFS de l'hôte.

Une réserve de cluster à anticiper : la « migration » de conteneurs entre nœuds est une migration par redémarrage : arrêt, déplacement, démarrage (quelques secondes d'indisponibilité pour un conteneur léger, mais une indisponibilité tout de même). Le HA fonctionne de la même façon : les conteneurs d'un nœud en panne redémarrent ailleurs. Si un service ne peut pas le tolérer, sa place est dans une VM. C'est la question 3 qui fait son travail.

Le tableau de décision

Workload	Verdict	Pourquoi
Tout ce qui tourne sous Windows	VM	Noyau étranger, pas d'autre option
Base de données de production	VM (généralement)	Isolation, migration à chaud pour la maintenance, contrôle de la mémoire
Hôte Docker/Kubernetes	VM	Recommandation de Proxmox lui-même ; mises à niveau propres
Reverse proxy, DNS, outils internes	LXC	Petit, fiable, redémarrable : le point idéal
Services par application (serveurs de jeu, bots, runners)	LXC	Densité ; politique un service, un conteneur
Workloads non fiables / multi-tenants	VM	La frontière, c'est le produit
Transcodage GPU (Jellyfin, etc.)	VM + passthrough	VFIO est réservé aux VM
Appliance NAS/stockage	VM (passthrough HBA) ou LXC + bind mounts	Selon qu'elle possède les disques ou emprunte des chemins
Pare-feu/routeur (OPNsense)	VM	C'est du BSD, et vous voulez l'isoler de toute façon

Questions fréquentes

Puis-je convertir un conteneur en VM plus tard (ou inversement) ?

Il n'existe pas de conversion en un clic. Le contenu du disque est compatible (ce sont tous des systèmes de fichiers Linux), mais l'emballage diffère : une VM a besoin d'un noyau, d'un chargeur de démarrage et d'un init qu'une image de conteneur ne transporte pas. La voie pratique consiste à redéployer et migrer les données, ce qui est rarement pénible pour les petits services que les conteneurs hébergent. L'asymétrie mérite d'être notée au moment du déploiement : « commencer en VM, conteneuriser plus tard » ne coûte que des ressources, alors que « commencer en LXC, basculer vers une VM plus tard » coûte une migration. En cas de doute réel, la VM est le choix à peu près réversible.

LXC est-il vraiment plus rapide, et de combien ?

En calcul brut, à peine : KVM exécute les instructions CPU de l'invité avec assistance matérielle, si bien qu'une VM soumise à un calcul intensif reste à quelques pourcents du natif. Les différences honnêtes : le temps de démarrage (une seconde contre un démarrage d'OS complet), l'économie de mémoire (plafonds contre réservations : c'est de là que vient la densité), et la longueur du chemin d'E/S (l'E/S d'un conteneur est de l'E/S hôte ; l'E/S d'une VM traverse VirtIO, rapide mais pas gratuit). Si votre motivation est la « performance », mesurez d'abord ; si c'est « faire tenir 30 petits services sur une seule machine », LXC plaide sa cause tout seul.

Les conteneurs fonctionnent-ils avec le HA et le clustering de Proxmox ?

Oui, avec une différence de comportement : pas de migration à chaud. Déplacer un conteneur entre nœuds (pour maintenance, ou par le HA après une panne de nœud) se fait en stop-transfert-démarrage, prévoyez donc de quelques secondes à une minute d'indisponibilité par déplacement, plutôt que la bascule imperceptible dont bénéficient les VM. Pour la plupart des services de classe conteneur, c'est sans conséquence (et un HA qui redémarre votre conteneur DNS sur un nœud survivant vaut mieux que de le laisser hors service) ; là où ce n'est pas le cas, voyez la question 3 et utilisez une VM. La mécanique de cluster est couverte dans notre guide HA.

Faut-il tout simplement passer entièrement en VM, par souci de simplicité ?

C'est une simplification défendable (un seul modèle, l'isolation la plus forte partout, la migration à chaud pour tout), et si vos services sont peu nombreux et la RAM abondante, adoptez-la. Le coût, c'est la densité : les VM inactives réservent de la mémoire que des conteneurs inactifs ne réserveraient pas, si bien qu'un parc tout-VM demande un hôte plus grand pour le même workload. La plupart des opérateurs convergent vers le mélange que décrit cet article dès que le nombre de services augmente ; il n'y a pas de prix à la pureté, dans un sens comme dans l'autre.

Déployer chez Serverside

Les deux modèles veulent le même socle : cœurs, RAM et NVMe rapide. Nos serveurs dédiés Proxmox arrivent préinstallés et provisionnés en moins d'une minute sur l'ASN 55285, avec assez d'options de RAM pour faire tourner le parc tout-VM si c'est votre style, un réseau privé pour les configurations multi-nœuds, et du KVM-over-IP pour l'hôte lui-même. Dimensionnez la machine avec le guide de dimensionnement des serveurs (additionnez vos invités, la RAM est la contrainte), puis complétez avec le reste de la série : configuration initiale, réseau, et sauvegardes.