Proxmox PCI Passthrough en échec : groupes IOMMU et pièges classiques

Feuille de route de diagnostic rapide

Si vous êtes d’astreinte et qu’une VM ne démarre pas après activation du passthrough, vous n’avez pas besoin de philosophie. Vous devez trouver le goulot d’étranglement rapidement.
Voici la feuille de route courte que j’utilise en production, dans l’ordre qui révèle le plus avec le moins d’effort.

1) Confirmer que l’IOMMU est réellement activé (BIOS + noyau)

La plupart des tickets « VFIO est cassé » correspondent à « IOMMU jamais activé ». Ou il est activé dans le BIOS mais désactivé dans le noyau, ou l’inverse.
Vérifiez d’abord les logs du noyau et la ligne de commande active ; ne devinez pas.

2) Vérifier le groupe IOMMU du périphérique cible

Si le GPU partage un groupe avec un contrôleur SATA, ce n’est pas une situation « on verra ça plus tard ». C’est le problème.
Décidez tôt si vous pouvez accepter de passer tout le groupe, si l’ACS override est acceptable, ou si vous avez besoin d’un autre matériel.

3) Vérifier qui possède actuellement le périphérique

Si l’hôte utilise le GPU pour la sortie console, ou si la carte réseau est revendiquée par un module noyau, la VM ne peut pas la prendre.
Assignez à vfio-pci et blacklistz le pilote concurrent. Vérifiez avec lspci -k.

4) Valider les choix de configuration VM qui vous sabotent silencieusement

Le type de machine, la taille du ROM BAR, la sélection du GPU principal, UEFI vs SeaBIOS, et les quirks de reset causent 80% des problèmes d’écran noir.
C’est là que vous arrêtez de « tester des trucs au hasard sur les forums » et que vous commencez à faire des choix intentionnels.

5) Ensuite seulement : chassez les bizarreries spécifiques au vendeur

NVIDIA Code 43, bugs de reset AMD, alternatives Intel iGPU GVT, et périphériques multifonctions sont réels — mais n’y allez pas tant que les fondamentaux ne sont pas propres.

Une idée paraphrasée de Leslie Lamport s’applique ici : Idée paraphrasée : un système distribué échoue à cause d’un composant dont vous n’aviez même pas connaissance. — Leslie Lamport

Groupes IOMMU : qu’est-ce que c’est et pourquoi s’en soucier

Un IOMMU est la frontière matérielle qui permet à l’hôte de contrôler comment les périphériques PCIe accèdent à la mémoire. Sans lui, le passthrough est essentiellement
« s’il vous plaît ne faites pas de DMA dans mon hyperviseur », ce qui n’est pas un modèle de sécurité — plutôt un modèle d’espoir et de prière.
Avec l’IOMMU, vous pouvez donner un périphérique à une VM tout en appliquant l’isolation mémoire.

Les groupes IOMMU sont la conséquence pratique de la topologie PCIe. Les périphériques derrière le même pont upstream sans isolation correcte
(ACS : Access Control Services) ne peuvent pas être séparés proprement. Linux les groupe ensuite, ce qui signifie : si vous passez un périphérique,
vous devez traiter l’ensemble du groupe comme potentiellement capable d’espionner ou d’interférer avec les autres.

Les opérateurs comprennent souvent cela de manière très précise mais erronée : ils pensent que les groupes sont une suggestion. Ce n’est pas le cas.
Ce sont les descriptions du noyau sur ce que le matériel peut isoler en toute sécurité. Parfois vous pouvez « tricher » avec l’ACS override ; parfois vous ne devriez pas.

Les trois catégories d’échec du passthrough

• Échec d’isolation : le périphérique est dans un groupe contenant des éléments que vous ne pouvez pas sacrifier (par ex. contrôleur de stockage, USB hôte, NIC principal).
• Échec de propriété : le pilote du noyau hôte possède le périphérique (ou les services Proxmox le font), donc VFIO ne peut pas le binder.
• Échec d’exécution : la VM démarre mais le périphérique ne s’initialise pas (problèmes de reset, quirks ROM, mismatch firmware, dimensionnement des BAR, détection du pilote GPU).

Traitez ces catégories comme un arbre de décision. Ne continuez pas à « bidouiller » sans savoir dans quelle catégorie vous vous trouvez.

Blague #1 : les groupes IOMMU sont comme les organigrammes — tout semble séparable jusqu’à ce que vous essayiez de déplacer une personne et découvriez que trois équipes s’effondrent.

Faits et histoire qui expliquent la douleur d’aujourd’hui

Vous pouvez exécuter le passthrough sans connaître l’histoire, mais la connaître aide à prédire quelles plates-formes se comporteront bien et lesquelles vous mèneront en bateau.
Voici des points concrets qui comptent opérationnellement.

1. VT-d (Intel) et AMD-Vi (AMD) sont arrivés comme la version « DMA » de la virtualisation, pas la version compute. La virtualisation CPU (VT-x/AMD-V) ne suffit pas pour le passthrough PCI.
2. Les chipsets grand public précoces ont souvent implémenté mal l’IOMMU ou avec une isolation limitée ; les plates-formes serveur faisaient ça correctement en premier.
3. PCIe ACS est devenu l’élément central pour la séparation des groupes ; de nombreuses cartes mères grand public omettent les fonctionnalités ACS sur les ports downstream, créant de grands groupes.
4. VFIO a remplacé les anciennes méthodes d’assignation de périphériques (historiquement KVM utilisait un mélange de mécanismes). VFIO a standardisé l’accès sécurisé aux périphériques et est la base moderne.
5. Le passthrough GPU s’est développé à l’ombre des politiques des fournisseurs ; les pilotes ont parfois un comportement différent en VM, et la communauté a construit des contournements.
6. L’adoption d’UEFI a changé la façon dont les ROM d’option sont chargées et comment les GPU s’initialisent. Beaucoup d’incidents d’écran noir sont en réalité des incompatibilités firmware/chaîne de démarrage.
7. Resizable BAR est excellent pour les performances sur métal nu, mais peut compliquer le passthrough et le mappage des BAR en VM selon la plate-forme et le firmware.
8. Les noyaux modernes renforcent la sécurité ; ce qui « fonctionnait » avec des valeurs par défaut permissives il y a des années peut maintenant nécessiter des options explicites (et c’est une bonne chose).
9. Les patches d’ACS override sont devenus populaires précisément parce que l’écosystème matériel ne priorisait pas l’isolation propre pour les amateurs — utile, mais un compromis.

Tâches pratiques (commandes, sorties, décisions)

L’objectif ici n’est pas de déverser des commandes. C’est de faire en sorte que chaque commande mérite sa place : exécutez-la, interprétez la sortie, puis prenez une décision.
Les exemples d’hôte supposent un nœud Proxmox basé sur Debian.

Task 1: Confirm CPU virtualization and IOMMU capability

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name|Vendor ID'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) CPU E-2246G @ 3.60GHz
Virtualization:        VT-x

Ce que cela signifie : VT-x/AMD-V est présent, mais cela ne confirme pas que VT-d/AMD-Vi est activé.
Décision : passez aux vérifications du noyau/IOMMU ; ne supposez pas que VT-d existe simplement parce que VT-x est présent.

Task 2: Check kernel boot parameters for IOMMU

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

Ce que cela signifie : intel_iommu=on active l’IOMMU Intel ; iommu=pt utilise le mapping pass-through pour les périphériques hôtes (réduit souvent la surcharge).
Décision : si ces flags ne sont pas présents, ajoutez-les et redémarrez avant toute autre action.

Task 3: Verify IOMMU actually initialized

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 15
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.112345] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.112678] DMAR: Initialized

Ce que cela signifie : le noyau voit et a activé l’IOMMU.
Décision : si vous ne voyez pas « IOMMU enabled/Initialized », allez dans le BIOS (VT-d/AMD-Vi) et corrigez la plate-forme d’abord.

Task 4: List PCI devices with IDs (you will need these)

cr0x@server:~$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87]
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8]
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Ce que cela signifie : vous avez des IDs de périphérique comme 10de:1e87 (GPU) et 10de:10f8 (sa fonction audio).
Décision : planifiez de passer l’ensemble du multifunction (GPU + audio) sauf si vous avez une bonne raison de ne pas le faire.

Task 5: Print IOMMU groups (the “can I isolate it?” test)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; lspci -nns "$(basename -a $g/devices/*)"; echo; done
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]

Group 7
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87]
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8]

Group 8
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Ce que cela signifie : le GPU est dans un petit groupe avec sa fonction audio — c’est bien.
Décision : si votre périphérique cible partage un groupe avec des périphériques critiques de l’hôte (contrôleur SATA, contrôleur USB nécessaire pour le clavier, la seule NIC),
vous devez soit passer tout le groupe, changer d’emplacement/paramètres BIOS, utiliser ACS override en connaissance de cause, ou changer de matériel.

Task 6: Identify which driver currently owns the device

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3751
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que cela signifie : le pilote NVIDIA de l’hôte est chargé ; VFIO ne peut pas prendre la carte sans la détacher/rebinder.
Décision : supprimez l’utilisation hôte du GPU (pas de console, pas de Xorg), blacklistez le pilote si nécessaire, et bindez sur vfio-pci.

Task 7: Make sure VFIO modules are available and loaded

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          94208  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   40960  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             372736  0
kvm                  1036288  1 kvm_intel

Ce que cela signifie : VFIO est présent.
Décision : si les modules VFIO manquent, installez les bons paquets du noyau et assurez-vous que le noyau Proxmox correspond aux attentes.

Task 8: Bind a device to vfio-pci using device IDs

cr0x@server:~$ sudo sh -c 'echo "options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1" > /etc/modprobe.d/vfio.conf'
cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1

Ce que cela signifie : au prochain démarrage, VFIO revendiquera les fonctions GPU tôt.
Décision : faites cela quand vous voulez que le passthrough soit stable across reboots. Les astuces de détachement temporaires sont bien pour expérimenter, pas pour la production.

Task 9: Blacklist conflicting GPU drivers (nouveau is a frequent squatter)

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset
EOF
cr0x@server:~$ cat /etc/modprobe.d/blacklist-gpu.conf
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset

Ce que cela signifie : vous empêchez l’hôte de « charger utilement » un pilote qui volerait votre périphérique de passthrough.
Décision : blacklistz seulement ce qui est nécessaire. Si l’hôte a besoin d’un GPU pour la console, utilisez l’iGPU ou une carte secondaire bon marché et passez l’autre.

Task 10: Update initramfs so early binding/blacklists actually apply

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

Ce que cela signifie : votre environnement de boot pre-init contient maintenant les nouveaux réglages de modules.
Décision : si vous sautez cette étape, vous passerez un long après-midi à regarder le mauvais pilote chargé « mystérieusement » avant le montage du rootfs.

Task 11: After reboot, confirm vfio owns the device

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3751
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que cela signifie : propriété correcte. Notez que « Kernel modules » peut lister des candidats ; « driver in use » est ce qui compte.
Décision : si ce n’est toujours pas vfio-pci, revoyez les blacklists, initramfs, et si le périphérique est utilisé comme VGA de démarrage.

Task 12: Confirm Proxmox/QEMU sees the IOMMU device nodes

cr0x@server:~$ ls -l /dev/vfio/
total 0
crw------- 1 root root 240,   0 Dec 26 09:12 0
crw------- 1 root root 240,   7 Dec 26 09:12 7
crw------- 1 root root 240, 255 Dec 26 09:12 vfio

Ce que cela signifie : les nœuds de groupe existent (ici le groupe 7 est présent).
Décision : si le nœud de groupe n’est pas présent, votre groupement IOMMU n’est pas actif ou le noyau n’expose pas VFIO correctement.

Task 13: Check if the device supports reset cleanly (common GPU trap)

cr0x@server:~$ sudo dmesg | egrep -i 'vfio|reset|FLR|D3' | tail -n 20
[  112.334455] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  112.334890] vfio-pci 0000:01:00.0: not capable of FLR, device reset may be unreliable

Ce que cela signifie : pas de Function Level Reset (FLR). Cela apparaît souvent comme « marche une fois, puis échoue au redémarrage de la VM » parce que le périphérique ne se réinitialise jamais.
Décision : planifiez autour de cela : cycle d’alimentation de l’hôte entre les exécutions VM, utilisez des modules de reset fournisseur si approprié, ou choisissez du matériel avec des resets fiables.

Task 14: Validate VM config for PCIe and OVMF (Proxmox qm config)

cr0x@server:~$ qm config 110
agent: 1
bios: ovmf
boot: order=scsi0;ide2;net0
machine: q35
memory: 16384
name: win11-gpu
ostype: win11
scsi0: local-lvm:vm-110-disk-0,size=200G
hostpci0: 01:00.0,pcie=1,x-vga=1
hostpci1: 01:00.1,pcie=1
efidisk0: local-lvm:vm-110-disk-1,size=1M,efitype=4m,pre-enrolled-keys=1

Ce que cela signifie : c’est la base saine pour de nombreux GPU : q35 + OVMF + pcie=1 et x-vga=1 pour un GPU principal.
Décision : si vous utilisez i440fx pour un GPU moderne et obtenez des bizarreries, passez à q35 sauf raison spécifique contraire.

Task 15: If VM won’t start, read the real error message in QEMU logs

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:server:00004A2C:0001D2B1:676D5B2A:qmstart:110:root@pam:
cr0x@server:~$ journalctl -u pvedaemon -n 80 --no-pager
Dec 26 09:20:11 server pvedaemon[1324]: start VM 110: UPID:server:00004A2C:0001D2B1:676D5B2A:qmstart:110:root@pam:
Dec 26 09:20:11 server pvedaemon[1324]: VM 110 qmp command failed - unable to open /dev/vfio/7: Device or resource busy

Ce que cela signifie : « busy » est généralement un problème de propriété ou un processus en suspens.
Décision : trouvez qui tient le groupe VFIO et tuez-le proprement (ou arrêtez la VM qui l’utilise déjà).

Task 16: Find which process is holding the device/group

cr0x@server:~$ sudo lsof /dev/vfio/7
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 991 root   25u   CHR  240,7      0t0  165 /dev/vfio/7

Ce que cela signifie : un processus QEMU détient déjà le groupe.
Décision : arrêtez la VM propriétaire. Si c’est un QEMU planté, terminez-le et investiguez pourquoi il n’a pas libéré VFIO.

Task 17: Inspect PCIe topology to understand grouping problems

cr0x@server:~$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           |            \-00.1
           \-02.0-[02]----00.0

Ce que cela signifie : le GPU est derrière le bus 01 ; le NVMe derrière le bus 02. Une séparation propre implique souvent des groupes propres.
Décision : si tout est sous un même port downstream, attendez-vous à des groupes désordonnés. Envisagez de déplacer les cartes vers des emplacements différents (raccordés à des root ports distincts).

Task 18: If you must, test ACS override and see what groups become (risk-aware)

cr0x@server:~$ sudo sed -i 's/quiet/quiet pcie_acs_override=downstream,multifunction/' /etc/default/grub
cr0x@server:~$ grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_acs_override=downstream,multifunction intel_iommu=on iommu=pt"
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
done

Ce que cela signifie : vous demandez au noyau de faire semblant qu’une isolation ACS existe là où elle peut ne pas exister.
Décision : utilisez ceci seulement si vous acceptez le compromis isolation/sécurité. Dans les environnements multi-locataires ou soumis à conformité, évitez-le.

Blague #2 : l’ACS override, c’est comme enlever la bande « interdit d’entrer » parce qu’elle vous ralentit — jusqu’à ce que vous vous souveniez pourquoi la bande existait.

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

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une équipe a déployé des nœuds Proxmox pour héberger des VMs Windows accélérées par GPU pour une unité métier qui utilisait une application legacy avec rendu GPU.
Ils ont testé sur une carte mère « golden » et ça fonctionnait. Les achats ont ensuite pris une autre révision de carte mère parce qu’elle était « équivalente ».
« Équivalent » est un mot dangereux en infrastructure.

Sur les nouvelles cartes, le groupe IOMMU du GPU contenait aussi un contrôleur USB et l’audio onboard. L’équipe a supposé :
« Nous passons seulement le GPU, donc le contrôleur USB ne devrait pas importer. » Ils ont activé l’ACS override pour scinder les groupes,
se sont félicités, et sont passés en production.

Quelques semaines plus tard, des VMs ont commencé à se figer pendant les pics de charge. Pas planter. Figées. L’hôte restait up, mais les processus QEMU se retrouvaient dans des états
nécessitant un kill forcé. Le taux de gel augmentait avec l’activité USB : lecteurs de cartes à puce, caméras USB, périphériques étranges.
Vous voyez probablement où ça mène.

Les groupes IOMMU « scindés » n’étaient pas une isolation réelle ; c’étaient des frontières imposées par le logiciel. Sous charge, des périphériques partageant le même chemin physique
interagissaient encore d’une manière que VFIO ne pouvait pas pleinement contrôler. Le résultat n’a pas été une faille de sécurité nette ; c’était un cauchemar opérationnel :
resets non fiables, interruptions instables, et VMs bloquées ressemblant à des problèmes de pilotes.

La correction fut peu glamour : ils ont migré vers des cartes avec une isolation ACS correcte sur les root ports PCIe et ont cessé d’outrepasser la réalité.
La ligne clé du post-mortem : l’hypothèse que les groupes IOMMU sont « juste un groupage Linux » plutôt que « des frontières de confinement matériel ».
Cette phrase leur a probablement évité une année d’incidents récurrents.

Mini-récit 2 : L’optimisation qui a échoué

Une autre organisation a voulu gagner en performance. Ils ont lu que iommu=pt réduit la surcharge pour les périphériques hôtes, donc ils l’ont ajouté partout.
Puis ils sont allés plus loin : réglages du noyau, réarrangements d’interruptions, et réglages agressifs d’économie d’énergie dans le BIOS parce que l’efficacité énergétique était séduisante sur une slide.

Le passthrough fonctionnait — principalement. Mais après des fenêtres de maintenance, certaines VMs démarreraient avec le GPU manquant, ou la NIC passée à une VM firewall
perdrait le lien jusqu’au redémarrage de la VM. L’équipe a traité ça comme des « bizarreries matérielles transitoires ».
Ces mots sont la façon dont des incidents deviennent récurrents.

Le coupable était une combinaison de gestion d’alimentation (périphériques tombant dans des états D profonds), comportement firmware, et capacité de reset.
Certains périphériques ne toléraient pas les nouveaux réglages ; d’autres avaient besoin d’un reset explicite. L’« optimisation » n’était pas mauvaise en général.
Elle était inadaptée à leur mélange spécifique de périphériques et de contraintes d’uptime.

Ils ont annulé les fonctionnalités d’économie pour le fabric PCIe, arrêté de courir après des micro-optimisations sans mesure, et documenté une règle stricte :
les nœuds passthrough en production ont des réglages PCIe conservateurs et seulement des paramètres noyau éprouvés.
Les performances ont un peu diminué par rapport aux espoirs, mais la fiabilité a augmenté drastiquement — et c’est ce qui paye votre salaire à long terme.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une petite équipe plateforme gérait une flotte de nœuds Proxmox avec des workloads mixtes. Certaines VMs utilisaient des NIC en passthrough ; d’autres des GPUs.
Leur pratique était résolument ennuyeuse : chaque nœud avait une note « topologie matérielle » mise à jour après tout changement physique — carte des slots, groupes IOMMU,
et quelle VM consommait quel groupe.

Un week-end, un nœud est tombé et un technicien l’a remplacé par un châssis de secours, déplaçant rapidement les cartes pour restaurer le service.
Les VMs sont revenues, mais une VM de stockage qui utilisait un HBA passé en passthrough a commencé à renvoyer des erreurs, tandis qu’une autre VM utilisant une NIC en passthrough
ne démarrait plus du tout.

Au lieu d’expérimenter en production, ils ont sorti la note de topologie. Elle montrait que sur le châssis de secours, le HBA et la NIC se retrouvaient dans le même groupe.
Ce n’était pas un problème de configuration Linux ; c’était un mauvais emplacement/une mauvaise topologie. Ils ont arrêté le nœud, déplacé une carte au bon emplacement,
et ont remis les services sans longue interruption.

Pas d’héroïsme. Pas de patch noyau. Pas d’ACS override aveugle. Juste de la documentation et de la discipline sur le mapping « ce slot PCIe mène à ce root port et à ce groupe IOMMU ».
La pratique était assez ennuyeuse pour que personne n’ait envie de la faire — jusqu’à ce qu’elle sauve un week-end et une réputation.

Erreurs courantes : symptôme → cause racine → correction

1) La VM ne démarre pas : « unable to open /dev/vfio/X: Device or resource busy »

Cause racine : un processus tient déjà le groupe VFIO (une autre VM, QEMU bloqué, ou état de binding résiduel).

Correction : identifiez le propriétaire avec lsof /dev/vfio/X, arrêtez la VM propriétaire, et nettoyez les processus QEMU en attente. Confirmez que la propriété du groupe est unique.

2) La VM démarre, mais le GPU affiche un écran noir

Cause racine : mauvais firmware/type de machine VM (SeaBIOS vs OVMF, i440fx vs q35), ROM GPU manquante, ou GPU non défini comme principal.

Correction : utilisez bios: ovmf, machine: q35, hostpci0: ...,pcie=1,x-vga=1. Assurez-vous de passer toutes les fonctions (audio GPU).

3) Le GPU fonctionne une fois, puis échoue après redémarrage de la VM

Cause racine : bug de reset ou absence de support FLR ; le périphérique ne se réinitialise pas proprement.

Correction : préférez du matériel avec FLR ; sinon planifiez opérationnellement (reboot de l’hôte pour reset propre) ou utilisez un module de contournement de reset quand approprié.

4) Le périphérique ne se bind pas à vfio-pci ; le pilote hôte continue de le prendre

Cause racine : le pilote se charge dans l’initramfs avant que vfio-pci ne réclame le périphérique ; les blacklists ne sont pas appliquées tôt.

Correction : configurez /etc/modprobe.d/vfio.conf + le fichier de blacklist, puis update-initramfs -u. Redémarrez et vérifiez avec lspci -k.

5) Les groupes IOMMU sont énormes ; le GPU partage le groupe avec SATA/USB/NIC

Cause racine : topologie PCIe de la carte mère et absence d’isolation ACS ; parfois des réglages BIOS empirent la situation.

Correction : essayez d’autres emplacements, désactivez « above 4G decoding » seulement si cela change réellement le groupage (souvent il faut le laisser activé), envisagez une autre carte mère.
Utilisez l’ACS override seulement si vous acceptez une isolation réduite.

6) La VM Windows affiche une erreur GPU (par ex. le pilote ne se charge pas, périphérique désactivé)

Cause racine : mismatch de configuration VM (GPU principal), UEFI manquant, ou détection vendor/driver de virtualisation.

Correction : corrigez d’abord la config q35/OVMF ; traitez ensuite les problèmes spécifiques au fournisseur seulement s’ils persistent.

7) La NIC en passthrough perd le lien de manière aléatoire

Cause racine : états d’alimentation, quirks de remapping d’interruptions, ou comportement de reset instable sur cette NIC/slot.

Correction : définissez des réglages PCIe conservateurs dans le BIOS, mettez à jour le firmware, et validez les logs de remapping d’interruptions. Envisagez de déplacer les slots/root ports.

8) L’hôte Proxmox devient instable lorsque l’ACS override est activé

Cause racine : vous avez scindé des groupes en logiciel qui ne sont pas isolés matériellement ; les chemins DMA/interruptions collident toujours.

Correction : supprimez l’ACS override, repensez la topologie matérielle, ou passez les groupes entiers (et acceptez de perdre ces périphériques pour l’hôte).

Checklists / plan pas à pas

Étapes pas à pas : mettre en place le passthrough sans drame

1. BIOS d’abord : activez VT-d (Intel) ou AMD-Vi (AMD). Désactivez CSM si possible, et gardez la gestion d’énergie PCIe conservatrice.
2. Flags noyau : mettez intel_iommu=on iommu=pt (ou amd_iommu=on iommu=pt) dans votre chargeur de démarrage.
3. Vérifier l’initialisation IOMMU : checkez dmesg pour « IOMMU enabled/Initialized ».
4. Cartographiez votre périphérique cible : notez son adresse PCI et ses IDs via lspci -nn.
5. Inspectez les groupes IOMMU : si le groupe contient des éléments que vous ne pouvez pas perdre, arrêtez-vous et redesign (déplacez le slot ou changez le matériel).
6. Bindez à vfio-pci : ajoutez options vfio-pci ids=... et blacklistz les pilotes concurrents.
7. Mettre à jour initramfs et redémarrer : rendez le binding précoce effectif.
8. Confirmez le binding : lspci -k doit afficher Kernel driver in use: vfio-pci.
9. Configurez la VM intentionnellement : q35 + OVMF pour les GPU modernes, incluez toutes les fonctions, mettez pcie=1.
10. Validez avec les logs : si ça échoue, lisez les logs QEMU/daemon ; ne devinez pas.
11. Testez les cycles de redémarrage : pas seulement « ça a démarré une fois », mais « ça survit aux redémarrages du guest et aux politiques de cycle de vie ».
12. Documentez la topologie : notez slot → adresse PCI → groupe IOMMU → VM consommatrice. Le vous du futur remerciera le vous du présent.

Checklist opérationnelle : avant de déclarer « prêt pour la production »

• L’hôte démarre sans avoir besoin du GPU passthrough pour la console (ou possède un GPU/iGPU de console séparé).
• Tous les périphériques du groupe IOMMU sont soit passés ensemble, soit inoffensifs pour l’hôte.
• La VM survit à 10+ cycles start/stop et à au moins 3 redémarrages invités sans perte de périphérique.
• Les mises à jour du noyau de l’hôte ont un plan de rollback (et vous avez testé VFIO après au moins une mise à jour).
• Pas d’ACS override dans les environnements nécessitant une isolation forte (multi-tenant, conformité, modèle de menace adversaire).
• Vous pouvez expliquer le domaine de panne en une phrase : « Si le groupe 7 casse, cela affecte la VM 110 et rien d’autre. »

FAQ

1) Pourquoi dois-je passer le GPU avec son périphérique audio ?

Parce qu’il s’agit typiquement d’un périphérique PCI multifonction : fonction GPU à 01:00.0 et audio HDMI/DP à 01:00.1.
Ils partagent souvent l’initialisation et le comportement de reset. Passez les deux à moins d’avoir une raison testée de ne pas le faire.

2) L’ACS override est-il « sûr » ?

« Sûr » dépend de votre modèle de menace. L’ACS override peut faire apparaître à Linux des groupes plus petits, mais il ne peut pas ajouter d’isolation matérielle manquante.
Pour un lab à la maison, c’est souvent acceptable. Pour des environnements exigeant une isolation DMA stricte, évitez-le et corrigez la topologie avec du matériel.

3) Mon groupe IOMMU inclut le contrôleur SATA. Et maintenant ?

Ne passez pas ce groupe à moins d’être prêt à perdre l’accès stockage de l’hôte. Essayez un autre slot PCIe, vérifiez les options BIOS,
ou passez à une carte mère/plate-forme CPU avec une meilleure isolation des root ports.

4) Pourquoi Proxmox dit que le périphérique VFIO est occupé alors qu’aucune VM ne tourne ?

Souvent il y a un processus QEMU bloqué, une tâche de gestion qui tient encore le périphérique, ou une VM partiellement démarrée.
Utilisez lsof /dev/vfio/X pour trouver le processus. Puis arrêtez la VM proprement ou tuez le processus bloqué et consultez les logs.

5) Dois-je utiliser q35 ou i440fx pour le passthrough ?

Pour les GPU modernes et les périphériques PCIe, utilisez q35. Il modélise PCIe de façon plus naturelle et évite certaines bizarreries legacy.
Utilisez i440fx uniquement si vous avez une dépendance guest legacy ou une raison de compatibilité spécifique.

6) Ai-je besoin d’OVMF (UEFI) pour le passthrough GPU ?

Pas toujours, mais souvent oui. Beaucoup de GPU modernes et d’installations Windows 11 se comportent mieux avec OVMF.
Si vous observez des écrans noirs ou des problèmes d’initialisation, passer à OVMF est un changement à forte valeur.

7) Que signifie « not capable of FLR » ?

FLR est un mécanisme de reset standardisé. Sans lui, un périphérique peut ne pas se réinitialiser proprement entre les exécutions de VM.
Les symptômes incluent « marche une fois » et « échoue après redémarrage ». La correction opérationnelle peut être aussi brutale qu’un reboot hôte entre les runs, ou aussi définitive que du nouveau matériel.

8) Puis-je passer des périphériques à des conteneurs (LXC) au lieu de VMs ?

Certains accès périphériques peuvent être accordés aux conteneurs, mais le vrai passthrough PCI est une histoire de VM car vous avez besoin d’isolation matérielle et du comportement VFIO.
Si vous avez besoin d’une séparation forte et d’un contrôle complet du périphérique, utilisez une VM.

9) Pourquoi les groupes IOMMU changent après une mise à jour BIOS ?

Les mises à jour BIOS peuvent changer le routage PCIe, l’exposition ACS, et la façon dont les ponts sont énumérés. Cela peut remodeler les groupes.
Traitez les mises à jour BIOS comme un changement qui doit être validé pour les nœuds passthrough, pas comme un patch de routine.

10) Puis-je passer un contrôleur USB au lieu de périphériques USB individuels ?

Oui, et c’est souvent plus fiable pour des charges USB importantes (dongles, caméras, lecteurs de cartes).
Mais vérifiez attentivement son groupe IOMMU ; les contrôleurs USB partagent souvent des groupes avec d’autres périphériques du chipset.

Conclusion : prochaines étapes pour réellement avancer

Quand le passthrough PCI échoue sur Proxmox, le chemin le plus rapide est d’arrêter de le traiter comme de la magie et de commencer à le traiter comme topologie plus propriété plus firmware.
Vérifiez l’initialisation IOMMU, lisez les groupes, bindez les périphériques à VFIO tôt, et configurez les VMs intentionnellement (q35 + OVMF est la position par défaut pour les GPU modernes).

Prochaines actions pratiques :

• Exécutez le dump des groupes IOMMU et sauvegardez-le avec la documentation de votre nœud. Traitez-le comme un schéma de câblage.
• Vérifiez le binding avec lspci -k après chaque mise à jour du noyau et après tout changement BIOS.
• Si vous dépendez de l’ACS override en production, planifiez une migration matérielle/topologique. C’est une dette technique avec un tranchant PCIe.
• Testez des cycles de redémarrage, pas seulement le « premier boot ». La plupart des échecs sont liés au reset et au cycle de vie.

Le passthrough n’est pas difficile parce que Linux est compliqué. Il est difficile parce que le matériel est compliqué — et il en est très sûr.
Alignez-vous sur le matériel, et Proxmox paraîtra ennuyeux. L’ennui est l’objectif.