Un GPU intégré peut-il être partagé entre une VM et des conteneurs hôtes ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Can an Integrated GPU Be Shared Between a VM and Host Containers? - Zima Store Online

Parfois. Le passthrough PCI complet donne à la VM l'intégralité du GPU intégré, de sorte que les conteneurs de l'hôte perdent normalement leur accès. Le partage nécessite la prise en charge matérielle et logicielle des périphériques médiés, d'Intel GVT-g sur certaines anciennes plateformes ou des fonctions virtuelles SR-IOV sur certaines plateformes plus récentes compatibles.

L'accès des conteneurs constitue une couche distincte : les conteneurs partagent généralement le noyau de l'hôte et utilisent des périphériques de rendu tels que `/dev/dri/renderD128`. Une VM a besoin d'une fonction GPU virtualisée ou d'un périphérique médié, et non de ce nœud de périphérique de l'hôte. Cette distinction détermine la configuration sûre, la méthode de validation et le point de retour en arrière.

Identifiez le mode de virtualisation pris en charge par votre plateforme

Commencez par relever la génération exacte du CPU, l'identifiant PCI de l'iGPU, le firmware, le noyau de l'hôte et le pilote. Un guide destiné à une génération Intel peut ne pas s'appliquer à une autre, et certaines méthodes de partage sont abandonnées ou nécessitent des modules externes à l'arborescence principale.

Si seul le passthrough complet est pris en charge, choisissez la VM ou l'hôte pour l'accélération. Ne vous attendez pas à ce qu'un conteneur de l'hôte conserve Quick Sync après le déliaison du pilote de l'hôte.

Si SR-IOV ou les périphériques médiés sont pris en charge, conservez la fonction physique sur l'hôte et attribuez une fonction virtuelle ou un mdev à la VM. Vérifiez le comportement lors de la réinitialisation et avec le pilote avant de considérer la solution comme prête pour la production.

Utilisez les indicateurs de capacité et de charge

Vérifiez que l'hôte expose toujours un nœud de rendu et que la VM détecte le GPU virtuel qui lui est attribué. Exécutez un décodage ou un encodage matériel dans les deux environnements au lieu de vous fier aux listes de périphériques.

Surveillez l'utilisation des moteurs GPU, les erreurs, la pression mémoire et les journaux du noyau pendant des transcodages simultanés. Le partage de la capacité ne garantit ni des performances prévisibles ni la prise en charge des codecs.

Utilisez le tableau ci-dessous pour choisir un mode d'exploitation sûr.

État observé	Verdict	Action suivante
Passthrough PCI complet	Utilisation exclusive par la VM	Les conteneurs de l'hôte perdent l'iGPU
mdev/GVT-g pris en charge	Tranches partagées	Spécifique à la génération
SR-IOV pris en charge	PF sur l'hôte, VF pour la VM	Valider le cycle de vie du pilote

Configurez le principe du moindre privilège et contrôlez les mises à niveau

Donnez aux conteneurs de l'hôte uniquement le périphérique de rendu et les autorisations de groupe requises, et non un accès privilégié étendu. Dans la VM, installez le pilote correspondant à la fonction virtualisée et conservez un mode de rendu logiciel de secours pour la maintenance.

Figez les combinaisons fonctionnelles de noyau et de pilote jusqu'à ce que la prochaine mise à jour ait passé un test en laboratoire. Les modules SR-IOV expérimentaux peuvent cesser de fonctionner après des mises à jour du noyau ou du firmware ; documentez donc les étapes de suppression et de récupération.

La présentation de l'extension GPU du ZimaCube par ZimaSpace fournit le contexte matériel.

Un guide indépendant du partage de GPU dans un homelab présente le passthrough complet, les périphériques médiés et SR-IOV.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

Effectuez de nouveaux tests après le redémarrage et sous charge simultanée

Effectuez un démarrage à froid de l'hôte, démarrez d'abord les conteneurs, puis la VM ; recommencez dans l'ordre inverse. Les deux chemins doivent fonctionner à nouveau sans réassociation manuelle du pilote.

Exécutez la charge réelle simultanée suffisamment longtemps pour révéler la limitation thermique et les erreurs de réinitialisation. Redémarrez ensuite la VM sans redémarrer l'hôte et vérifiez que les conteneurs conservent l'accélération.

Ne poursuivez que lorsque la plateforme exacte prend en charge un mode de partage et résiste aux tests de charge simultanée et de redémarrage. Arrêtez-vous si l'hôte perd son nœud de rendu, si la VM ne peut pas être réinitialisée ou si la solution dépend d'un pilote non maintenu que vous ne pouvez pas figer en toute sécurité.