Le passthrough GPU a une réputation de configuration capricieuse. Elle est méritée, mais pour une raison précise : six conditions doivent être réunies simultanément, et quand l'une manque, le symptôme ne pointe presque jamais vers la bonne cause.
Pris dans l'ordre, ces obstacles se lèvent méthodiquement.
Avant tout : en avez-vous besoin ?
Question à trancher en premier, parce qu'elle évite parfois tout le reste.
Le passthrough dédie la carte à une seule machine virtuelle. L'hôte la perd, les autres invités aussi. C'est un modèle exclusif.
Si votre besoin est du transcodage vidéo ou de l'inférence partagée entre plusieurs services, un conteneur avec accès au périphérique répond mieux : plusieurs conteneurs peuvent utiliser la carte en même temps, l'hôte y garde accès, et la configuration est infiniment plus simple.
Le passthrough se justifie pour un usage exclusif : jeu, station de travail virtualisée, système d'exploitation différent, application exigeant le pilote constructeur complet.
Piège 1 : l'IOMMU inactive
L'IOMMU est le composant matériel qui permet d'isoler les accès mémoire d'un périphérique. Sans elle, aucun passthrough n'est possible.
Deux activations sont nécessaires, et il faut les deux :
- Dans le firmware de la carte mère. Le réglage porte des noms variables selon les constructeurs et se cache souvent dans les options avancées du chipset. Il est fréquemment désactivé par défaut.
- Au démarrage du noyau, par un paramètre passé au chargeur d'amorçage.
La vérification est simple : le noyau consigne au démarrage la détection de l'IOMMU et la constitution des groupes. Si ces messages sont absents, arrêtez-vous là — rien de ce qui suit ne fonctionnera.
Piège 2 : le groupe indivisible
C'est le blocage le plus structurel, et celui contre lequel aucune configuration logicielle ne peut rien.
Les périphériques sont répartis en groupes IOMMU selon ce que le matériel est capable d'isoler. Le passthrough opère à la granularité du groupe entier, jamais du périphérique seul.
Si votre carte graphique se trouve seule dans son groupe, tout va bien. Si elle le partage avec un contrôleur réseau, un port de stockage ou un contrôleur USB, il faut tout passer à la machine virtuelle — y compris des composants dont l'hôte a besoin pour fonctionner.
La qualité de cette séparation dépend de la carte mère et de l'emplacement utilisé. Les plateformes d'entrée de gamme regroupent largement ; les plateformes serveur ou haut de gamme isolent finement.
Deux réponses possibles : changer la carte d'emplacement, ce qui suffit parfois à la placer dans un groupe plus favorable, ou recourir à un contournement noyau qui force une séparation plus fine — en sachant qu'il affaiblit l'isolation qu'il prétend fournir, et qu'il n'a sa place que sur une machine dont vous maîtrisez tous les invités.
Piège 3 : le pilote de l'hôte s'accroche
Au démarrage, le système détecte la carte et charge son pilote graphique. Une fois qu'il la tient, elle n'est plus disponible pour le passthrough.
Il faut donc l'en empêcher, avant même que le pilote ne se charge : soit en mettant le pilote concerné sur liste noire, soit en associant explicitement l'identifiant du périphérique au pilote d'assignation dès l'initialisation du système.
Le diagnostic est direct : dans la liste des périphériques, regardez quel pilote est rattaché à la carte. S'il s'agit du pilote graphique, l'hôte l'a prise. S'il s'agit du pilote d'assignation, elle est prête.
Piège 4 : la carte qui affiche la console
Cas particulièrement retors. Une carte initialisée par le firmware au démarrage, et utilisée pour l'affichage de l'hôte, se réinitialise mal une fois détachée.
Le symptôme est caractéristique : la machine virtuelle démarre une fois et fonctionne. Vous l'arrêtez, vous la redémarrez, et plus rien — jusqu'au redémarrage physique de la machine.
La solution la plus fiable est de donner à l'hôte une autre sortie vidéo : carte graphique intégrée au processeur, ou seconde carte modeste. La carte à passer n'est alors jamais touchée par le firmware ni par l'hôte, et se comporte correctement.
Piège 5 : la ROM nécessaire
Quand la carte à passer est aussi celle qui démarre la machine, elle a déjà été initialisée par le firmware. La machine virtuelle, en essayant de l'initialiser à son tour, échoue.
Le contournement consiste à fournir à la VM une copie de la ROM de la carte, non altérée par l'initialisation du démarrage. On l'extrait soit du système, soit d'une base publique correspondant au modèle exact.
Ce n'est nécessaire que dans cette configuration précise. Avec une sortie vidéo distincte pour l'hôte, le problème ne se pose pas — raison de plus pour privilégier cette solution.
Piège 6 : la réinitialisation impossible
Dernier obstacle, purement matériel : certaines cartes ne se réinitialisent pas correctement quand la machine virtuelle s'arrête. Elles restent dans un état incohérent, et le démarrage suivant échoue.
Cela dépend du modèle et de la génération. Certains contournements existent, aucun n'est universel.
La parade pratique : configurer la machine virtuelle pour qu'elle démarre avec l'hôte et ne s'arrête pas en usage courant. Ce n'est pas élégant, mais sur un poste de travail virtualisé qui tourne en permanence, la contrainte est acceptable.
L'ordre de diagnostic
- L'IOMMU est-elle détectée au démarrage du noyau ? Sinon, rien d'autre n'est pertinent.
- La carte est-elle seule dans son groupe ? Sinon, changez d'emplacement avant tout autre effort.
- Quel pilote est rattaché à la carte ? Il doit être celui d'assignation.
- L'hôte a-t-il une autre sortie vidéo ? Sinon, attendez-vous aux pièges 4 et 5.
- La VM démarre-t-elle une fois puis plus jamais ? C'est le problème de réinitialisation.
Traités dans cet ordre, ces points couvrent la quasi-totalité des échecs. Et si le blocage est au point 2 sur une carte mère qui regroupe tout, la conclusion honnête est parfois qu'un conteneur avec accès au périphérique répondra mieux à votre besoin réel.
Commentaires