Proxmox LXC ou VM pour héberger Docker avec passthrough USB ou GPU : lequel est le plus facile à gérer ?
Choisissez un conteneur LXC Proxmox pour l’hôte Docker lorsque les nœuds de périphérique Linux peuvent être exposés en toute sécurité, que l’hôte possède les pilotes GPU ou USB requis et que la faible consommation de ressources ou le partage du GPU est important. Choisissez une VM lorsque le système invité doit gérer sa propre pile de pilotes, qu’un périphérique PCI doit être isolé via IOMMU ou que Docker et son accès au matériel doivent rester indépendants de l’hôte Proxmox. Les périphériques USB série conviennent souvent aux deux options ; le passthrough exclusif d’un GPU favorise généralement une VM.
Définir le « passthrough » avant de comparer LXC et une VM
LXC et KVM ne transmettent pas le matériel aux charges de travail de la même manière. Un conteneur LXC partage le noyau Proxmox, qui lui accorde généralement l’autorisation d’accéder aux nœuds de périphérique créés par l’hôte, comme `/dev/dri`, `/dev/ttyUSB0` ou `/dev/bus/usb`. L’hôte continue de détecter le matériel et de charger le pilote du noyau.
Une VM exécute son propre noyau. Proxmox peut émuler un périphérique USB, connecter un périphérique ou un port USB sélectionné, ou attribuer un périphérique PCI via VFIO et IOMMU. Le système invité charge alors son propre pilote et traite le matériel attribué davantage comme un périphérique installé directement.
Le guide actuel de configuration d’un NAS Proxmox de ZimaSpace présente les deux types de systèmes invités. Cet article limite la décision à un hôte Docker dont les conteneurs ont besoin de dongles USB, d’adaptateurs série, de GPU multimédias ou d’accélérateurs de calcul.
| Critère de décision | Docker dans un LXC Proxmox | Docker dans une VM |
|---|---|---|
| Noyau | Partage le noyau de l’hôte Proxmox | Exécute un noyau invité indépendant |
| Accès USB | Expose les nœuds de périphérique de l’hôte et leurs autorisations | Connecte le périphérique ou le port USB sélectionné au système invité |
| Accès au GPU | Partage généralement le pilote chargé par l’hôte et les périphériques de rendu | Peut recevoir un périphérique PCI exclusif via VFIO |
| Surcoût en ressources | Moins de ressources mémoire et de stockage consommées | Mémoire et espace disque supplémentaires pour le système invité |
| Isolation | Couplage plus étroit à l’hôte et frontière de noyau partagée | Séparation plus poussée des pilotes et du noyau |
| Portabilité | Dépend de périphériques hôtes, de pilotes, d’identifiants et de mappages compatibles | L’état des pilotes invités suit la VM, mais les mappages PCI physiques restent spécifiques à l’hôte |
| Partage du GPU | Plusieurs conteneurs peuvent utiliser le même périphérique de rendu de l’hôte lorsque cela est pris en charge | Le passthrough de l’ensemble du périphérique le dédie normalement à une seule VM |
| Cas d’utilisation idéal | Média, USB série et services GPU Linux partagés | Accélérateurs exclusifs, pilotes propriétaires, isolation renforcée, besoins de systèmes d’exploitation invités mixtes |
Les périphériques USB privilégient LXC lorsqu’ils se comportent comme des nœuds de périphérique Linux stables
Les adaptateurs USB-série, les coordinateurs Zigbee, les interfaces d’onduleurs, les accélérateurs Coral USB et les périphériques similaires peuvent très bien fonctionner dans LXC lorsque Proxmox expose le nœud de périphérique et lui attribue la propriété correcte. Le conteneur Docker à l’intérieur de LXC reçoit alors ce périphérique depuis son environnement hôte Linux.
Une explication pratique de l’accès USB dans Proxmox LXC montre le principe sous-jacent : monter le périphérique ne suffit pas si le conteneur n’est pas également autorisé à y accéder.
Utilisez des chemins stables tels que `/dev/serial/by-id` lorsque l’application les prend en charge. Les numéros de bus et les affectations de `/dev/ttyUSB0` peuvent changer après un redémarrage ou une reconnexion. L’approche LXC devient fragile lorsque chaque mise à jour de l’hôte nécessite de réparer manuellement les cgroups, les UID, les GID ou les chemins de périphériques.
Une machine virtuelle est plus propre lorsque la gestion du périphérique USB doit être autonome
Une machine virtuelle peut recevoir un périphérique USB par identifiant de fabricant et de produit ou par port physique, puis charger le pilote du périphérique dans son propre système d’exploitation. Cette approche est utile lorsque le périphérique nécessite un paquet du fabricant, une autre version du noyau ou une pile applicative qui ne doit pas dépendre des bibliothèques de l’hôte Proxmox.
La machine virtuelle crée également une limite de diagnostic plus claire. Si l’invité perd le périphérique USB, l’administrateur peut examiner séparément l’attachement au niveau de l’hyperviseur, puis le pilote de l’invité. Avec LXC, le pilote de l’hôte, le nœud de périphérique, les autorisations, le mappage du conteneur, l’environnement d’exécution Docker et l’application participent tous à une même chaîne.
Le compromis concerne le comportement lors de la reconnexion. Certains périphériques USB se réinitialisent, changent d’identité ou disparaissent lors du redémarrage de l’invité. Testez la déconnexion, le redémarrage de l’hôte, le redémarrage de l’invité et la récupération de l’application au lieu de supposer qu’une première connexion réussie garantit un fonctionnement stable.
L’accès partagé au GPU est généralement préférable avec LXC
Pour les périphériques de rendu Intel ou AMD et les charges de travail NVIDIA prises en charge, LXC peut exposer les nœuds de périphériques du GPU hôte à plusieurs services Linux. Le GPU reste géré par le pilote de l’hôte Proxmox, ce qui permet à plusieurs conteneurs d’utiliser l’encodage matériel ou le calcul sans attribuer l’intégralité du périphérique PCI à un seul invité.
L’exemple récent de XDA avec Proxmox explique comment un conteneur LXC peut partager le GPU géré par l’hôte plutôt que de le dédier via le passthrough à une machine virtuelle. Le même modèle opérationnel peut convenir à Jellyfin, Plex, Frigate ou à plusieurs services Docker lorsque les exigences en matière de pilotes et d’autorisations sont compatibles.
Le partage crée un couplage entre les versions. Le pilote du noyau de l’hôte, les bibliothèques en espace utilisateur dans LXC, l’intégration du runtime Docker et les paquets de l’application doivent rester compatibles. Une mise à niveau du noyau ou du pilote Proxmox peut donc affecter simultanément chaque conteneur utilisant le GPU.
Le passthrough exclusif d’un GPU favorise généralement une VM
Une VM constitue la meilleure option lorsqu’une charge de travail doit disposer de la propriété directe d’un GPU dédié, d’un pilote invité propriétaire, de la prise en charge de Windows, d’un isolement CUDA ou d’une pile de noyau qui ne devrait pas être installée sur Proxmox. L’attribution via VFIO sépare le périphérique de l’hôte et le présente à l’invité.
Le modèle PCI de Proxmox est conçu pour attribuer un périphérique PCI physique à un invité KVM. Une discussion Level1Techs sur Docker illustre la conséquence pratique : une VM utilise normalement le GPU transféré de manière exclusive, tandis que LXC peut partager l’accès aux périphériques de l’hôte entre plusieurs services.
Ce choix peut s’inverser lorsque le GPU prend en charge les périphériques médiés ou le SR-IOV, mais les GPU grand public et les plateformes de serveur domestique n’offrent pas de méthode universelle de partage. Vérifiez les groupes IOMMU, le comportement de réinitialisation, le micrologiciel, l’initialisation de l’affichage et la nécessité pour l’hôte d’utiliser ce GPU avant de concevoir votre solution autour d’un passthrough exclusif.
Docker dans LXC ajoute une couche de gestion imbriquée
LXC fournit déjà une isolation au niveau du système d’exploitation, et Docker y ajoute un autre moteur de conteneurs. Cela peut être efficace, mais introduit des espaces de noms imbriqués, des cgroups, des pilotes de stockage, des capacités et un comportement de montage supplémentaires. Certaines fonctionnalités de Docker nécessitent des options d’imbrication ou des autorisations supplémentaires dans le conteneur Proxmox.
Une VM fournit à Docker un hôte Linux conventionnel. La documentation Docker, les modules du noyau, le comportement du pare-feu et les pilotes de stockage sont plus faciles à interpréter, car le système invité maîtrise la configuration de son noyau. En contrepartie, il faut prévoir un système d’exploitation invité complet, de la mémoire réservée, la gestion d’un disque virtuel et une couche supplémentaire de correctifs.
Ne choisissez pas LXC uniquement pour économiser quelques centaines de mégaoctets si la configuration requise impose un conteneur privilégié, des autorisations étendues sur les périphériques et des modifications non documentées de l’hôte. L’option légère perd de son intérêt lorsque chaque mise à niveau dépend du souvenir d’exceptions que la VM aurait confinées dans le système invité.
L’isolation et la sécurité peuvent inverser le vainqueur en matière de performances
LXC partage le noyau de l’hôte ; un conteneur privilégié mal configuré ou un mappage de périphériques trop large peut donc exposer une plus grande partie du nœud Proxmox que prévu. Un LXC non privilégié, des autorisations de périphériques limitées, des montages en lecture seule et un nombre minimal de capacités améliorent la séparation, mais l’architecture reste plus couplée qu’une machine virtuelle complète.
Une machine virtuelle fournit un noyau distinct et peut isoler les piles de pilotes GPU propriétaires, la mise en réseau Docker, les modules de pare-feu et les logiciels expérimentaux de la base Proxmox. Cette séparation est précieuse lorsque l’hôte Docker exécute des images tierces, des services publics, des paquets d’IA locale ou des expérimentations fréquentes de pilotes.
La machine virtuelle n’est pas automatiquement sécurisée. Le passthrough PCI, les montages de stockage partagé, les identifiants de gestion et la mise en réseau pontée créent toujours des vecteurs d’attaque et de défaillance. Choisissez-la lorsque la séparation du noyau et des pilotes simplifie réellement le modèle de menace et de maintenance.
Les sauvegardes et la migration favorisent des types de simplicité différents
Les sauvegardes LXC sont compactes et rapides, car l’invité ne contient pas une pile matérielle virtuelle complète. Toutefois, la restauration de l’accès au matériel sur un autre nœud Proxmox nécessite de retrouver les mêmes nœuds de périphériques, groupes, pilotes et autorisations. Le système de fichiers du conteneur peut migrer, mais pas le contrat associé au périphérique physique.
Une sauvegarde de machine virtuelle contient le système d’exploitation invité et la configuration des pilotes, ce qui rend la récupération de l’application plus autonome. Les périphériques USB et les adresses PCI doivent tout de même être remappés sur la destination, et un GPU passé en relais peut empêcher la migration à chaud, car le périphérique physique est lié à un seul nœud.
Le flux de sauvegarde Proxmox de ZimaSpace couvre la protection de l’invité. Pour cette comparaison, une récupération n’est complète que lorsque Docker démarre et que l’application dépendante de l’USB ou du GPU peut détecter le périphérique de remplacement.
Effectuez un test de récupération des périphériques avant de choisir le type d’invité
- Répertoriez tous les périphériques USB et PCI requis par les applications Docker.
- Déterminez si chaque périphérique doit être partagé avec l’hôte ou attribué à un seul invité.
- Testez le pilote de l’hôte, le nœud de périphérique, le mappage UID/GID et les autorisations Docker pour LXC.
- Testez le regroupement IOMMU, l’installation du pilote invité et le comportement de réinitialisation pour une machine virtuelle.
- Redémarrez l’hôte Proxmox et confirmez que l’attachement du périphérique revient automatiquement.
- Restaurez l’invité depuis une sauvegarde et recréez le mappage matériel à partir de la documentation.
- Répétez le test sur un autre nœud compatible si la migration ou le remplacement du matériel est important.
Mesurez le comportement de l’application plutôt que la seule surcharge de l’invité. La stabilité du transcodage matériel, la reconnexion USB, les mises à jour des pilotes, la maintenance de l’hôte et le temps de récupération comptent généralement davantage qu’une légère différence de performances CPU entre LXC et KVM.
Quel invité Proxmox convient à l’hôte Docker ?
Choisissez LXC lorsque
Choisissez LXC lorsque toutes les charges de travail sont basées sur Linux, que l’hôte peut gérer les pilotes, que les périphériques USB exposent des nœuds stables et qu’un GPU doit être partagé entre plusieurs services. Maintenez le conteneur non privilégié dans la mesure du possible et documentez chaque mappage de périphérique et de groupe.
Choisissez une machine virtuelle lorsque
Choisissez une machine virtuelle lorsque l’hôte Docker nécessite la propriété exclusive d’un GPU PCI, des pilotes propriétaires ou expérimentaux, une isolation renforcée du noyau ou une portabilité accrue de l’ensemble de la pile logicielle. Réservez suffisamment de mémoire vive et de stockage à l’invité et testez la réinitialisation du périphérique après un redémarrage.
Répartissez les charges de travail lorsque
Exécutez les services légers de médias et USB dans LXC, tout en plaçant les traitements GPU exclusifs, les outils dépendant de Windows ou les piles Docker non fiables dans une machine virtuelle. Une plateforme compatible avec Proxmox peut prendre en charge les deux, mais chaque appareil physique doit avoir un modèle de propriété documenté et unique.
FAQ
Docker peut-il fonctionner de manière fiable dans un LXC non privilégié ?
Oui, pour de nombreuses charges de travail, mais l’imbrication, les pilotes de stockage, les montages, le réseau et l’accès aux périphériques peuvent nécessiter une configuration supplémentaire. Testez précisément les fonctionnalités Docker utilisées et n’optez pas pour un conteneur privilégié uniquement pour contourner un problème d’autorisation inexpliqué.
Un même GPU peut-il être utilisé par un LXC et une machine virtuelle ?
Pas avec un passthrough VFIO classique de l’appareil entier en même temps. LXC peut partager un périphérique de rendu géré par l’hôte, tandis qu’une machine virtuelle doit normalement avoir le périphérique détaché de l’hôte. La prise en charge de SR-IOV ou des périphériques médiés peut modifier cette situation sur certains matériels.
Quelle option est la meilleure pour un coordinateur Zigbee USB ?
Les deux peuvent fonctionner. LXC est efficace lorsqu’un chemin série stable basé sur l’identifiant et des autorisations fiables sont disponibles. Une machine virtuelle est plus propre lorsque la pile logicielle ou le pilote du coordinateur doit rester indépendant de l’hôte Proxmox.
Verdict final
Utilisez LXC pour héberger Docker lorsque les ressources USB et GPU peuvent être partagées via la pile de pilotes Linux de l’hôte Proxmox et qu’une faible surcharge est importante. Utilisez une machine virtuelle lorsque le matériel doit appartenir à l’invité, que les pilotes doivent être isolés ou que la récupération doit préserver un système d’exploitation autonome. Choisissez en fonction de la propriété des appareils et du comportement lors de la restauration, et non en partant du principe que les conteneurs sont toujours plus simples.
Produits recommandés
Comparaisons de produits
Plus à lire
Tunnel VPS vs redirection de ports à domicile pour les services auto-hébergés publics : quel chemin d’entrée est le plus facile à contrôler ?
Utilisez la redirection de port pour le chemin direct le plus simple ; utilisez un tunnel VPS lorsque le CGNAT, la confidentialité de l’adresse,...
Routeur grand public ou pare-feu dédié pour un laboratoire domestique segmenté : quand faut-il séparer la passerelle ?
Conservez le routeur grand public tant que la segmentation reste simple ; passez à un pare-feu dédié lorsque les règles, la visibilité, les interfaces...
Laboratoire de couche 2 ou VLAN routés à mesure que votre laboratoire personnel s’agrandit : quand la passerelle doit-elle se rapprocher de la périphérie ?
Conservez la couche 2 tant qu’une seule passerelle et quelques trunks restent faciles à gérer ; routez plus près de la périphérie lorsque l’étendue...
