Proxmox VE s’est imposé comme une plateforme incontournable pour les administrateurs système, les laboratoires domestiques et les entreprises recherchant une alternative ouverte à la virtualisation. Son attrait ne se limite pas à la création de machines virtuelles avec KVM, mais s’étend à la gestion combinée de plusieurs blocs d’infrastructure : calcul, stockage, réseau, clusters, sauvegardes et conteneurs Linux, le tout via une interface unique.

Parmi ces composants, les Linux Containers, plus connus sous le nom de LXC, occupent une place particulière. Il ne s’agit ni de machines virtuelles traditionnelles ni de conteneurs d’applications à la Docker. Ce sont des conteneurs de système d’exploitation : des environnements Linux isolés qui partagent le noyau de l’hôte, mais disposent de leur propre système de fichiers, processus, réseau, utilisateurs et services. Avec Proxmox, cela permet de déployer des charges très légères, rapides à démarrer et faciles à gérer depuis la même console que celle utilisée pour les machines virtuelles.

Qu’est-ce que LXC dans Proxmox ?

LXC est une technologie de virtualisation de niveau système d’exploitation. Contrairement à une machine virtuelle complète, qui émule du matériel et exécute son propre noyau, un conteneur LXC partage le noyau de l’hôte Proxmox. Cette différence technique explique presque toutes ses avantages et ses limitations.

Un conteneur LXC consomme moins de ressources qu’une VM car il n’a pas besoin de démarrer un système d’exploitation complet desde zéro. Il n’y a pas de BIOS virtuel, pas de noyau invité indépendant, ni de couche complète de virtualisation matérielle. Le résultat : un démarrage plus rapide, une consommation mémoire inférieure et une densité accrue de services par nœud.

Proxmox facilite grandement l’usage de LXC. L’interface web permet de télécharger des templates, de créer des conteneurs, d’allouer CPU, mémoire, disque, réseau, DNS, mot de passe, clés SSH et stockage. En ligne de commande, la commande principale est pct, qui sert à créer, démarrer, arrêter, cloner, migrer, prendre des snapshots ou accéder à un conteneur.

Chaque conteneur repose sur une template. Celle-ci contient le système de fichiers d’une distribution Linux (Debian, Ubuntu, AlmaLinux, Rocky Linux, Fedora ou Alpine, selon disponibilité). Lors de la création, Proxmox clone cette template sur le stockage choisi, générant ainsi un environnement Linux isolé en quelques secondes.

Un exemple simplifié de création en ligne de commande serait :

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

Le conteneur peut ensuite être démarré avec :

pct start 101

Et accessible via :

pct enter 101

Cette simplicité explique en partie pourquoi LXC s’intègre si bien dans Proxmox. Un administrateur peut déployer en quelques minutes un serveur Nginx, un proxy, un DNS interne, un conteneur de monitoring, un petit service PHP, une base légère ou un outil administratif, sans réserver autant de ressources qu’une VM complète.

Privilegié vs non privilegié : le choix sécuritaire

Un des choix clés lors de la création d’un conteneur LXC dans Proxmox concerne sa configuration en mode privilégié ou non privilégié. En règle générale, dans les environnements modernes, il est conseillé de privilégier les conteneurs non privilégiés quand cela est possible.

Un conteneur privilégié associe le root du conteneur directement au root de l’hôte. Cela facilite certaines opérations, comme le montage de dispositifs ou l’accès à certains périphériques, mais augmente le risque en cas de compromission. À l’inverse, un conteneur non privilégié utilise des user namespaces pour mapper les utilisateurs internes à des identifiants sans droits sur l’hôte, faisant en sorte que le root du conteneur ne soit pas égal au root du nœud hôte.

La recommandation générale est d’utiliser des conteneurs non privilégiés pour les services standards, en réservant le mode privilégié pour les cas nécessitant des accès spécifiques ou dispositifs. Si un service demande des permissions particulières, du montage NFS/SMB ou Docker dans LXC, il convient d’évaluer si une VM offrirait un meilleur niveau de sécurité.

Mention spéciale à Docker dans LXC : cela reste possible dans certains scénarios mais peut poser des problèmes liés aux permissions, AppArmor, cgroups, stockage overlay ou mises à jour. En production, beaucoup d’administrateurs préfèrent exécuter Docker dans une VM dédiée, surtout si la charge est critique.

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

LXC excelle lorsque le besoin est de déployer de nombreux services Linux légers et bien séparés. Il ne remplace pas toutes les VM mais permet une réduction de consommation et une simplification opérationnelle dans diverses situations.

Pour les laboratoires et petites infrastructures, LXC permet de séparer les services sans gaspiller de ressources. Un nœud doté de 64 Go de RAM peut héberger bien plus de charges légères en conteneurs qu’en VM, dès lors que la gestion du stockage, du réseau et des sauvegardes est bien conçue.

Dans un contexte professionnel, l’usage doit être plus sélectif. LXC est utile pour les services auxiliaires, outils internes, composants d’infrastructure et charges Linux contrôlées. Pour des applications critiques, des environnements réglementés ou multi-tenant, les VM restent une option plus prudente en matière de sécurité.

Le stockage doit également être planifié dès le départ. Proxmox permet de créer des systèmes de fichiers racine (rootfs) de conteneurs sur divers backend : LVM, ZFS, Ceph, NFS ou répertoire local, selon la conception du cluster. Ce choix impacte la gestion des snapshots, la réplication, la performance et la migration. Par exemple, ZFS offre une gestion rapide des snapshots et clones localement, tandis que Ceph est adapté pour un stockage distribué en cluster, bien qu’il demande une configuration plus élaborée.

Les sauvegardes intégrées avec Proxmox utilisent vzdump, et avec Proxmox Backup Server, on profite de déduplication, compression, chiffrement et sauvegardes incrémentielles. Pour LXC, cela facilite la protection ordonnée de services nombreux et légers, souvent sans scripts dispersés.

En réseau, un conteneur est généralement connecté à un bridge comme vmbr0, similaire à une VM. Le DHCP ou une IP statique peuvent être utilisés, avec VLANs et règles de pare-feu. En environnement segmenté, il est conseillé de considérer chaque conteneur comme une unité de sécurité : n’attribuer que le réseau nécessaire, limiter l’exposition, activer le pare-feu au besoin et éviter de partager des répertoires du hôte sans raison valable.

Bonnes pratiques pour la production

LXC ne doit pas être utilisé comme une solution rapide pour héberger n’importe quoi. Son efficacité peut entraîner une création excessive de conteneurs sans contrôle, complexifiant maintenance, mises à jour et sécurité. La meilleure approche consiste à définir le rôle de chaque conteneur et à le documenter, comme pour une VM.

Utiliser des templates à jour, créer des conteneurs non privilégiés par défaut, limiter leurs ressources, séparer stockage de données et sauvegardes, planifier la sauvegarde dès le départ, et consulter régulièrement les logs de Proxmox et du système invité, constituent des pratiques recommandées. Éviter également les “contendors mascottes” chargés de multiples services, qui devraient plutôt faire l’objet d’une segmentation ou d’une VM dédiée si l’ensemble devient trop complexe.

La distinction entre LXC et VM ne doit pas se voir comme une opposition technique, mais comme deux outils complémentaires. LXC offre rapidité, densité et efficacité pour les charges Linux, tandis que KVM garantit un isolement plus robuste et une compatibilité étendue. Proxmox excelle précisément en permettant d’utiliser les deux dans une même plateforme.

Dans une architecture avancée, il est courant de combiner ces deux approches : VM pour les charges critiques, Windows, appliances ou bases de données, et LXC pour les services Linux secondaires, les applications légères, le monitoring, les DNS ou l’automatisation. Cette hybridation optimise l’utilisation du matériel tout en maintenant un contrôle opératif optimal.

Proxmox et LXC constituent une alliance particulièrement efficace, car ils rendent la conteneurisation de système d’exploitation accessible aux administrateurs qui ne souhaitent pas se limiter à Kubernetes ou Docker pour tout gérer. Pour nombre d’organisations, la priorité n’est pas de micro-service à outrance ou de déployer des clusters complexes, mais de bien séparer les charges Linux, réduire leur coût et simplifier la gestion. LXC prend tout son sens dans cette optique.

L’essentiel est de savoir quand ne pas s’en servir. Un conteneur n’est pas une VM allégée : il partage le noyau, hérite de certaines décisions du host, et nécessite une bonne compréhension des permissions, namespaces, stockage et sécurité. Lorsqu’on approche cet outil avec cette connaissance, il devient une ressource très efficace. Lorsqu’on le considère comme un raccourci, il peut engendrer plus de problèmes qu’il n’en résout.

Questions fréquentes

Qu’est-ce que LXC dans Proxmox ?
LXC est une technologie de conteneurs Linux permettant d’exécuter, dans Proxmox, des environnements Linux isolés partageant le noyau du nœud hôte.

En quoi LXC diffère-t-il d’une machine virtuelle ?
Une VM virtualise le matériel et possède son propre noyau, tandis qu’un conteneur LXC partage celui de l’hôte, consommant moins de ressources, mais avec une isolation moindre.

Est-il possible d’exécuter Windows dans un conteneur LXC ?
Non. LXC dans Proxmox est conçu pour des distributions Linux. Pour Windows ou autres OS, il faut utiliser une VM.

Est-ce sûr d’utiliser LXC en production ?
Cela peut l’être si l’on privilégie des conteneurs non privilégiés, si l’on limite les permissions, si l’on configure les sauvegardes et si l’on segmente bien le réseau. Pour des charges critiques ou multi-tenant, la VM demeure souvent plus adaptée.