Pas d’IOMMU détecté sur Proxmox ? Corrigez-le en 10 minutes (UEFI + options du noyau)

février 7, 2026 • février 7, 2026 • Lecture : 30 min • Views: 0

Cet article vous a aidé ?

Vous essayez de faire la chose pour laquelle Proxmox est réputé : le passthrough PCIe. GPU, HBA, NIC, peu importe. Puis l’hôte vous informe calmement : Pas d’IOMMU détecté. Traduction : votre hyperviseur a les yeux bandés et vous lui demandez de jongler avec des tronçonneuses.

Cela n’est généralement pas « un bug Proxmox ». C’est un désaccord de réglages entre le mode du firmware (UEFI/Legacy), les fonctions de virtualisation du CPU (VT-d / AMD‑Vi) et les options du noyau qui activent effectivement l’IOMMU. La réparation est rapide quand on sait où regarder — et exaspérante quand on ne sait pas.

Ce que signifie réellement « Pas d’IOMMU détecté »

Sur la virtualisation x86, une IOMMU est le composant matériel qui permet à l’hôte de contrôler le DMA (accès direct à la mémoire) des périphériques. Sans elle, un périphérique PCIe peut potentiellement lire/écrire dans la mémoire où il ne devrait pas. C’est rédhibitoire pour un passthrough sûr.

Proxmox (KVM/QEMU en coulisses) a besoin que le noyau expose une IOMMU active. Si vous voyez « Pas d’IOMMU détecté », l’une des situations suivantes est vraie :

Le CPU/le chipset ne la prend pas en charge (rare sur serveurs modernes ; moins rare sur composants desktop bas de gamme).
Le firmware a désactivé la fonctionnalité (VT-d sur Intel, AMD‑Vi/IOMMU sur AMD).
Vous avez démarré dans un mode/configuration où le noyau ne l’a pas activée (flags du noyau manquants, mauvaise configuration du chargeur de démarrage, particularités du Secure Boot).
Elle est activée, mais vous regardez la mauvaise preuve (fréquent — on greppe le mauvais log puis on poursuit des fantômes).

Et voici la vérité opérationnelle importante : « IOMMU activée » n’est pas binaire en pratique. Vous pouvez avoir une IOMMU détectée avec un groupement catastrophique, un remappage d’interruptions cassé ou un périphérique qui ne réinitialise pas. Vous n’obtiendrez toujours pas de passthrough stable.

Guide de diagnostic rapide (premier/deuxième/troisième)

Si vous êtes pressé (vous l’êtes), faites ceci dans l’ordre. Ce n’est pas philosophique. C’est rapide.

Premier : prouver si le noyau voit une IOMMU

Vérifiez les messages du noyau en direct pour DMAR Intel ou AMD‑Vi. C’est la source de vérité la plus rapide.

cr0x@server:~$ dmesg | egrep -i 'dmar|iommu|amd-vi|ivrs' | head -n 50
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0

Ce que cela signifie : Si vous voyez « DMAR: IOMMU enabled » (Intel) ou « AMD-Vi: IOMMU enabled » (AMD), le message « Pas d’IOMMU détecté » provient d’un autre niveau ou d’un démarrage antérieur.

Décision : S’il n’y a aucune ligne pertinente, allez immédiatement vérifier le firmware et les options du noyau. S’il y a des lignes mais que le groupement est mauvais, passez à la section Groupes IOMMU.

Second : confirmer que vous avez démarré comme vous le pensez

cr0x@server:~$ cat /sys/firmware/efi/fw_platform_size 2>/dev/null || echo "Not booted via UEFI"
64

Ce que cela signifie : « 64 » signifie démarrage UEFI. Si vous obtenez « Not booted via UEFI », vous êtes en mode legacy. Cela peut encore fonctionner, mais l’UEFI est généralement moins imprévisible sur les plateformes modernes.

Décision : Si la plateforme supporte l’UEFI, utilisez-le. Mélanger un démarrage legacy avec des fonctions de virtualisation modernes est la manière la plus sûre de perdre son week-end.

Troisième : vérifier que les options du noyau sont effectivement appliquées

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

Ce que cela signifie : Vous devriez voir intel_iommu=on pour Intel ou amd_iommu=on pour AMD. Souvent vous voulez aussi iommu=pt pour réduire l’overhead pour les périphériques gérés par l’hôte.

Décision : Si les flags ne sont pas présents, corrigez GRUB ou systemd-boot. S’ils sont présents et que dmesg n’affiche toujours pas d’IOMMU, le firmware est en cause (ou le matériel).

Faits intéressants (et un peu d’histoire) sur l’IOMMU

Le DMA précède la virtualisation moderne de plusieurs décennies. Les premiers systèmes laissaient les périphériques écrire directement en mémoire parce que les CPU étaient lents et la copie de buffers coûteuse.
Le « VT-d » d’Intel et le « AMD‑Vi » d’AMD sont apparus parce que les hyperviseurs avaient besoin d’un DMA sûr. Sans IOMMU, le passthrough, c’est essentiellement « faire confiance au périphérique et prier ».
La table ACPI « DMAR » est un artefact clé. Sur les systèmes Intel, le noyau découvre souvent la capacité IOMMU via la table DMAR fournie par le firmware.
Le remappage d’interruptions compte. Une IOMMU fonctionnelle n’est pas qu’une traduction d’adresses ; un bon remappage d’interruptions réduit la surface d’attaque et améliore l’isolation.
Les groupes IOMMU sont principalement une histoire de carte mère/topologie. Les groupes dépendent des ports racine PCIe, des commutateurs et du comportement ACS (Access Control Services).
ACS n’a pas été inventé pour les labs domestiques. C’est une fonctionnalité PCIe conçue pour faire respecter l’isolation dans des environnements multi-fonctions/multi-tenant — puis les bricoleurs ont découvert que ça facilitait le layout VFIO.
« iommu=pt » est un compromis de performance. Il utilise des mappages en passthrough pour les périphériques de l’hôte afin de réduire la surcharge de traduction, tout en permettant l’isolation pour les périphériques VFIO.
L’UEFI n’a pas rendu cela plus simple ; il l’a rendu différent. Beaucoup de plateformes livrent de meilleures tables ACPI en mode UEFI, mais introduisent aussi Secure Boot et des complexités NVRAM.

Vérifications préalables : confirmer CPU, mode firmware et chargeur de démarrage Proxmox

Avant de toucher aux réglages du BIOS, confirmez ce que vous avez sous la main. C’est la base pour les systèmes en production : mesurer d’abord, changer ensuite.

Tâche 1 : Identifier le fabricant du CPU et les capacités de virtualisation

cr0x@server:~$ lscpu | egrep 'Vendor ID|Model name|Virtualization|Flags'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Xeon(R) CPU E-2278G @ 3.40GHz
Virtualization:                  VT-x
Flags:                           ... vmx ... dmar ...

Ce que cela signifie : Sur Intel, vous voulez VT-x (virtualisation CPU) et VT-d (IOMMU). VT-d ne s’affiche pas toujours comme « VT-d » ici ; vous l’inférerez typiquement via la plateforme et les logs DMAR. Sur AMD vous verrez « svm » pour la virtualisation CPU et vérifierez AMD‑Vi dans dmesg.

Décision : Si le CPU est un modèle bas de gamme ou un SKU embarqué étrange, confirmez d’abord qu’il prend en charge l’IOMMU avant d’accuser Proxmox.

Tâche 2 : Confirmer que les modules liés à l’IOMMU sont présents

cr0x@server:~$ lsmod | egrep 'vfio|iommu|kvm' | head
vfio_pci               16384  0
vfio_pci_core          69632  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 : Le chargement des modules VFIO n’atteste pas que l’IOMMU est activée, mais indique que le câblage de base n’est pas manquant.

Décision : Si VFIO est absent et que vous tentez le passthrough, il faudra le charger/configurer plus tard. Pour « Pas d’IOMMU détecté », concentrez-vous d’abord sur le firmware et la ligne de commande du noyau.

Tâche 3 : Déterminer si Proxmox utilise GRUB ou systemd-boot

cr0x@server:~$ proxmox-boot-tool status 2>/dev/null || echo "proxmox-boot-tool not in use"
Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace
System currently booted with: uefi
Configured ESPs: /boot/efi

Ce que cela signifie : Si proxmox-boot-tool est utilisé, vous êtes généralement sur systemd-boot avec une partition système EFI (ESP). S’il n’est pas utilisé, vous êtes peut-être sur GRUB.

Décision : Ne devinez pas quel chargeur de démarrage vous avez. Appliquez les options du noyau au bon endroit pour votre chemin de démarrage.

Tâche 4 : Confirmer les entrées actuelles du chargeur (chemin systemd-boot)

cr0x@server:~$ bootctl status 2>/dev/null | sed -n '1,120p'
System:
     Firmware: UEFI 2.70
  Secure Boot: disabled
   Setup Mode: user
Boot Loader:
     Product: systemd-boot 252
    Features: ✓ Boot counting
Default Boot Entry: proxmox

Ce que cela signifie : Vous utilisez systemd-boot. Proxmox gère couramment la ligne de commande du noyau via /etc/kernel/cmdline.

Décision : Si vous êtes sur systemd-boot, éditer /etc/default/grub peut ne rien changer. C’est un gaspillage de temps classique.

Tâche 5 : Confirmer que GRUB est installé/actif (chemin GRUB)

cr0x@server:~$ grub-probe /boot 2>/dev/null && echo "GRUB tooling present"
ext2
GRUB tooling present

Ce que cela signifie : L’outillage GRUB existe, mais n’atteste pas qu’il soit le chargeur actif. Combinez avec les vérifications UEFI ci‑dessus.

Décision : Si vous avez démarré en UEFI et que systemd-boot est actif, traitez GRUB comme une distraction sauf si vous l’avez installé volontairement.

Paramètres UEFI/BIOS importants (et ceux qui n’ont pas d’importance)

Les menus du firmware varient énormément, mais les concepts sont stables. Vous devez activer la fonction IOMMU et parfois quelques options annexes qui la rendent utilisable en pratique.

Plateformes Intel (libellés courants)

Intel Virtualization Technology (VT-x) : Active la virtualisation CPU. Nécessaire pour KVM, mais pas suffisante pour le passthrough.
Intel VT-d : C’est l’IOMMU. C’est celle que vous cherchez.
Above 4G decoding : Utile/nécessaire quand vous passez des GPU ou plusieurs périphériques qui mappent de grands BAR. Sur certaines cartes, cela modifie aussi l’allocation des ressources PCIe et améliore le groupement.
Resizable BAR : Peut compliquer le passthrough dans certains setups. Si vous déboguez, envisagez de le désactiver temporairement.
SR-IOV : Non requis pour IOMMU, mais souvent dans le même voisinage. Activez seulement si vous avez besoin de VFs.

Plateformes AMD (libellés courants)

SVM : Virtualisation CPU (KVM). Activez-la.
IOMMU / AMD‑Vi : L’IOMMU. Activez-la.
ACS / ACS Enable : Parfois exposé, parfois non. Ne comptez pas systématiquement sur sa présence.
Above 4G decoding : Même remarque que pour Intel ; souvent requis pour la stabilité des passthrough GPU.

Paramètres du firmware dont les gens s’obsèdent (généralement inutiles)

« UEFI vs Legacy » comme commutateur magique : L’UEFI peut aider, mais ne remplace pas l’activation de VT-d/AMD‑Vi.
C‑states : La gestion d’alimentation peut causer des problèmes de latence, pas un « Pas d’IOMMU détecté ». Ne changez pas dix réglages d’un coup.
XMP/EXPO : Les profils mémoire peuvent déstabiliser un hôte, mais ils ne désactivent pas l’IOMMU. Gardez-les conservateurs si c’est de la production.

Blague #1 : Si votre interface BIOS ressemble à un menu de lecteur DVD de 2009, ne paniquez pas — vos réglages IOMMU sont encore cachés quelque part.

Options du noyau : GRUB vs systemd-boot (la réparation en 10 minutes)

Une fois le firmware correct, le noyau doit encore activer l’IOMMU. Sur Proxmox, c’est typiquement un changement d’une ligne plus une mise à jour du chargeur de démarrage.

Choisissez vos options selon le fournisseur

Intel : intel_iommu=on iommu=pt
AMD : amd_iommu=on iommu=pt

Pourquoi iommu=pt ? C’est un défaut pragmatique pour de nombreux hôtes de virtualisation : les périphériques de l’hôte utilisent des mappages passthrough (moins d’overhead), tandis que les périphériques VFIO conservent l’isolation. Si vous visez une isolation maximale multi‑tenant, vous pouvez choisir autrement. La plupart des utilisateurs Proxmox ne le font pas.

Tâche 6 (systemd-boot) : Définir les options dans /etc/kernel/cmdline

cr0x@server:~$ sudo cat /etc/kernel/cmdline
root=ZFS=rpool/ROOT/pve-1 ro quiet

Ce que cela signifie : C’est votre modèle de ligne de commande du noyau.

Décision : Ajoutez les flags appropriés pour votre fournisseur CPU.

cr0x@server:~$ sudo nano /etc/kernel/cmdline

Éditez-le pour ressembler à :

cr0x@server:~$ sudo cat /etc/kernel/cmdline
root=ZFS=rpool/ROOT/pve-1 ro quiet intel_iommu=on iommu=pt

Appliquez-le ensuite :

cr0x@server:~$ sudo proxmox-boot-tool refresh
Running hook script 'proxmox-auto-removal'..
Running hook script 'zz-proxmox-boot'..
Refreshing ESP /boot/efi
Copying kernel and creating EFI boot entry

Ce que cela signifie : Les entrées ESP sont rafraîchies avec la nouvelle cmdline.

Décision : Si vous ne voyez pas le rafraîchissement de l’ESP, vous n’utilisez peut-être pas systemd-boot — ou votre ESP n’est pas monté correctement.

Tâche 7 (GRUB) : Définir les options dans /etc/default/grub et update-grub

cr0x@server:~$ sudo grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

Ce que cela signifie : C’est ici que vous ajoutez les flags pour les installations GRUB classiques.

Décision : Ajoutez le flag spécifique au fournisseur et généralement iommu=pt.

cr0x@server:~$ sudo sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="quiet"/GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"/' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-3-pve
Found initrd image: /boot/initrd.img-6.8.12-3-pve
done

Ce que cela signifie : Votre configuration GRUB contient maintenant les flags.

Décision : Si update-grub ne trouve pas vos images noyau Proxmox, vous n’utilisez pas GRUB ou votre /boot est atypique.

Tâche 8 : Redémarrer, puis confirmer que la cmdline contient les flags

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.

Après le redémarrage :

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

Ce que cela signifie : Le noyau en cours d’exécution a les flags.

Décision : Si les flags ne sont pas là, vous avez modifié le mauvais endroit pour votre chargeur de démarrage. Revenez aux tâches de détection du chargeur.

Valider que l’IOMMU fonctionne (et interpréter la sortie)

Vous ne « sentez » pas l’IOMMU. Vous la prouvez. Voici les vérifications en lesquelles j’ai confiance.

Tâche 9 : Vérifier dmesg pour l’activation de l’IOMMU (encore, après les changements)

cr0x@server:~$ dmesg | egrep -i 'DMAR: IOMMU enabled|AMD-Vi: IOMMU enabled|IOMMU enabled' | head
[    0.000000] DMAR: IOMMU enabled

Ce que cela signifie : Le noyau utilise l’IOMMU.

Décision : Si vous ne voyez toujours rien, le firmware n’active pas VT-d/AMD‑Vi ou la plateforme ne fournit pas correctement les tables.

Tâche 10 : Vérifier le remappage d’interruptions / avertissements DMAR

cr0x@server:~$ dmesg | egrep -i 'remapping|x2apic|DMAR:.*fault|AMD-Vi:.*Event' | head -n 50
[    0.000000] DMAR: Interrupt remapping enabled

Ce que cela signifie : Le remappage d’interruptions est activé (bon signe). Si vous voyez des fautes DMAR, cela peut indiquer un firmware buggué ou un périphérique faisant du DMA illégal.

Décision : Si vous voyez des fautes répétées, ne les ignorez pas. Elles corrèlent fortement avec des « VM qui se figent aléatoirement lors d’IO ».

Tâche 11 : Vérifier la présence de sysfs IOMMU

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups 2>/dev/null | head
0
1
2
3

Ce que cela signifie : Si /sys/kernel/iommu_groups existe et contient des répertoires numérotés, le noyau a créé des groupes IOMMU.

Décision : Si le répertoire n’existe pas, vous n’avez pas d’IOMMU active.

Tâche 12 : Énumérer les groupes et les périphériques (le sérum de vérité)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; for d in "$g"/devices/*; do echo -n "  "; lspci -nns "$(basename "$d")"; done; done | sed -n '1,60p'
Group 0
  00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]
Group 1
  00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901]
Group 7
  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1b80] (rev a1)
  01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f0] (rev a1)

Ce que cela signifie : Les périphériques du même groupe ne peuvent pas être séparés en toute sécurité pour du passthrough. Un GPU apparaît typiquement avec sa fonction audio dans le même groupe — normal et acceptable. Mais si votre GPU partage un groupe avec, par exemple, le contrôleur SATA depuis lequel vous démarrez, vous êtes mal parti.

Décision : Si le groupe de la cible contient des périphériques critiques non liés, déplacez la carte dans un autre slot, modifiez les réglages du firmware (Above 4G decoding aide parfois), ou envisagez un ACS override (en connaissance de cause).

Groupes IOMMU : à quoi ressemble du « bon »

Les groupes IOMMU font la différence entre « le passthrough est une case à cocher » et « le passthrough est un projet trimestriel ». Vous voulez une séparation propre. La perfection est rare. Vous vous contentez du sûr.

Ce que vous voulez

Votre périphérique de passthrough (GPU/HBA/NIC) est isolé dans son propre groupe, ou ne partage qu’avec ses propres fonctions (périphériques multi‑fonctions).
Les contrôleurs de la carte mère dont vous dépendez pour le boot (contrôleur SATA/NVMe contenant la racine Proxmox) ne sont pas collés au même groupe que la cible de passthrough.
Les ports racine et ponts PCIe forment une séparation logique entre les slots.

Ce que vous pouvez tolérer

GPU + fonction audio du GPU dans le même groupe.
NIC avec multiples fonctions regroupées (dépend du matériel).

Ce que vous ne devez pas tolérer

HBA groupé avec le contrôleur SATA du chipset qui héberge les disques de boot Proxmox.
GPU groupé avec le contrôleur USB dont vous avez besoin pour le clavier/console lors des pannes (demandez‑moi comment je sais ; ne demandez pas, en fait).

Blague #2 : Les groupes IOMMU sont comme les places de bureau — si Finance et Production partagent un bureau, quelque chose va bientôt être audité.

Principes de base VFIO : lier proprement les périphériques

Une fois que l’IOMMU est activée et que les groupes sont acceptables, vous devez encore empêcher l’hôte d’accrocher le périphérique avec un pilote natif. VFIO veut réclamer le périphérique en premier.

Tâche 13 : Identifier les IDs PCI du périphérique que vous allez passer

cr0x@server:~$ lspci -nn | egrep -i 'vga|nvidia|amd|ethernet|sas|sata' | head -n 20
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1b80] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f0] (rev a1)

Ce que cela signifie : Les IDs vendeur:périphérique sont entre crochets. Ici : 10de:1b80 et 10de:10f0.

Décision : En général, vous liez toutes les fonctions que vous comptez passer (GPU + audio). Ne liez pas la moitié d’un périphérique multi‑fonction à moins d’aimer dépanner.

Tâche 14 : Vérifier quel pilote possède actuellement le périphérique

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3301
        Kernel driver in use: nouveau
        Kernel modules: nouveau

Ce que cela signifie : L’hôte utilise nouveau. Pour le passthrough, vous voulez typiquement vfio-pci à la place.

Décision : Planifiez de binder sur vfio-pci et de blacklist les pilotes hôtes qui se chargent automatiquement.

Tâche 15 : Configurer les IDs VFIO

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:1b80,10de:10f0 disable_vga=1
EOF

Ce que cela signifie : Cela indique à vfio-pci de réclamer ces périphériques tôt.

Décision : Si c’est un hôte de production qui utilise aussi le GPU pour la console, reconsidérez. Le passthrough signifie que l’hôte ne doit pas dépendre de ce périphérique.

Tâche 16 : Blacklister les pilotes GPU conflictuels (exemple pour nouveau)

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
options nouveau modeset=0
EOF

Ce que cela signifie : Empêche l’hôte de lier le pilote libre NVIDIA au démarrage.

Décision : Blacklistez seulement ce qui entre en conflit. Ne lancez pas une croisade de blacklistage ; c’est comme ça qu’on supprime son propre pilote NIC et qu’on découvre la politique de « mains sur site ».

Tâche 17 : S’assurer que les modules VFIO se chargent tôt

cr0x@server:~$ sudo tee -a /etc/modules >/dev/null <<'EOF'
vfio
vfio_pci
vfio_iommu_type1
vfio_virqfd
EOF

Ce que cela signifie : Assure le chargement des modules au démarrage. Certains setups fonctionnent sans cela ; beaucoup se comportent mieux avec.

Décision : Si vous chassez un binding intermittent, charger VFIO tôt est un stabilisateur peu coûteux.

Tâche 18 : Régénérer l’initramfs et redémarrer

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

Ce que cela signifie : Votre initramfs inclut désormais les configs de modules pour le démarrage précoce.

Décision : Redémarrez pour tester un binding propre ; n’essayez pas de détacher un GPU à chaud sur un système que vous devez garder accessible.

Tâche 19 : Confirmer que le périphérique est maintenant lié à vfio-pci

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3301
        Kernel driver in use: vfio-pci
        Kernel modules: nouveau

Ce que cela signifie : « Kernel driver in use: vfio-pci » est le signe de victoire. « Kernel modules » peut toujours lister des modules potentiels ; c’est normal.

Décision : Si c’est toujours nouveau/nvidia/amdgpu, votre blacklist ou mise à jour initramfs n’a pas pris effet, ou le périphérique est utilisé comme console primaire.

Listes de contrôle / plan étape par étape

Pas à pas : corriger « Pas d’IOMMU détecté » dans le monde réel

Confirmer le mode de démarrage : UEFI ou legacy via /sys/firmware/efi. Décidez de standardiser sur l’UEFI.
Identifier le chargeur : systemd-boot vs GRUB. Éditez le bon fichier de configuration.
Activer les options firmware : VT-d (Intel) ou IOMMU/AMD‑Vi (AMD). Activez aussi SVM/VT-x pour la virtualisation CPU.
Activer Above 4G decoding : Surtout si vous faites du passthrough GPU/HBA ou plusieurs périphériques PCIe.
Ajouter les flags du noyau : intel_iommu=on iommu=pt ou amd_iommu=on iommu=pt.
Rafraîchir les entrées de démarrage : proxmox-boot-tool refresh pour systemd-boot, ou update-grub pour GRUB.
Redémarrer : Ne faites pas confiance aux états partiels.
Valider dans dmesg : « IOMMU enabled », et idéalement remappage d’interruptions.
Vérifier les groupes : Assurez-vous que votre périphérique cible est dans un groupe sûr.
Lier VFIO : Définissez les IDs vfio-pci, blacklistez les pilotes en conflit, mettez à jour l’initramfs, redémarrez.
Tester la stabilité VM : Démarrez la VM, soumettez-la à de la charge, confirmez que les resets et redémarrages fonctionnent de manière répétée.

Liste de sécurité avant de passer des contrôleurs de stockage

Confirmez que le HBA n’est pas dans le même groupe IOMMU que le contrôleur de boot.
Assurez-vous que la racine Proxmox n’est pas sur des disques attachés au contrôleur que vous passerez.
Ayez un accès hors bande (IPMI/iKVM) ou au moins un plan si le réseau tombe.
Snapshottez la configuration VM et notez les adresses PCI avant les changements.

Erreurs courantes : symptômes → cause racine → correction

C’est là que la plupart du temps est perdu : pas dans la réparation, mais à réparer en toute confiance la mauvaise chose.

1) Symptom : « Pas d’IOMMU détecté » même après avoir mis intel_iommu=on

Cause racine : Vous avez modifié GRUB, mais l’hôte démarre via systemd-boot (ou vice versa).
Correction : Confirmez avec bootctl status et proxmox-boot-tool status. Appliquez les flags dans /etc/kernel/cmdline pour systemd-boot et faites proxmox-boot-tool refresh.

2) Symptom : dmesg montre IOMMU activée, mais l’interface Proxmox se plaint encore

Cause racine : Vous regardez une information obsolète (ancien démarrage), ou l’avertissement vient d’une vérification de config VM qui attend les modules VFIO et les groupes, pas seulement l’IOMMU.
Correction : Redémarrez, puis validez avec cat /proc/cmdline et ls /sys/kernel/iommu_groups. Assurez-vous que les modules VFIO sont chargés et que l’isolation des groupes est acceptable.

3) Symptom : la VM démarre, mais le périphérique n’apparaît pas dans l’invité

Cause racine : Le pilote hôte possède encore le périphérique, ou vous n’avez lié qu’une partie d’un périphérique multi‑fonction.
Correction : Utilisez lspci -k pour confirmer vfio-pci. Liez toutes les fonctions concernées (GPU + audio). Mettez à jour l’initramfs et redémarrez.

4) Symptom : « Les groupes IOMMU ne sont pas viables » / grands groupes contenant la moitié du système

Cause racine : La topologie de la carte mère manque d’isolation ACS ; courant sur cartes grand public.
Correction : Essayez d’autres slots PCIe, activez Above 4G decoding, mettez à jour le BIOS, et seulement alors envisagez ACS override (en sachant que cela peut affaiblir l’isolation).

5) Symptom : le passthrough fonctionne une fois, puis échoue après reboot de la VM

Cause racine : Problèmes de reset du périphérique (surtout GPU), bugs firmware ou bizarreries de pilote dans l’invité.
Correction : Testez plusieurs cycles de redémarrage. Envisagez un autre GPU, appliquez des contournements de reset spécifiques au fournisseur seulement si vous pouvez valider la stabilité. Ne mettez pas en production quelque chose qui « marche au premier démarrage ».

6) Symptom : l’hôte devient injoignable après activation de VFIO/liage d’une NIC

Cause racine : Vous avez lié la NIC de gestion (ou son groupe entier) à vfio-pci, retirant le réseau de l’hôte.
Correction : Déliez en retirant les IDs vfio/blacklists, reconstruisez l’initramfs, redémarrez. Utilisez la console hors bande. Et la prochaine fois, vérifiez les groupes avant de binder.

7) Symptom : « DMAR: DRHD: handling fault status » en cascade dans les logs

Cause racine : Bugs firmware/IOMMU, ou un périphérique effectuant du DMA illégal.
Correction : Mettez à jour le BIOS, confirmez les flags noyau corrects, essayez de désactiver les économies d’énergie PCIe agressives dans le firmware. Si cela persiste, la plateforme peut être peu fiable pour le passthrough.

Trois mini-récits d’entreprise issus du terrain

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

Une équipe dont j’ai fait partie a hérité d’un cluster Proxmox qui « supportait définitivement le passthrough ». Quelqu’un l’avait fait une fois, sur un nœud différent, dans une armoire différente, lors d’une fenêtre de migration. Cela est devenu une vérité tribale. L’étape suivante fut de passer un HBA à une VM de stockage — parce que c’était le moyen le plus rapide d’importer une pile de disques.

Ils ont activé VT-d dans le BIOS, ajouté intel_iommu=on à GRUB, redémarré, et ont déclaré la tâche terminée. Puis ils ont lié le HBA à vfio-pci. L’hôte est tombé en panne : boucle de démarrage, périphérique racine manquant, le silence déprimant après la déconnexion SSH. Le personnel sur site a dû brancher un crash cart parce que l’accès hors bande n’était pas câblé. Ce fut une longue après‑midi.

La cause racine n’était pas exotique. Le HBA qu’ils « passaient » n’était pas un HBA séparé. C’était le contrôleur de stockage intégré. Il vivait dans le même groupe IOMMU que les fonctions du chipset qui hébergeaient aussi le volume de boot. Ils ont supposé « le nom du contrôleur ressemble à HBA » signifiait « sûr pour le passthrough ». Le noyau n’était pas d’accord.

La réparation fut ennuyeuse : s’arrêter, cartographier les groupes IOMMU, et installer physiquement un vrai HBA dédié dans un slot qui groupait proprement. Puis ne binder que ce périphérique. La leçon n’était pas « soyez prudent ». La leçon était ne jamais supposer l’identité à partir des noms marketing. Les adresses PCI et les groupes IOMMU sont le seul schéma de nommage fiable dans la salle.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un autre environnement voulait des performances maximales pour une charge GPU‑intensive. Quelqu’un a lu que la traduction IOMMU ajoutait de l’overhead. Il a décidé « d’optimiser » en expérimentant divers paramètres du noyau et réglages firmware jusqu’à ce que les benchs paraissent bons. La configuration a dérivé : un nœud utilisait iommu=pt, un autre non, un troisième avait des réglages PCIe différents parce que « ce nœud en avait besoin pour démarrer ».

Tout semblait bien pendant un moment. Puis des pannes rares et laides sont apparues : des VMs en passthrough GPU se bloquaient sous forte charge IO tandis que l’hôte restait majoritairement vivant. Ce n’était pas assez fréquent pour reproduire à la demande. Mais assez fréquent pour épuiser les ingénieurs. Ils ont chassé les pilotes invités, puis les versions de QEMU, puis les théories d’alimentation. J’aimerais plaisanter. Je ne plaisante pas.

Le coupable final fut l’incohérence de configuration autour de l’IOMMU et du remappage d’interruptions combinée à des versions BIOS légèrement différentes. Un seul nœud avait le remappage d’interruptions désactivé par le firmware après une mise à jour. Sous une charge spécifique, c’était celui qui craquait. L’« optimisation » n’était pas la cause directe ; c’était le manque de standardisation.

La reprise fut opérationnelle : standardiser le firmware, standardiser la ligne de commande du noyau, l’appliquer via gestion de configuration, et ajouter une vérification au démarrage qui alerte quand l’IOMMU n’est pas activée. Les performances ne sont pas tombées de façon significative. La stabilité a beaucoup augmenté. Le retour de bâton ne venait pas du tuning — mais du tuning sans discipline.

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

Une petite structure gérait quelques nœuds Proxmox supportant des services internes. Ils n’étaient pas sophistiqués. Mais ils avaient une habitude que je respectais : pour chaque nœud, ils gardaient un simple fichier de « cartographie hardware » dans leur repo ops — adresses PCI, ce qu’était chaque périphérique, et ce à quoi il avait le droit d’être affecté.

Quand ils ont décidé de passer une NIC à une VM firewall, ils n’ont pas commencé par éditer des fichiers modprobe. Ils ont commencé par vérifier la cartographie, puis valider les groupes IOMMU en live, puis planifier le changement pendant une fenêtre avec l’accès hors bande testé. Ils l’ont aussi fait par étapes : binder VFIO, redémarrer, confirmer que l’hôte reste joignable, puis ajouter le périphérique à la VM.

Le jour du changement, la NIC ciblée était groupée avec le contrôleur USB intégré. La passer rendrait la récupération console à distance plus difficile en cas de problème, parce que leur dongle KVM IP basé sur USB était sur ce contrôleur. Rien n’a cassé, parce qu’ils n’ont pas poursuivi. Ils ont déplacé la NIC dans un autre slot et les groupes se sont améliorés.

Rien d’excitant n’est arrivé. C’est le but. La pratique « ennuyeuse » — garder une carte des périphériques et traiter les changements comme des changements — a évité un incident auto‑infligé. La fiabilité est surtout l’art de ne pas être surpris par sa propre infrastructure.

Une citation d’exploitation (idée paraphrasée)

Idée paraphrasée : « L’espoir n’est pas une stratégie. » — souvent cité dans les cercles d’exploitation, associé à la gestion pragmatique de l’ingénierie (paraphrase)

FAQ

1) Ai-je besoin d’UEFI pour utiliser l’IOMMU sur Proxmox ?

Non, mais l’UEFI tend à fournir de meilleures tables firmware et moins de surprises sur le matériel moderne. Si vous pouvez choisir, choisissez UEFI et soyez cohérent entre les nœuds.

2) Quelle est la différence entre VT-x et VT-d ?

VT-x est la virtualisation CPU (exécuter des VMs efficacement). VT-d est l’IOMMU (DMA sûr et passthrough PCI). Vous avez besoin de VT-x/SVM pour les VMs ; vous avez besoin de VT-d/AMD‑Vi pour le passthrough.

3) Dois-je toujours utiliser `iommu=pt` ?

Pour la plupart des hôtes Proxmox faisant du passthrough, oui : c’est une bonne valeur par défaut. Si vous visez une isolation maximale pour tous les périphériques de l’hôte (mappages plus stricts), vous pouvez ne pas l’utiliser — attendez‑vous à un certain overhead.

4) J’ai activé l’IOMMU mais mes groupes sont énormes. L’ACS override est‑il sûr ?

L’ACS override peut améliorer le groupement en forçant le noyau à traiter les périphériques comme plus isolés que la topologie ne le suggère. Il peut aussi réduire l’isolation réelle. Utilisez‑le seulement si vous comprenez le risque et que vous ne prétendez pas que cet hôte est une plateforme multi‑tenant renforcée.

5) Pourquoi Proxmox se plaint encore après avoir changé les options du BIOS ?

Parce que les options BIOS n’ont pas d’effet si les flags du noyau n’ont pas été appliqués, ou si vous avez modifié la mauvaise configuration du chargeur de démarrage. Validez avec /proc/cmdline et dmesg, pas avec de l’espoir.

6) Puis‑je passer mon contrôleur NVMe de boot ?

Vous le pouvez, mais vous ne devriez pas si Proxmox boot depuis ce contrôleur. Si vous donnez le contrôleur à une VM, l’hôte perdra l’accès. Si vous voulez NVMe direct dans une VM, installez un second contrôleur ou utilisez un disque dédié.

7) ZFS change-t-il quelque chose pour l’IOMMU ?

Pas directement. ZFS influence les patterns de ligne de commande de boot (par ex. root=ZFS=...) et peut influencer la façon dont vous gérez les chargeurs de démarrage (systemd-boot est courant). L’IOMMU reste un comportement firmware + noyau.

8) Comment savoir si un périphérique est sûr à passer ?

Vérifiez son groupe IOMMU. Si le groupe contient seulement ce périphérique (et ses fonctions), vous êtes en bonne position. S’il partage avec des périphériques critiques de l’hôte, déplacez le slot ou repensez le plan.

9) Mon GPU est lié à vfio-pci mais la VM ne démarre pas. Et maintenant ?

Vérifiez les quirks de reset et assurez‑vous d’avoir passé toutes les fonctions (GPU + audio). Confirmez le type de machine et le firmware de la VM (OVMF/UEFI est courant pour les GPU modernes). Puis vérifiez les logs QEMU pour l’erreur réelle ; ils sont généralement explicites.

10) Le Secure Boot peut‑il causer « Pas d’IOMMU détecté » ?

Le Secure Boot affecte généralement le chargement des modules et les noyaux signés plus que la détection IOMMU elle‑même. Mais il peut compliquer le chemin de démarrage et vous faire croire que vous avez appliqué des flags alors que non. Validez avec /proc/cmdline.

Étapes suivantes (que faire une fois que ça marche)

Une fois l’IOMMU activée et vos groupes acceptables, ne vous arrêtez pas à « la VM a démarré ». Faites les vérifications opérationnelles qui évitent les incidents futurs :

Tests de redémarrage : Redémarrez la VM à plusieurs reprises. Redémarrez l’hôte une fois. Si un périphérique ne fonctionne que après un cold boot, c’est un problème de fiabilité qui attend votre prochaine fenêtre de patch.
Hygiène des logs : Surveillez dmesg pour les fautes DMAR/AMD‑Vi sous charge. Le spam de fautes n’est pas « normal ».
Contrôle des changements : Enregistrez la version du BIOS, le mode de boot, la cmdline du noyau et les IDs vfio. Standardisez‑les entre les nœuds si vous en avez plusieurs.
Limiter le scope du passthrough : Passez uniquement le minimum de périphériques nécessaires. Ne donnez pas à la VM le monde entier parce que c’était plus simple que de réfléchir.

Si vous avez tout fait ci‑dessus et que vous voyez encore « Pas d’IOMMU détecté », vous êtes dans l’un des petits cas gênants : firmware qui ment, plateforme sans vrai VT-d/AMD‑Vi, ou chemin de chargeur de démarrage que vous n’aviez pas réalisé. C’est le moment d’arrêter de changer et de prouver chaque couche à nouveau : firmware → cmdline → dmesg → groupes. Les systèmes ne répondent pas aux impressions. Ils répondent à la configuration.