Proxmox VE gère deux technologies d’isolation fondamentalement différentes : les machines virtuelles KVM et les conteneurs Linux LXC. Les deux s’administrent depuis la même interface, mais leur logique interne diverge, ce qui rend le choix entre l’un et l’autre bien moins évident qu’il n’y paraît. Bien comprendre cette différence, c’est éviter de gaspiller des ressources en exécutant des VM là où un conteneur suffit, ou au contraire de se retrouver avec une surface de sécurité insuffisante pour des charges sensibles.

Qu’est-ce que LXC dans Proxmox ?

LXC est une technologie de virtualisation au niveau du système d’exploitation. Contrairement à une machine virtuelle KVM, qui émule du matériel et fait tourner son propre noyau, un conteneur LXC partage le noyau de l’hôte Proxmox. Il n’y a pas de BIOS virtuel, pas de noyau invité indépendant, pas de couche de virtualisation matérielle. Le résultat : démarrage plus rapide, consommation mémoire inférieure et plus de services par nœud.

Proxmox simplifie beaucoup la gestion LXC. L’interface web permet de télécharger des templates, de créer des conteneurs, d’allouer CPU, mémoire, disque, réseau et clés SSH. En ligne de commande, la commande principale est pct. Exemple de création :

pct create 101 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst 
  --hostname web-lxc-01 
  --cores 2 
  --memory 2048 
  --rootfs local-lvm:20 
  --net0 name=eth0,bridge=vmbr0,ip=dhcp 
  --unprivileged 1

Ensuite :

pct start 101
pct enter 101

En quelques minutes, un serveur Nginx, un proxy, un DNS interne, un outil de monitoring ou une interface d’administration est opérationnel, sans réserver autant de ressources qu’une VM complète.

Privilégié vs non privilégié : le choix sécuritaire

Un conteneur privilégié associe le root du conteneur au root de l’hôte. Cela facilite certaines opérations (montage de périphériques, accès à certains dispositifs), mais augmente le risque en cas de compromission. Un conteneur non privilégié utilise des user namespaces pour mapper les utilisateurs internes à des identifiants sans droits sur l’hôte.

La recommandation générale est de défaut sur le mode non privilégié et de réserver le mode privilégié aux cas nécessitant des accès matériels spécifiques. Cette logique rejoint les questions de sécurité matérielle en profondeur : la controverse autour d’AMD TSME rappelle que le chiffrement mémoire au niveau processeur est une couche supplémentaire que les environnements Proxmox sur Ryzen ne bénéficient pas nécessairement par défaut.

Docker dans LXC reste possible mais pose souvent des problèmes liés aux permissions, AppArmor, cgroups et stockage overlay. En production, beaucoup d’administrateurs préfèrent exécuter Docker dans une VM dédiée, surtout pour des charges critiques.

Cas d’usage : où LXC est particulièrement adapté

Pour les laboratoires et petites infrastructures, LXC permet de séparer les services sans gaspiller de ressources. Un nœud avec 64 Go de RAM héberge bien plus de charges légères en conteneurs qu’en VM, à condition que le stockage, le réseau et les sauvegardes soient bien conçus dès le départ.

Le stockage mérite une attention particulière. Proxmox supporte plusieurs backends pour le rootfs des conteneurs : LVM, ZFS, Ceph, NFS ou répertoire local. ZFS offre une gestion rapide des snapshots et clones en local ; Ceph convient mieux au stockage distribué en cluster. Le choix du support physique a son importance : la durée de vie des SSD sous des écritures soutenues influe sur la sécurité des données des conteneurs.

Bonnes pratiques en production

LXC ne doit pas devenir une solution rapide pour entasser des services sans contrôle. Son efficacité peut conduire à créer trop de conteneurs, ce qui complexifie la maintenance, les mises à jour et la sécurité. La bonne approche : définir le rôle de chaque conteneur et le documenter, comme pour une VM.

La distinction LXC/VM n’est pas une opposition technique, c’est deux outils complémentaires. KVM garantit un isolement robuste et une compatibilité étendue. LXC offre rapidité, densité et efficacité pour les charges Linux. Proxmox excelle précisément en permettant d’utiliser les deux depuis la même plateforme.

Dans une architecture typique : VM pour les charges critiques, Windows, appliances ou bases de données, et LXC pour les services Linux secondaires, le monitoring, les DNS et l’automatisation. Cette hybridation optimise l’utilisation du matériel tout en gardant un contrôle opérationnel clair.

Questions fréquentes sur LXC dans Proxmox

Qu’est-ce que LXC dans Proxmox ?

LXC est une technologie de conteneurs Linux qui permet d’exécuter des environnements Linux isolés partageant le noyau du nœud hôte. Contrairement à une VM, il ne virtualise pas le matériel, ce qui le rend plus léger et plus rapide à démarrer.

En quoi LXC diffère-t-il d’une machine virtuelle ?

Une VM virtualise le matériel et possède son propre noyau, ce qui lui permet de faire tourner n’importe quel système d’exploitation. Un conteneur LXC partage le noyau de l’hôte, consomme moins de ressources mais offre une isolation moins forte.

Peut-on exécuter Windows dans un conteneur LXC ?

Non. LXC dans Proxmox est conçu exclusivement pour des distributions Linux. Pour Windows, BSD ou tout autre système, il faut utiliser une VM KVM.

LXC est-il sûr à utiliser en production ?

Oui, si on privilégie les conteneurs non privilégiés, si on limite les permissions, si on configure les sauvegardes et si on segmente correctement le réseau. Pour des charges critiques ou des environnements multi-tenant, la VM reste souvent plus adaptée.

Quels services conviennent le mieux à LXC ?

Serveurs web légers (Nginx, Apache), DNS interne (Pi-hole, Unbound), proxy inverse (Traefik, HAProxy), monitoring (Prometheus, Grafana), outils d’administration et services Linux standards. Docker peut fonctionner dans LXC mais se gère mieux dans une VM dédiée.