KVM ou LXC sur Proxmox : quand choisir une VM, quand choisir un conteneur

La grande force de Proxmox VE — et accessoirement sa plus grande source de confusion pour les nouveaux utilisateurs — c'est qu'il propose deux technologies de virtualisation sur le même hôte : les machines virtuelles KVM et les conteneurs Linux LXC. Sur le papier, on pourrait croire que c'est un choix de goût. En pratique, choisir l'un ou l'autre a des conséquences directes sur la sécurité, la densité, les performances et la maintenabilité de votre infrastructure.

Cet article remet à plat ce que fait réellement chaque technologie, où sont les vrais risques de sécurité (notamment le piège classique Docker-dans-LXC), comment configurer un LXC correctement, et donne une grille de décision en 5 questions pour ne plus jamais hésiter.

Ce que fait réellement chaque technologie

KVM : virtualisation complète

KVM (Kernel-based Virtual Machine) crée une machine virtuelle au sens strict : chaque VM a son propre noyau Linux (ou Windows, ou BSD), son propre kernel space, ses propres pilotes, sa propre table de processus. L'hyperviseur Proxmox parle au matériel via les extensions matérielles VT-x ou AMD-V, et la VM ne « voit » qu'un matériel virtualisé qui lui est dédié. L'isolation est binaire : ce qui se passe dans la VM ne déborde pas sur l'hôte, sauf vulnérabilité critique de QEMU/KVM (rarissime et patchée immédiatement).

LXC : conteneurs Linux natifs

LXC (Linux Containers) ne crée pas une machine virtuelle. Il crée un environnement isolé qui partage le noyau Linux de l'hôte Proxmox via les mécanismes natifs du kernel : namespaces (PID, réseau, mount, user, UTS, IPC) et cgroups. Le conteneur a sa propre table de processus, ses propres interfaces réseau virtuelles, son propre système de fichiers — mais quand un processus du conteneur fait un appel système, c'est le noyau de l'hôte qui répond.

Le partage de noyau : avantage et risque

Le partage du noyau est ce qui rend les LXC si légers. Pas de second OS à booter, pas de RAM réservée pour un kernel invité, pas d'overhead de virtualisation matérielle. Un conteneur Debian minimal démarre en 2 secondes et consomme 50 à 80 Mo de RAM au repos. Sur un hôte 32 Go, on peut faire tourner facilement 30 services indépendants dans 30 LXC distincts.

Le piège Docker dans LXC

C'est probablement la mauvaise pratique la plus répandue dans l'écosystème Proxmox amateur : créer un LXC Debian, y installer Docker, puis y faire tourner toute la stack applicative en Docker Compose. Techniquement, ça marche. Officiellement, ce n'est ni supporté ni recommandé par les développeurs Proxmox.

Pourquoi ? Parce qu'on empile alors deux couches de partage de noyau (LXC + Docker), ce qui multiplie les vecteurs d'évasion. De plus, Docker a besoin de capabilities Linux que les LXC unprivileged ne donnent pas — il faut donc soit utiliser un LXC privileged (mauvaise idée sécurité), soit activer des `lxc.cap.keep` qui élargissent la surface d'attaque, soit jouer avec `fuse-overlayfs` qui dégrade les performances I/O.

Privileged vs unprivileged et AppArmor

Unprivileged (recommandé par défaut)

• Le root du conteneur (UID 0) est mappé sur un UID non-privilégié de l'hôte (typiquement 100000).
• Une évasion vers l'hôte ne donne aucun privilège réel.
• Profil AppArmor restrictif appliqué automatiquement.
• Limitation : certains montages exotiques (NFS root, FUSE) demandent une configuration supplémentaire.

Privileged (à éviter sauf cas exceptionnel)

• Le root du conteneur reste UID 0 sur l'hôte.
• Une vulnérabilité dans un service en root du LXC donne directement le contrôle root de l'hôte.
• À réserver aux conteneurs système où vous contrôlez 100 % du code et acceptez le risque.
• Ne jamais utiliser pour héberger une application publique exposée à Internet.

# Verifier le mode d'un LXC existant (extrait de /etc/pve/lxc/100.conf)
cat /etc/pve/lxc/100.conf | grep -E 'unprivileged|features'

# Sortie attendue pour un unprivileged :
# unprivileged: 1
# features: nesting=0

Empreinte mémoire et CPU : chiffres concrets

Les comparaisons théoriques restent abstraites. Voici quelques mesures réelles prises sur un hôte Proxmox 8 avec Debian 12 comme guest, au repos après initialisation complète des services.

Vaultwarden (gestionnaire de mots de passe Bitwarden)

• LXC unprivileged Debian — 80 à 130 Mo RAM, 0,1 % CPU au repos. Démarrage en 3 secondes.
• VM KVM Debian — 480 à 600 Mo RAM (dont 350 pour le noyau et systemd invités), 0,3 % CPU. Démarrage en 25 secondes.

Nextcloud (avec PHP-FPM + Nginx + cache OPcache)

• LXC unprivileged — 250 à 400 Mo RAM au repos, monte à 1,2 Go en charge sur 10 utilisateurs simultanés.
• VM KVM — 700 Mo à 1 Go RAM au repos, 1,8 Go en charge équivalente.

PostgreSQL 16 (instance dédiée, shared_buffers 512 Mo)

• LXC — 550 à 700 Mo RAM. Mais isolation faible : à éviter pour un Postgres critique multi-tenant.
• VM KVM — 1,1 à 1,3 Go RAM. Isolation totale, recommandée pour la production.

Grille de décision en 5 questions

1. Le service va-t-il manipuler des données critiques ou être exposé à Internet ? → VM KVM (isolation forte).
2. Avez-vous besoin de faire tourner Docker, Kubernetes, ou un OS autre que Linux ? → VM KVM obligatoire.
3. Le service est-il un démon Linux simple, contrôlé par vous, à empreinte mémoire faible ? → LXC unprivileged.
4. Cherchez-vous à maximiser la densité (20+ services sur un même hôte) ? → LXC unprivileged, en assumant le risque kernel.
5. Le service va-t-il nécessiter un passthrough matériel (GPU, USB, carte PCIe) ? → VM KVM, le seul mode supporté proprement.

Règles de pouce par typologie de service

• Base de données productive (Postgres, MySQL, MongoDB) — VM KVM dédiée.
• Reverse proxy / WAF (Nginx, Traefik, Caddy) — LXC unprivileged, ou VM si en frontal Internet exposé.
• Application web stateless (Nextcloud, Vaultwarden, BookStack, Outline) — LXC unprivileged.
• Services réseau d'infrastructure (DNS, DHCP, RADIUS) — LXC unprivileged.
• Médias et transcodage (Jellyfin, Plex avec accélération matérielle GPU) — VM KVM avec passthrough.
• Domotique critique (Home Assistant avec Zigbee USB) — VM KVM avec passthrough USB.
• Environnement de dev ou test à isoler fort — VM KVM jetable.
• Tout ce qui demande Docker — VM KVM, jamais LXC.

Conclusion

KVM et LXC ne sont pas concurrents : ils sont complémentaires. Un hôte Proxmox bien architecturé mélange typiquement quelques VMs lourdes (bases de données, services Docker, plateformes critiques) avec une majorité de LXC unprivileged pour tout ce qui est démon Linux léger et contrôlable. C'est cette dualité, et la facilité avec laquelle Proxmox permet de basculer de l'un à l'autre, qui en fait un outil au-dessus de la concurrence pour bâtir un cloud privé souverain.

Une fois la bonne technologie choisie pour chaque service, la priorité suivante devient la sauvegarde — qui ne pardonne aucune erreur d'architecture. Le guide PBS détaille comment protéger l'ensemble du parc, VMs comme LXC, avec déduplication, rétention multi-niveaux et résistance aux ransomware.