Passthrough GPU Proxmox : écran noir — 10 causes et solutions

Playbook de diagnostic rapide (vérifier d’abord/deuxième/troisième)

Quand l’écran est noir, n’agitez pas inutilement. La chaîne de passthrough GPU est longue. Votre objectif est de trouver quel segment est cassé :
isolation du périphérique sur l’hôte, initialisation firmware de la VM, pilote invité, ou routage de l’affichage.

Première étape : confirmer que l’hôte a bien cédé le GPU à VFIO

• Vérifier le binding : le GPU doit être lié à vfio-pci, pas à nvidia, amdgpu ou nouveau.
• Vérifier qu’IOMMU est activé : si le remappage DMA est désactivé, le passthrough peut fonctionner à moitié puis échouer de façon étrange.
• Vérifier les groupes IOMMU : si votre GPU est dans un groupe avec d’autres périphériques que vous n’avez pas passés, vous aurez des échecs incohérents.

Deuxième étape : confirmer que la VM peut initialiser le périphérique (firmware + type de machine)

• OVMF vs SeaBIOS : les GPU modernes nécessitent souvent l’UEFI (OVMF). Certaines cartes plus anciennes se comportent mieux avec SeaBIOS. Choisissez délibérément.
• Q35 vs i440fx : Q35 est le choix par défaut pour une raison (PCIe). Beaucoup de problèmes de passthrough disparaissent sur Q35.
• Paramètre GPU primaire : si la VM attend un périphérique d’affichage mais que vous l’avez retiré, vous pourriez regarder le néant parce que vous n’avez rien demandé.

Troisième étape : confirmer que le pilote invité est sain et que la sortie est correctement routée

• Windows : vérifiez les erreurs dans le Gestionnaire de périphériques (Code 43, Code 31) et le journal d’événements.
• Invités Linux : vérifiez dmesg pour l’initialisation amdgpu/nvidia, et confirmez quelle sortie est active.
• Routage d’affichage : testez différents ports (DP vs HDMI) et désactivez fréquence élevée + HDR pendant le débogage.

Une citation à garder en tête pendant le débogage : idée paraphrasée de Richard Feynman :
« La réalité doit primer sur les relations publiques. » En termes d’ops : faites confiance à ce que dit le noyau, pas à ce que laisse entendre votre interface.

Faits intéressants et courte histoire (pourquoi c’est si pointilleux)

• Intel VT-d (remappage DMA) est arrivé largement après la virtualisation CPU ; les premiers hyperviseurs pouvaient lancer des VM mais pas passer des périphériques en toute sécurité.
• VFIO a remplacé les anciens frameworks de passthrough PCI sous Linux parce qu’il est plus sûr et s’intègre correctement avec IOMMU.
• OVMF est essentiellement le firmware UEFI pour les VM ; à mesure que les GPU sont devenus plus centrés sur l’UEFI, les chemins BIOS hérités ont commencé à échouer plus souvent.
• Les GPU ne sont pas “que des périphériques PCIe” : beaucoup sont aussi de petits ordinateurs avec leur propre firmware, formation mémoire et état au démarrage.
• Le “Code 43” de NVIDIA est devenu un rite de passage pour les utilisateurs de passthrough ; c’est moins fréquent aujourd’hui mais cela survient encore dans des cas limites.
• Les bugs de reset sont réels : certains GPU ne se réinitialisent pas complètement après l’arrêt d’une VM, donc le démarrage suivant récupère un périphérique bloqué dans un mauvais état.
• ACS (Access Control Services) affecte l’isolation PCIe ; les cartes grand public peuvent grouper des périphériques ensemble alors que vous voudriez les séparer.
• Resizable BAR est une fonctionnalité de performance qui peut modifier la façon dont la mémoire est mappée ; c’est excellent jusqu’à ce que ça ne le soit plus, surtout à travers des frontières de firmware.
• Le link training DisplayPort peut échouer après des réinitialisations chaudes ; un « écran noir » peut être un problème de négociation avec le moniteur, pas un problème PCI.

Modèle mental : où se produit l’écran noir

Un « écran noir » n’est pas un seul problème ; c’est un symptôme. La pile de passthrough GPU a des couches, et chaque couche peut échouer d’une manière qui ressemble à la même chose
depuis votre chaise.

1. Isolation matérielle : IOMMU doit traduire le DMA, et la topologie PCIe doit permettre d’isoler proprement le GPU.
2. Binding du pilote hôte : l’hôte ne doit pas revendiquer le GPU avec un pilote natif. VFIO doit en être propriétaire avant le démarrage de la VM.
3. Firmware de la VM + modèle de machine : OVMF/Q35 doit énumérer le PCIe, assigner les BARs et initialiser correctement les chemins d’option ROM.
4. Pilote invité : Windows/Linux doit charger un pilote capable de gérer l’environnement, la gestion d’alimentation et l’initialisation de l’affichage.
5. Sortie d’affichage : le GPU peut être sain, mais la sortie est sur un port différent, la négociation du moniteur a échoué, ou le GPU attend une configuration de mode.

Vérité sèchement drôle : le GPU est innocent jusqu’à preuve du contraire, mais il ruinera quand même votre journée comme un chat avec accès à un clavier.

Tâches pratiques : commandes, sorties, décisions (au moins 12)

Voici les tâches que j’exécute dans grosso modo cet ordre. Chacune a : commande, ce que signifie la sortie, et quelle décision prendre ensuite.
Elles sont écrites pour un hôte Proxmox VE (base Debian).

Task 1: Confirm IOMMU is actually enabled

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.012345] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.045678] DMAR: DRHD base: 0x000000fed90000 flags: 0x1

Meaning: You want to see “IOMMU enabled” (Intel DMAR) or “AMD-Vi: IOMMU enabled”.

Decision: If you don’t see it, stop. Fix BIOS settings and kernel parameters before touching VM config.

Task 2: Verify kernel cmdline parameters

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt

Meaning: intel_iommu=on or amd_iommu=on should be present. iommu=pt is commonly used for performance.

Decision: If missing, edit GRUB, update-grub, reboot. Don’t “hope it’s fine.”

Task 3: Identify GPU PCI IDs (and the audio function)

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display|audio' 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)

Meaning: GPUs are often multi-function devices. The audio function matters for resets and for Windows driver sanity.

Decision: Plan to pass through both functions unless you have a reason not to.

Task 4: Check what driver currently owns the GPU

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] TU104 [1462:3751]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Meaning: “Kernel driver in use: vfio-pci” is what you want.

Decision: If it says nouveau, nvidia, or amdgpu, fix binding before running the VM.

Task 5: Confirm VFIO modules are loaded

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          69632  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   57344  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             425984  0
kvm                  1376256  1 kvm_intel

Meaning: If VFIO isn’t present, passthrough will be flaky or fail outright.

Decision: Load modules, fix initramfs configuration, reboot if needed.

Task 6: Inspect IOMMU group isolation for the GPU

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$(basename "$(dirname "$d")") $(basename "$d")"; done | sort -n | egrep '01:00'
12 0000:01:00.0
12 0000:01:00.1

Meaning: Ideally, the GPU and its audio function are in a group by themselves (or with only what you also pass through).

Decision: If the group includes chipset devices or an NVMe you need on the host, you likely need different slot placement or ACS override.

Task 7: Verify Proxmox VM config for correct machine/firmware

cr0x@server:~$ qm config 120
agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 8
cpu: host,hidden=1,flags=+pcid
machine: q35
memory: 16384
name: win11-gpu
ostype: win11
scsi0: local-lvm:vm-120-disk-0,discard=on,iothread=1
hostpci0: 0000:01:00.0,pcie=1,x-vga=1
hostpci1: 0000:01:00.1,pcie=1

Meaning: bios: ovmf et machine: q35 sont généralement corrects. x-vga=1 peut aider quand vous voulez que le GPU soit primaire.

Decision: Si vous êtes en i440fx/SeaBIOS avec un GPU moderne, passez à Q35/OVMF sauf preuve contraire.

Task 8: Read QEMU log for device assignment errors

cr0x@server:~$ journalctl -u pve-qm@120 --no-pager -n 120
... qemu-system-x86_64: vfio-pci 0000:01:00.0: BAR 1: can't reserve [mem 0x...] ...
... qemu-system-x86_64: vfio-pci 0000:01:00.0: failed to setup container for group 12: Failed to set iommu for container: Operation not permitted
... VM 120 start failed: QEMU exited with code 1

Meaning: Les problèmes de réservation de BAR, d’erreurs de groupe et de permissions apparaissent ici en premier.

Decision: Si QEMU ne peut pas démarrer, ne chassez pas les pilotes invités. Corrigez la couche hôte/firmware.

Task 9: Check for host console takeover (framebuffer conflicts)

cr0x@server:~$ dmesg | egrep -i 'fbcon|efifb|simplefb|vesafb|nouveau|amdgpu' | head -n 60
[    1.234567] efifb: framebuffer at 0xe1000000, using 3072k, total 3072k
[    1.234890] fbcon: Deferring console take-over

Meaning: Si l’hôte lie un framebuffer au GPU, le binding VFIO peut se produire en course ou échouer.

Decision: Si vous voyez l’hôte saisir le GPU ciblé, blacklistez les modules pertinents et envisagez de désactiver le framebuffer EFI pour ce périphérique.

Task 10: Confirm the VM sees the GPU in-guest (Windows via agent-less hint)

cr0x@server:~$ qm monitor 120
(qemu) info pci
  Bus  0, device  1, function 0:
    VGA controller: PCI device 10de:1e87
      BAR0: 64 bit memory at 0x00000000f6000000 [0x01000000]
      BAR1: 64 bit memory at 0x00000000e0000000 [0x10000000]

Meaning: QEMU énumère le périphérique et mappe les BARs. Cela ne prouve pas que les pilotes fonctionnent, mais cela prouve que vous avez dépassé l’énumération basique.

Decision: Si c’est absent, revenez à la config VM (lignes hostpci, pcie=1) et aux vérifications de groupe IOMMU.

Task 11: Detect reset-related issues (GPU stuck after shutdown)

cr0x@server:~$ dmesg | egrep -i 'vfio-pci|reset|FLR|D3' | tail -n 60
[  912.345678] vfio-pci 0000:01:00.0: not ready 1023ms after bus reset; waiting
[  913.369012] vfio-pci 0000:01:00.0: not ready 2047ms after bus reset; giving up

Meaning: Le GPU ne s’est pas réinitialisé proprement. Cela donne souvent un écran noir au prochain démarrage de la VM.

Decision: Appliquez un contournement de reset (vendor-reset pour certains GPU AMD, reboot complet de l’hôte, ou choisissez un GPU connu pour se réinitialiser proprement).

Task 12: Check interrupt remapping and kernel warnings

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|IR:|x2apic|ATS|posted interrupt' | head -n 80
[    0.123456] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.123789] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.

Meaning: Le remappage IRQ réduit les « verrouillages de périphériques mystérieux sous charge » et améliore l’isolation.

Decision: Si vous voyez des avertissements sur le remappage IRQ désactivé, attendez-vous à de l’instabilité. Corrigez le BIOS/firmware ou considérez les flags noyau adaptés à votre plateforme.

Task 13: Confirm the GPU ROM situation (only if needed)

cr0x@server:~$ echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/rom >/dev/null
cr0x@server:~$ sudo cat /sys/bus/pci/devices/0000:01:00.0/rom | head -c 16 | hexdump
0000000 55 aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000010

Meaning: Un en-tête ROM commence par 55 aa. Certains GPU nécessitent un dump de ROM pour s’initialiser dans une VM, surtout s’ils ne sont pas le GPU primaire.

Decision: Si les lectures ROM sont bloquées ou corrompues, envisagez de fournir un fichier ROM connu dans la config VM (et seulement alors).

Task 14: Verify hugepages / memory backing didn’t break DMA

cr0x@server:~$ grep -H . /proc/meminfo | egrep 'HugePages|Hugepagesize' 
/proc/meminfo:HugePages_Total:       8192
/proc/meminfo:HugePages_Free:        8000
/proc/meminfo:Hugepagesize:          2048 kB

Meaning: Les hugepages vont bien, mais un mauvais dimensionnement ou un host à court de mémoire peut provoquer des échecs étranges qui ressemblent à des problèmes GPU.

Decision: Si l’hôte est sous pression mémoire ou que les hugepages sont fragmentées, revenez sur les optimisations de performance jusqu’à ce que la VM fonctionne de façon fiable.

10 causes et correctifs (édition écran noir)

1) L’hôte utilise encore le GPU (mauvais binding de pilote)

C’est le classique. Vous avez passé le GPU, mais l’hôte a chargé nvidia, amdgpu ou nouveau en premier.
La VM démarre, mais le GPU est à moitié possédé et se comporte comme s’il était tiré dans deux directions. L’écran noir est un résultat courant.

Correctif : liez le périphérique à vfio-pci tôt (initramfs), et blacklistez les modules conflictuels.

cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1

cr0x@server:~$ cat /etc/modprobe.d/blacklist-gpu.conf
blacklist nouveau
blacklist nvidia
blacklist nvidiafb

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Decision : Après le reboot, revérifiez avec lspci -nnk. Si ce n’est pas vfio-pci, vous n’avez pas fini.

2) Les groupes IOMMU sont sales (vous ne pouvez pas isoler le GPU)

Si le GPU se trouve dans un groupe IOMMU avec d’autres périphériques (contrôleurs USB, SATA, parfois tout le voisinage d’un slot PCIe),
VFIO ne peut pas assigner seulement le GPU en toute sécurité. Vous pouvez obtenir « ça démarre une fois, puis écran noir », ou « ça marche jusqu’au chargement du pilote ».

Correctif : déplacez le GPU vers un autre slot, désactivez « Above 4G decoding » seulement si cela casse vraiment le grouping (rare), ou utilisez ACS override avec prudence.

cr0x@server:~$ pvesh get /nodes/$(hostname)/hardware/pci --pci-class-blacklist ""
... 

Decision : Si déplacer les slots vous donne un groupe propre, faites-le. Si vous devez utiliser ACS override, traitez-le comme un contournement, pas une victoire.

3) Firmware/type de machine incorrect (mismatch OVMF/Q35)

SeaBIOS plus i440fx peut encore fonctionner, mais c’est le choix “ça tournait sur mon portable en 2017”.
Les GPU modernes et les installateurs d’OS modernes sont plus à l’aise avec OVMF + Q35.

Correctif : définissez bios: ovmf et machine: q35. Ajoutez aussi un disque EFI si nécessaire (Proxmox le fait via l’UI).

Decision : Si vous êtes coincé sur SeaBIOS pour une raison legacy spécifique, vous devrez peut-être fournir un fichier ROM et accepter que certains GPU ne coopèrent pas.

4) Vous regardez la mauvaise sortie d’affichage (port et négociation moniteur)

Celle-ci est humiliante parce qu’elle est réelle. Les ports différents peuvent se comporter différemment en passthrough : link training DP,
quirks EDID HDMI, et états d’économie d’énergie du moniteur peuvent tous ressembler à « le GPU est mort ».

Correctif : pendant le débogage, utilisez un seul moniteur, réglez-le sur une fréquence basique (60 Hz), désactivez le HDR et testez un port différent.

Decision : Si la VM est atteignable via RDP/SSH mais que la sortie locale est noire, le GPU est probablement sain ; le chemin d’affichage est le problème.

5) Omission de la fonction audio du GPU (passthrough multi-fonction)

Beaucoup de GPU exposent une fonction audio HDMI/DP. Certains pilotes supposent son existence. Certains resets se comportent mieux quand toutes les fonctions sont passées.
Passez uniquement la fonction VGA et vous pourriez obtenir un pilote qui se charge… puis rien à l’écran.

Correctif : passez à la fois 01:00.0 et 01:00.1 comme entrées hostpci séparées.

Decision : Si vous ne pouvez pas passer la fonction audio parce qu’elle est groupée avec autre chose, revenez aux groupes IOMMU et au choix de slot.

6) NVIDIA Code 43 / détection d’hyperviseur (moins courant, mais réel)

Dans certains environnements, Windows + pilotes NVIDIA décident qu’ils n’aiment pas les invités virtualisés et refusent d’initialiser correctement le GPU.
Les symptômes varient : écran noir, erreur de périphérique, pilotes qui s’installent mais ne produisent jamais de sortie.

Correctif : utilisez cpu: host,hidden=1 dans la config VM et évitez de masquer des flags CPU exotiques sauf si nécessaire pour des licences ou compatibilité.

Decision : Si vous faites des charges VDI, testez différentes versions de pilotes. Ce n’est pas de la superstition ; il y a des régressions.

7) Le bug de reset (le GPU ne se réinitialise pas après reboot/shutdown de la VM)

Certains GPU ne se réinitialisent pas complètement sans un cycle d’alimentation complet. Vous arrêtez la VM, la redémarrez, et obtenez un écran noir.
Le premier démarrage fonctionne, ce qui vous fait blâmer l’invité. Le GPU est celui qui garde rancune.

Options de correctif :

• Essayez un reboot complet de l’hôte comme diagnostic. Si cela “corrige” le problème, vous avez probablement un souci de reset.
• Pour certaines cartes AMD, un module de reset peut restaurer la fonction appropriée (dépend de la plateforme).
• Privilégiez les GPU connus pour se réinitialiser proprement en production. “Ça marche si je ne redémarre jamais” n’est pas une stratégie.

Blague n°2 : Si votre GPU ne fonctionne qu’après un reboot de l’hôte, félicitations — vous avez construit un interrupteur très coûteux.

8) Tailles BAR / Above 4G decoding / quirks Resizable BAR

Les GPU modernes mappent de larges régions mémoire (BARs). Si le firmware ne peut pas allouer l’espace proprement, vous verrez des erreurs de réservation de BAR,
des échecs QEMU aléatoires, ou une VM qui démarre mais ne montre jamais d’affichage quand le pilote tente de mapper la VRAM.

Correctif :

• Activez “Above 4G decoding” dans le BIOS pour les grandes allocations BAR (souvent requis).
• Désactivez temporairement Resizable BAR pendant le débogage (surtout si vous mélangez OS invité ou firmware plus anciens).
• Restez sur Q35 et OVMF pour un comportement PCIe cohérent.

Decision : Si vos logs montrent des échecs d’allocation BAR, ne perdez pas de temps côté pilote invité.

9) Confusion sur le GPU primaire : x-vga, vBIOS et « pas d’affichage émulé »

Si vous retirez le périphérique VGA émulé et attendez que le GPU passé soit primaire, le firmware invité doit l’utiliser comme affichage de démarrage.
Parfois il ne le fait pas, surtout si le GPU n’expose pas une option ROM compatible comme la VM l’attend.

Correctif :

• Essayez x-vga=1 sur le périphérique passthrough GPU.
• Gardez un affichage émulé basique temporairement (comme std VGA) pour l’installation/le débogage, puis retirez-le une fois stable.
• Si nécessaire, fournissez un fichier ROM correspondant exactement à votre modèle de GPU.

Decision : Si vous voyez les écrans de boot via VGA émulé mais perdez la sortie en passant au GPU, vous êtes en territoire firmware/option-ROM.

10) Gestion d’alimentation et états de sommeil (D3cold, ASPM et consorts)

Certaines plateformes mettent agressivement les périphériques en états basse consommation. Sur bare metal, les pilotes gèrent cela.
En passthrough, les transitions d’état d’alimentation peuvent être moins indulgentes. Le pilote invité se charge, change l’état d’alimentation du GPU,
et votre affichage devient noir.

Correctif : désactivez PCIe ASPM dans le BIOS pour tester, et évitez la suspension/hibernation dans l’invité tant que la stabilité n’est pas prouvée.

Decision : Si le GPU fonctionne jusqu’à ce que l’invité se mette en idle ou que l’écran se mette en veille, suspectez la gestion d’alimentation plutôt que les bases VFIO.

Erreurs courantes : symptôme → cause racine → correction

• Symptôme : La VM démarre, la console Proxmox est noire, le moniteur est noir, mais la VM répond au ping.
  Cause racine : La sortie est sur un port GPU différent ou l’invité utilise un autre adaptateur d’affichage.
  Correction : RDP/SSH, définissez le GPU passé comme affichage principal, testez un autre port physique, réduisez fréquence/HDR.
• Symptôme : La VM ne démarre pas ; QEMU sort avec des erreurs de groupe/conteneur.
  Cause racine : Groupe IOMMU non isolé ou IOMMU désactivé/mal configuré.
  Correction : activez VT-d/AMD-Vi, corrigez les flags noyau, déplacez les slots GPU, puis seulement envisagez ACS override.
• Symptôme : Ça marche une fois après reboot hôte, puis écran noir après redémarrage VM.
  Cause racine : Bug de reset GPU / FLR non supporté.
  Correction : évitez les stop/start fréquents, utilisez des contournements vendor-reset si disponibles, ou choisissez un GPU avec des resets propres.
• Symptôme : Windows montre le GPU mais le pilote échoue ; écran noir quand le pilote se charge.
  Cause racine : incompatibilité pilote/hyperviseur, fonction audio manquante, ou mismatch de firmware.
  Correction : passez toutes les fonctions, utilisez OVMF+Q35, mettez cpu: host,hidden=1, testez une branche pilote stable.
• Symptôme : L’hôte perd la vidéo après le binding du GPU à VFIO ; vous ne voyez plus la console.
  Cause racine : Vous avez passé le seul GPU que l’hôte utilise pour l’affichage.
  Correction : utilisez un iGPU ou un GPU secondaire bon marché pour la console hôte, ou travaillez en headless avec IPMI/série en acceptant le compromis.
• Symptôme : Gel aléatoire sous charge ; parfois se termine par un écran noir.
  Cause racine : remappage d’interruptions désactivé, BIOS buggué, ou transitions de gestion d’alimentation.
  Correction : mettez à jour le BIOS, activez le remappage IRQ, désactivez ASPM pour tester, gardez le noyau à jour.
• Symptôme : Le log QEMU mentionne des échecs de réservation de BARs.
  Cause racine : Interaction Above 4G decoding/Resizable BAR ou exhaustion de l’espace d’adresses.
  Correction : activez Above 4G decoding, désactivez Resizable BAR temporairement, restez sur Q35/OVMF.

Trois mini-récits d’entreprise depuis le terrain

Incident n°1 : La panne causée par une mauvaise hypothèse

Une équipe voulait “accélération GPU pas chère” pour une charge Windows CAD. Ils ont construit un nœud Proxmox avec un gros GPU et ont supposé :
“La VM utilise le GPU, l’hôte n’en a pas besoin.” Ils ont même désactivé le VGA émulé parce que cela semblait plus propre.

La VM a démarré correctement—une fois. Après un reboot de maintenance, elle est revenue avec un écran noir. L’astreinte a tenté les classiques :
réinstaller les pilotes, changer les câbles, basculer les réglages OVMF. Sans succès. La VM était vivante sur le réseau, mais la sortie locale n’est jamais revenue.

L’hypothèse cachée était que le GPU présenterait toujours un affichage de boot utilisable à OVMF. En réalité, le chemin d’option ROM de la carte
n’était pas consistant dans cette configuration. Sans affichage émulé, il n’y avait rien à voir pendant l’amorçage et l’initialisation du pilote échouait silencieusement.

La correction fut ennuyeuse : réajouter un affichage émulé pour l’installation et le dépannage, conserver Q35+OVMF, passer les deux fonctions GPU,
et ne retirer l’adaptateur émulé qu’après avoir confirmé la stabilité du GPU sur plusieurs reboots. Ils ont aussi ajouté un petit GPU secondaire pour la console hôte.
L’“accélération pas chère” est devenue moins chère en heures humaines immédiatement.

Incident n°2 : L’optimisation qui s’est retournée contre eux

Une autre organisation courait après la latence et a décidé de “tout tuner” : hugepages, pinning CPU, économies d’énergie agressives, ASPM activé,
et une ligne de commande noyau personnalisée copiée depuis un fil de forum qui avait l’air autoritaire.

La VM passthrough GPU démarrerait, afficherait la sortie, puis deviendrait noire sous charge—généralement quand un job de rendu commençait.
Leur premier réflexe fut les pilotes. Ils ont piné plus de cœurs. Ils ont changé les profils d’alimentation Windows. Ils ont même changé de moniteurs.
L’écran noir revenait comme une suite non demandée.

Finalement, en regardant dmesg, ils ont découvert que le remappage d’interruptions ne faisait pas ce qu’ils pensaient à cause d’interactions entre le BIOS et le mode x2APIC.
Le système était assez stable pour des usages légers, instable sous forte activité DMA/interrupts.
L’“optimisation” (gestion d’énergie agressive + flags noyau douteux) avait transformé une configuration passable en une configuration instable.

La correction fut de revenir à une base connue bonne : paramètres noyau Proxmox par défaut pour IOMMU, mise à jour du BIOS,
désactivation d’ASPM pendant la validation, puis réintroduction progressive des optimisations avec plan de rollback.
Les performances se sont améliorées parce que le système a cessé de tomber. C’est une optimisation sous-estimée.

Incident n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une troisième équipe exploitait le passthrough GPU pour une petite pipeline CI interne nécessitant des builds CUDA. Pas glamour, mais proche de la prod.
Ils avaient une règle : tout changement d’infrastructure avait un snapshot de la config VM et un dump d’état hôte “known state”.
Ils tenaient aussi un log texte des PCI IDs GPU, des groupes IOMMU, et de la version exacte du noyau Proxmox utilisée.

Un matin, après une mise à jour noyau de routine, les VMs ont commencé à booter sur des écrans noirs. La panique a failli apparaître — cette pipeline alimentait des releases.
Mais l’équipe avait des preuves : ils ont comparé qm config avant/après, confirmé que les PCI IDs n’avaient pas changé,
et ont vu immédiatement que le GPU s’était rebindi sur un pilote hôte après la mise à jour d’initramfs.

Parce qu’ils avaient une checklist, ils n’ont pas perdu de temps en débats. Ils ont régénéré initramfs, confirmé le binding VFIO, rebooté une fois,
et récupéré rapidement. Pas d’héroïsme. Pas de “réinstallons l’invité”. Juste une vérification disciplinée.

La pratique n’était pas sexy, mais elle a raccourci l’incident. En ops, le correctif le plus rapide est souvent “prouver ce qui a changé” puis l’annuler proprement.

Checklists / plan pas à pas

Checklist A : Préparation de l’hôte (faire avant de toucher la VM)

1. Activez VT-d/AMD-Vi et (si disponible) le remappage d’interruptions dans le BIOS.
2. Activez Above 4G decoding pour les GPU modernes ; désactivez Resizable BAR temporairement si vous déboguez.
3. Démarrez l’hôte et vérifiez IOMMU activé dans dmesg.
4. Confirmez les PCI IDs du GPU et l’isolation des groupes IOMMU.
5. Lie le GPU + fonction audio à vfio-pci dans initramfs ; blacklistez les pilotes GPU natifs.
6. Rebootez et revérifiez lspci -nnk pour le binding vfio-pci.

Checklist B : Configuration VM Proxmox (defaults stables)

1. Utilisez le type de machine Q35 et le BIOS OVMF pour la plupart des GPU modernes.
2. Ajoutez un disque EFI (variables UEFI) pour OVMF.
3. Passez le GPU et sa fonction audio avec pcie=1.
4. Commencez avec un affichage émulé présent pour l’installation/le débogage ; retirez-le plus tard si nécessaire.
5. Définissez le type CPU sur host ; pour NVIDIA/Windows, considérez hidden=1.
6. Démarrez une fois, installez les pilotes, redémarrez plusieurs fois pour valider le comportement de reset.

Checklist C : Plan de réponse écran noir (quand ça pète à 2h du matin)

1. Confirmez que la VM est vivante sur le réseau (ping, RDP/SSH). Si elle répond, suspectez la sortie/les pilotes plutôt qu’un échec de boot.
2. Vérifiez journalctl -u pve-qm@VMID pour des erreurs VFIO/BAR/groupe.
3. Vérifiez le binding GPU sur l’hôte et les messages de reset dans dmesg.
4. Si c’est le bug de reset, faites un reboot contrôlé de l’hôte pour restaurer le GPU, puis planifiez un vrai correctif (pas “ne plus jamais redémarrer”).
5. Documentez ce qui a changé depuis le dernier état connu bon : mise à jour noyau, réglage BIOS, mise à jour pilote, config matérielle VM.

FAQ

1) Pourquoi ma VM boote bien, mais l’écran devient noir quand les pilotes GPU s’installent ?

C’est souvent la transition du framebuffer VGA/UEFI basique vers le mode-setting complet du pilote. Suspectez un mismatch firmware/type de machine,
une fonction audio manquante, la gestion d’alimentation, ou une bizarrerie pilote/hyperviseur (incluant le Code 43 sur certaines configurations).

2) Dois-je utiliser OVMF ou SeaBIOS pour le passthrough GPU ?

Utilisez OVMF pour la plupart des GPU modernes et des OS invités modernes. SeaBIOS sert pour des cas legacy spécifiques ou pour le dépannage,
et il réduit vos options avec du hardware récent.

3) Q35 ou i440fx ?

Q35 sauf raison contraire. Les GPU sont des périphériques PCIe ; Q35 gère le PCIe plus naturellement et évite beaucoup d’étrangetés.

4) Dois-je vraiment passer la fonction audio du GPU ?

En pratique : oui, la plupart du temps. Cela améliore la stabilité des pilotes et peut réduire les cas limites liés aux resets et à l’initialisation.
Si vous l’omettez, vous choisissez une configuration plus fragile.

5) Mon hôte n’a qu’un seul GPU. Puis-je le passer et continuer à gérer Proxmox ?

Oui, mais attendez-vous à gérer en headless (SSH, interface web) et acceptez que la console locale puisse disparaître.
Si vous tenez à votre tension artérielle, utilisez un iGPU, IPMI, ou un GPU secondaire bon marché pour l’hôte.

6) Quelle est la manière la plus rapide de savoir si c’est un problème hôte ou invité ?

Si les logs QEMU montrent des erreurs VFIO/groupe/BAR, c’est l’hôte/firmware. Si la VM est atteignable sur le réseau mais n’a pas d’affichage, c’est pilote/invité/sortie.
Si ça casse seulement après redémarrage de la VM, c’est probablement un problème de reset.

7) “iommu=pt” cause-t-il des écrans noirs ?

En général non ; c’est un réglage courant de performance. Mais si votre plateforme a déjà un comportement IOMMU fragile, tout tuning peut l’exposer.
Si vous déboguez, simplifiez : gardez les flags IOMMU nécessaires, retirez les réglages non essentiels.

8) Comment savoir si j’ai un bug de reset ?

Le pattern est : le premier démarrage de la VM fonctionne, les démarrages suivants après l’arrêt de la VM donnent un écran noir, et dmesg affiche des timeouts VFIO reset.
Un reboot complet de l’hôte “corrige” temporairement. C’est votre indice.

9) ACS override est-il sûr ?

C’est un contournement qui échange des garanties d’isolation contre de la commodité. Pour un labo, c’est souvent acceptable.
En production, préférez du hardware qui donne des groupes IOMMU propres sans astuces.

10) Pourquoi la console Proxmox n’affiche rien alors que le GPU est passé ?

La console Proxmox sert l’affichage émulé. Si vous comptez sur la sortie GPU passée, la console peut être volontairement vide.
Gardez un adaptateur émulé pendant le débogage pour avoir des yeux à l’intérieur de la VM.

Conclusion : prochaines étapes pratiques

Traitez un écran noir comme un problème de routage, pas comme une humeur. Commencez par l’hôte : IOMMU activé, groupe IOMMU propre, binding vfio-pci.
Puis validez le firmware et le modèle de machine de la VM (OVMF + Q35 est la base saine). Ce n’est qu’ensuite que vous poursuivez les pilotes invités et les quirks de moniteur.

Prochaines étapes qui rapportent immédiatement :

• Capturez un « état connu bon » : /proc/cmdline, lspci -nnk, groupes IOMMU, et qm config.
• Prouvez le binding VFIO après chaque mise à jour du noyau (les changements d’initramfs peuvent vous ramener aux pilotes hôtes).
• Validez les resets en effectuant plusieurs cycles arrêt/démarrage de la VM avant de considérer la configuration comme stable.
• Si vous tombez sur un bug de reset, cessez de négocier avec ce GPU et changez de plan : module contournement, modèle différent, ou accepter les reboots hôte.