VM ou LXC : comment choisir sur Proxmox

Tu as installé Proxmox, tu ouvres l’interface web, et deux boutons t’attendent en haut à droite : Create VM (créer une machine virtuelle) et Create CT (créer un conteneur). Deux boutons, deux technologies, et une question que tout le monde se pose au début : c’est quoi la différence, et lequel des deux boutons dois-je choisir : VM ou CT ?

La réponse courte, sans suspense : une VM est un ordinateur complet simulé dans ton serveur, un conteneur LXC est un environnement Linux isolé qui partage le moteur de ton serveur. La VM est plus lourde mais plus étanche et plus polyvalente. Le LXC est plus léger et plus rapide, mais réservé à Linux.

Dans cet article, on fait le tour complet de la question : comment chacun fonctionne, ce que ça change concrètement en ressources et en sécurité, et surtout — comment décider en trente secondes lequel utiliser pour ton prochain service. Le tout en restant dans l’interface web de Proxmox, sans ligne de commande.

Si tu as suivi les articles précédents, tu as déjà utilisé les deux sans forcément le savoir : Pi-hole tourne dans un LXC, Linux Mint dans une VM. À la fin de cet article, tu sauras exactement pourquoi.

La VM : un ordinateur complet dans ton ordinateur

Une machine virtuelle (VM), c’est exactement ce que son nom dit : un ordinateur entier, simulé par logiciel à l’intérieur de ton serveur. Quand tu crées une VM dans Proxmox, tu fabriques un PC virtuel de toutes pièces : son propre BIOS, son propre disque dur virtuel, sa propre carte réseau virtuelle, sa propre mémoire réservée.

Et surtout : son propre système d’exploitation complet, installé depuis zéro comme sur un vrai PC. C’est pour ça que créer une VM commence toujours par télécharger une image ISO — le fameux fichier d’installation. Linux Mint, Debian, Windows, peu importe : la VM ne sait même pas qu’elle est virtuelle. Elle croit tourner sur du vrai matériel.

Sous le capot, Proxmox utilise KVM/QEMU : KVM est le module de virtualisation intégré au noyau Linux, QEMU s’occupe de simuler le matériel. Tu n’as pas besoin de retenir ces noms pour l’utiliser — mais tu les croiseras dans l’interface, notamment dans la colonne « Type » où tes VMs apparaissent comme qemu.

L’image la plus juste : la VM est une maison indépendante. Ses propres murs, sa propre plomberie, son propre compteur électrique. Ce qui se passe dedans reste dedans : si une VM plante ou se fait compromettre, les autres et le serveur hôte ne voient rien. Cette indépendance a un prix : chaque maison doit être construite entièrement, avec sa propre fondation — le système d’exploitation complet — qui consomme de la RAM et du disque avant même que ton service ne démarre.

Concrètement : ta VM Linux Mint embarque un noyau Linux complet, tous les services système de Mint, une interface graphique — plusieurs gigaoctets de disque et au moins 2 Go de RAM, juste pour exister. Le service que tu fais tourner dessus s’ajoute par-dessus.

Le LXC : un conteneur qui partage le moteur de ton serveur

Un conteneur LXC (Linux Containers), c’est une approche radicalement différente. Au lieu de simuler un ordinateur complet, le conteneur réutilise le noyau Linux de ton serveur Proxmox. Pas de BIOS virtuel, pas de matériel simulé, pas de système d’exploitation installé depuis zéro : le conteneur ne contient que ce qui est propre à lui — ses fichiers, ses applications, sa configuration.

C’est pour ça que créer un CT ne passe pas par une ISO mais par un template : une archive légère qui contient juste l’environnement d’une distribution (Debian, Ubuntu, Alpine…), sans le noyau. Le noyau, c’est celui de Proxmox qui le fournit, en direct.

Pour reprendre notre image : si la VM est une maison indépendante, le LXC est un appartement dans un immeuble. Il a sa porte qui ferme à clé, ses propres meubles, son propre agencement — mais il partage les fondations, la structure porteuse et le compteur général avec tous les autres appartements. Résultat : construire un appartement coûte infiniment moins cher que construire une maison, et c’est immédiat.

Concrètement, ça donne quoi ? Ton conteneur Pi-hole démarre en deux ou trois secondes, là où une VM met une à deux minutes. Côté mémoire, les chiffres parlent d’eux-mêmes : le Pi-hole de ce blog consomme 53 Mo de RAM en fonctionnement, sur les 512 Mo qui lui sont alloués — là où la moindre VM en réclame 2 Go rien que pour exister. Et son disque occupe quelques centaines de Mo au lieu de plusieurs Go. Sur un serveur modeste, la différence n’est pas cosmétique : c’est ce qui te permet de faire tourner dix services au lieu de trois.

L’isolation, elle, est assurée par des mécanismes du noyau Linux lui-même — chaque conteneur est cloisonné dans son propre espace : il voit ses propres processus, son propre réseau, ses propres utilisateurs, et rien des autres. C’est une vraie isolation, mais avec une nuance de taille qu’on détaillera dans le comparatif : les appartements partagent la structure de l’immeuble. Si la structure a un défaut, tout l’immeuble est concerné.

Attention à la confusion classique : LXC n’est pas Docker. Les deux utilisent les mêmes mécanismes du noyau, mais la philosophie diverge. Un LXC est un conteneur système : il se comporte comme une petite machine Linux complète et durable, dans laquelle tu te connectes, installes et mets à jour des paquets, comme sur un serveur classique. Docker est un conteneur applicatif : une seule application par conteneur, jetable et reconstruit à chaque mise à jour. Dans Proxmox, quand tu cliques sur Create CT, c’est du LXC — Docker est un autre sujet, pour un autre article.

Une conséquence directe du partage de noyau, et elle est sans appel : un LXC ne peut faire tourner que du Linux. Le noyau est celui de l’hôte, donc pas de Windows en conteneur, jamais. Besoin de Windows ou d’un autre OS ? C’est une VM, fin de la discussion.

VM vs LXC : le comparatif franc

Maintenant que tu sais comment chacun fonctionne, posons les différences côte à côte. Pas de gagnant universel ici — chaque colonne a ses cas d’usage.

La question qui fâche : la sécurité

Soyons directs : une VM est mieux isolée qu’un conteneur, point. La VM ne partage rien avec l’hôte à part le processeur physique — pour la compromettre depuis l’intérieur puis atteindre ton serveur, un attaquant doit traverser toute la couche de virtualisation. C’est rare et difficile.

Le LXC, lui, partage le noyau. Une faille dans le noyau Linux exploitée depuis un conteneur peut, en théorie, toucher l’hôte. C’est l’immeuble : un défaut dans la structure porteuse concerne tous les appartements.

Ça ne veut pas dire que le LXC est une passoire. Proxmox crée par défaut des conteneurs unprivileged — non privilégiés : le compte root à l’intérieur du conteneur correspond à un utilisateur ordinaire sans aucun droit à l’extérieur, sur l’hôte. Même si un attaquant devient root dans ton conteneur Pi-hole, côté serveur il n’est qu’un utilisateur lambda. Garde ce défaut : ne passe un conteneur en « privileged » que si tu as une raison documentée de le faire — et dans le doute, c’est qu’il n’y en a pas.

La règle pratique qui en découle : plus un service est exposé ou sensible, plus la VM se justifie. Un service interne à ton réseau comme Pi-hole vit très bien en LXC unprivileged. Un service exposé à Internet ou qui manipule des données critiques mérite de réfléchir à une VM.

Le cas particulier : Docker

Tu croiseras vite la question « je mets mon Docker dans un LXC ou dans une VM ? ». La position officielle de Proxmox est claire : les conteneurs applicatifs comme Docker sont à faire tourner dans une VM, pas dans un LXC. Empiler des conteneurs Docker dans un conteneur LXC fonctionne parfois, au prix de bricolages de configuration qui cassent régulièrement lors des mises à jour de Proxmox. Une petite VM Debian dédiée à Docker t’épargne tout ça. Retiens juste ce principe pour le moment — Docker aura son propre article.

Ce que ça coûte vraiment sur ton serveur

Dernier point, le plus concret : la densité. Une VM réserve sa RAM : tu lui donnes 2 Go, ils sont pris, qu’elle les utilise ou non. Un LXC partage les ressources de l’hôte : il ne consomme que ce qu’il utilise réellement. Sur une machine avec 16 Go de RAM, ça se traduit par une poignée de VMs… ou des dizaines de conteneurs. Pour un homelab sur matériel modeste, c’est souvent l’argument qui tranche.

Comment décider en trente secondes

Toute la théorie ci-dessus tient en trois questions. Tu les poses dans l’ordre, et tu t’arrêtes à la première qui répond « oui ».

Question 1 — Ton service a besoin d’autre chose que Linux ?

Windows, BSD, macOS, peu importe : si ce n’est pas du Linux, c’est une VM, obligatoirement. Un LXC utilise le noyau Linux de ton serveur — il ne peut rien faire tourner d’autre. Pas de contournement possible.

Question 2 — C’est un poste de travail complet, Docker, ou un service exposé à Internet ?

Dans les trois cas : VM.

• Un poste de travail — un système avec bureau graphique que tu utilises comme un vrai PC (Linux Mint, Ubuntu Desktop…) — est fait pour la VM : tu veux une machine entière, pas un service en arrière-plan. Attention, c’est l’usage qui compte, pas la distribution : le même Ubuntu en version serveur, sans bureau, tourne très bien en conteneur.
• Docker : recommandation officielle de Proxmox — l’alternative en LXC existe mais repose sur des bricolages qui cassent au fil des mises à jour.
• Un service exposé à Internet : ce qui est accessible depuis l’extérieur est une cible, et une cible mérite l’isolation la plus forte.

Question 3 — Tu as répondu non aux deux premières ?

Alors c’est un service Linux, interne à ton réseau — le cas de l’immense majorité des services d’un homelab. Réponse : LXC unprivileged, le choix par défaut. Léger, rapide à démarrer, suffisamment isolé pour un service interne, et c’est ce qui permet à un serveur modeste d’héberger dix services au lieu de trois.

En une phrase : LXC par défaut ; VM dès que Windows, un bureau graphique, Docker ou l’exposition à Internet entrent en jeu.

Vérifie avec ce que tu connais déjà. Pi-hole : Linux, interne → LXC, c’est bien ce qu’on a fait. Linux Mint avec son bureau graphique : un OS complet à tester, pas un simple service → VM, logique aussi. La règle fonctionne.

Où ça se voit dans l’interface web

Tout ce qu’on vient de voir se retrouve directement dans l’interface de Proxmox. Petit tour du propriétaire.

Les deux boutons. En haut à droite de l’interface, en permanence : Create VM (créer une machine virtuelle) et Create CT (créer un conteneur — CT pour container). Deux boutons, deux mondes.

Le point de départ n’est pas le même. La différence de philosophie se voit avant même de créer quoi que ce soit : dans ce que tu dois préparer.

Pour une VM, il te faut une image ISO — le fichier d’installation complet d’un système d’exploitation, celui que tu graverais sur une clé USB pour un vrai PC. Les ISO se gèrent dans le stockage : sélectionne local dans l’arborescence de gauche, puis ISO Images. Deux façons d’en ajouter : Upload si le fichier est déjà sur ton PC, Download from URL pour que Proxmox le télécharge directement — plus rapide, pas de transfert depuis ta machine.

Au moment de créer la VM, l’assistant te demande cette ISO dans l’onglet OS — tu la retrouves dans le menu déroulant, il n’y a qu’à la sélectionner. Tu devras ensuite dérouler l’installation du système, écran par écran, comme sur une machine physique.

Pour un CT, il te faut un template — une archive prête à l’emploi, sans installation à dérouler. Même logique de rangement : stockage local, section CT Templates, puis bouton Templates.

Proxmox te propose alors une liste de distributions maintenues — Debian, Ubuntu, Alpine, Fedora et bien d’autres. Un clic, un téléchargement de l’ordre de la centaine de Mo (compare avec les 3 Go d’une ISO Linux Mint : la différence de philosophie, déjà), et le template est disponible pour tous tes futurs conteneurs.

Au moment de créer le conteneur, l’assistant te demande ce template dans l’onglet Template — et c’est tout : le conteneur sera utilisable dès la fin de l’assistant, en quelques secondes.

Les options trahissent la mécanique. Dans l’assistant Create CT, tu retrouves la case Unprivileged container — cochée par défaut, on a vu pourquoi. Laisse-la cochée. Dans Create VM, tu croiseras à l’inverse des onglets entiers dédiés au matériel simulé : BIOS, type de machine, contrôleur SCSI, carte graphique… Autant de choses qu’un conteneur n’a tout simplement pas, puisqu’il ne simule aucun matériel.

Et une fois créés ? Dans la colonne Type des vues de recherche, tes VMs apparaissent comme qemu, tes conteneurs comme lxc — les deux technologies qu’on a vues en début d’article, noir sur blanc dans l’interface.

Au quotidien, en revanche, VMs et conteneurs se pilotent exactement pareil : démarrer, arrêter, sauvegarder, snapshots, console — mêmes menus, mêmes gestes. C’est une des forces de Proxmox : deux technologies très différentes sous le capot, une seule interface pour les vivre.

En résumé : deux outils, un seul réflexe

Tu sais maintenant ce qui se cache derrière les deux boutons bleus. La VM : un ordinateur complet simulé, avec son propre noyau — plus lourde, mieux isolée, capable de tout faire tourner. Le LXC : un environnement Linux qui partage le noyau de ton serveur — léger, quasi instantané, mais Linux uniquement.

Et surtout, tu as le réflexe : LXC unprivileged par défaut ; VM dès que Windows, un bureau graphique, Docker ou l’exposition à Internet entrent en jeu. Trois questions, trente secondes, décision prise.

La meilleure façon d’ancrer tout ça, c’est de pratiquer les deux :

• Côté conteneur : Pi-hole sur Proxmox en LXC — ton premier service utile, et tu comprendras maintenant chaque choix de l’assistant Create CT.
• Côté machine virtuelle : Installer Linux Mint sur Proxmox : ta première machine virtuelle pas à pas — un OS complet dans une VM, installation ISO comprise.

La suite logique de la série : maintenant que tu sais choisir entre VM et conteneur, on va s’en servir pour construire. Prochaine étape : déployer des services qui rendent ton homelab réellement utile au quotidien.

Ta tech, tes règles, ta liberté.