Passthrough GPU et PCIe sous Proxmox VE : IOMMU, VFIO et limites

Le passthrough PCI(e) sous Proxmox VE permet de confier directement un GPU, une carte réseau ou un autre périphérique physique à une VM KVM. En échange, l’hôte et les autres VM perdent tout accès à ce périphérique : ce n’est ni du partage logiciel ni une simple accélération graphique virtuelle.

La base technique repose sur l’IOMMU, VFIO et les groupes IOMMU. Un montage fiable dépend autant du BIOS, des slots PCI(e) et des pilotes que de la configuration de la VM. Il faut aussi accepter une limite structurante : le passthrough bloque actuellement la migration à chaud.

Le passthrough change le périmètre de la VM

Avec un périphérique passé en direct, le système invité le pilote comme s’il était installé dans sa propre machine. Cela peut procurer une latence plus basse, de meilleures performances et des fonctions supplémentaires, notamment les capacités d’offloading d’un équipement. C’est le cas typique d’un GPU pour l’affichage ou le calcul, mais aussi d’une carte réseau ou d’une fonction virtuelle SR-IOV.

Cette proximité a un coût d’exploitation très concret. Le périphérique ne reste pas disponible pour l’hôte, et il ne peut pas être affecté en parallèle à une autre VM. Avant de réserver une carte graphique à une machine, il faut donc vérifier que l’hôte conserve une console et les ressources nécessaires à son administration.

Dans un environnement de laboratoire, ce choix intervient dès le matériel. La page Construire son HomeLab aide à replacer ce besoin parmi les contraintes de plateforme : le meilleur hyperviseur ne corrige ni un BIOS incomplet ni des groupes IOMMU mal découpés par la carte mère.

Le mécanisme est réservé aux VM KVM. Les conteneurs LXC ne bénéficient pas du passthrough PCI(e) tel qu’il est configuré dans Proxmox VE. Cette distinction compte : une application qui réclame un GPU ou une carte PCI(e) directe doit être placée dans une VM adaptée à cette dépendance.

IOMMU : la condition matérielle à valider d’abord

Le processeur et la carte mère doivent gérer l’IOMMU avec remappage d’interruptions. Les noms varient selon l’architecture : Intel VT-d, AMD-Vi et SMMU sur arm64. Le support réel dépend toutefois du firmware, de l’implémentation de la plateforme et de la qualité des pilotes. Les équipements serveur sont souvent mieux pris en charge, sans que le matériel récent grand public soit automatiquement exclu.

L’IOMMU constitue la base de l’isolation DMA nécessaire au passage direct. Une VM ne doit pas pouvoir utiliser librement la mémoire de l’hôte par l’intermédiaire du périphérique qui lui est confié. C’est pourquoi l’activation de l’IOMMU ne doit pas être traitée comme un réglage accessoire, surtout lorsque l’objectif comprend une frontière d’isolation sérieuse. Les compromis qui l’affaiblissent doivent être évalués avec les mêmes exigences que celles décrites dans ce guide pour sécuriser un cluster de virtualisation.

Dans le BIOS ou l’UEFI, activez explicitement le réglage IOMMU ou VT-d. Le mode Auto n’est pas systématiquement équivalent à Enabled. L’ACS, ou Access Control Services, mérite aussi d’être activé lorsqu’il est proposé : il peut améliorer le découpage des groupes IOMMU.

Sous Proxmox VE, l’IOMMU AMD est activé par défaut. Côté Intel, les noyaux 6.8 et plus récents l’activent également par défaut ; avec un noyau plus ancien, il faut ajouter intel_iommu=on à la ligne de commande du noyau. Sur arm64, aucun paramètre n’est requis : le SMMU est fourni par le firmware et ACPI.

Le mode IOMMU passthrough peut être activé avec iommu=pt dans la ligne de commande du noyau lorsque le matériel le supporte. Il permet aux DMA des VM de contourner la traduction par défaut et peut améliorer les performances. Ce réglage ne remplace ni l’IOMMU, ni le contrôle des groupes, ni une validation effective du remappage d’interruptions.

Après redémarrage, les journaux doivent confirmer que la fonction est active. Les messages exacts dépendent de la plateforme, mais les commandes suivantes donnent les vérifications attendues :

dmesg | grep 'remapping'
dmesg | grep -e DMAR -e IOMMU -e AMD-Vi

Le premier contrôle doit notamment pouvoir afficher AMD-Vi: Interrupt remapping enabled ou DMAR-IR: Enabled IRQ remapping in x2apic mode. Sans remappage d’interruptions, l’assignation peut échouer avec Failed to assign device ... Operation not permitted ou avec Interrupt Remapping hardware not found, passing devices to unprivileged domains is insecure.

Il existe un contournement avec options vfio_iommu_type1 allow_unsafe_interrupts=1 dans un fichier .conf de /etc/modprobe.d/. Son nom est explicite : cette option peut rendre le système instable. Ce n’est pas une manière saine de déclarer un matériel compatible ; c’est un dernier recours avec une conséquence assumée.

VFIO et l’appropriation du périphérique par la VM

VFIO est l’interface noyau utilisée pour réserver le périphérique à la virtualisation. Les modules nécessaires se chargent depuis un fichier tel que /etc/modules-load.d/vfio.conf, puis l’initramfs doit être reconstruit afin que la réservation intervienne suffisamment tôt au démarrage.

vfio
vfio_iommu_type1
vfio_pci
update-initramfs -u -k all
lsmod | grep vfio

Les périphériques médiés, par exemple certaines configurations vGPU, n’exigent pas ce chargement de modules VFIO. Pour un périphérique PCI(e) classique, en revanche, la présence de VFIO doit être vérifiée avant de construire la configuration de VM autour de lui.

Proxmox VE essaie de rendre automatiquement le périphérique indisponible pour l’hôte. Si ce n’est pas le cas, deux approches existent : lier les identifiants vendeur et produit au pilote vfio-pci, ou mettre le pilote hôte en liste noire. Les identifiants proviennent de lspci -nn, tandis que le pilote actif se consulte avec lspci -k.

options vfio-pci ids=1234:5678,4321:8765
blacklist NOMDUPILOTE
softdep NOMDUMODULE pre: vfio-pci
update-initramfs -u -k all

La ligne softdep sert lorsque l’ordre de chargement reste défavorable à VFIO. Après redémarrage, la commande suivante doit montrer Kernel driver in use: vfio-pci, ou l’absence de cette ligne, pour confirmer que le périphérique est prêt à être confié :

lspci -nnk

Pour les GPU, les pilotes couramment mis en liste noire sont amdgpu et radeon pour AMD, ainsi que nouveau pour NVIDIA. Il faut être prudent avec i915 : le blacklister pour une carte Intel dédiée prive aussi l’iGPU Intel de ce pilote. Une fois ce choix fait, la console graphique locale de l’hôte peut changer radicalement de comportement.

Les groupes IOMMU déterminent ce qui est réellement isolable

Un périphérique à passer doit appartenir à un groupe IOMMU séparé. Ce groupe représente l’unité d’isolation matérielle que l’hôte peut attribuer de manière sûre. Un GPU qui partage son groupe avec son contrôleur audio HDMI reste dans un cas normal : ces fonctions font partie du même équipement. Le partage avec le port racine ou le pont PCI(e) associé est également acceptable.

La vue API de Proxmox VE permet de relever la colonne iommugroup et de vérifier la topologie sans interpréter seulement la sortie brute du noyau :

pvesh get /nodes/{nodename}/hardware/pci --pci-class-blacklist ""

Un groupe contenant des périphériques sans lien direct avec le GPU ou la carte cible doit alerter. Passer seulement un membre de ce groupe revient à ignorer une frontière matérielle insuffisante. Dans ce cas, commencez par déplacer la carte dans un autre slot PCI(e). Certaines plateformes modifient ainsi le découpage des groupes.

Le correctif ACS override peut être activé avec pcie_acs_override=downstream sur la ligne de commande du noyau. Il est présent dans le noyau Proxmox VE, mais n’est pas sans risques. Il ne faut pas le confondre avec l’ACS matériel : il peut produire un découpage apparent qui ne reflète pas les garanties physiques de la plateforme.

Le passthrough fait partie des fonctions qui distinguent Proxmox VE d’un simple hébergement de VM généraliste. Il s’insère parmi les possibilités de la plateforme décrites dans cet état de l’art de Proxmox VE en 2026, mais il impose davantage de discipline que l’ajout d’un disque virtuel ou d’une interface réseau virtuelle.

Préparer une VM GPU sans multiplier les variables

Le passthrough PCI existe avec les machines i440fx et q35. Le passthrough PCIe exige q35. Choisir l’option PCIe indique au système invité qu’il reçoit un périphérique PCIe ; cela ne force pas une carte PCIe passée en mode PCI à fonctionner à une vitesse PCI.

Pour un GPU, l’association la plus compatible est généralement q35, OVMF pour l’UEFI et le mode PCIe. OVMF exige toutefois une ROM GPU compatible UEFI. Si ce n’est pas le cas, SeaBIOS peut être préférable. La compatibilité peut être testée en extrayant la ROM puis en l’analysant avec l’outil rom-parser : une image de type 3 indique une compatibilité UEFI.

L’ajout se fait depuis l’interface web, dans le matériel de la VM via Host PCI, ou directement avec qm. Pour un appareil unique :

qm set VMID -hostpci0 00:02.0

Pour passer toutes les fonctions d’un même périphérique, par exemple 00:02.0 et 00:02.1, la syntaxe courte est 00:02. L’interface propose l’équivalent avec la case All Functions. Pour un GPU principal présenté en PCIe, l’exemple suivant regroupe les options utiles :

qm set VMID -hostpci0 02:00,pcie=on,x-vga=on

Les options hostpciX à connaître sont les suivantes :

Avec OVMF, options vfio-pci ids=<vendor>,<device> disable_vga=1 peut désactiver l’arbitrage VGA. Cela réduit le code hérité exécuté au démarrage. Des surcharges de vendor-id, device-id, sub-vendor-id et sub-device-id sont aussi possibles afin de forcer le chargement d’un pilote dans l’invité.

La sortie vidéo du GPU passé ne remonte pas dans noVNC ou SPICE depuis l’interface Proxmox VE. Il faut connecter un écran à la carte, ou mettre en place un accès distant dans l’invité, par exemple VNC ou RDP. Une charge de calcul OpenCL ou CUDA n’a pas besoin d’affichage local. SPICE peut gêner un GPU passé, car il présente également une carte graphique virtuelle à l’invité ; le désactiver est une piste de diagnostic raisonnable.

Diagnostiquer les pannes fréquentes côté GPU

Les problèmes de passthrough GPU apparaissent souvent au démarrage de la VM, au chargement du pilote invité ou après un arrêt. Il faut lire conjointement le dmesg de l’hôte, les journaux de l’invité et, sous Windows, les journaux d’événements. Changer plusieurs paramètres à la fois rend le diagnostic impraticable.

Une erreur BAR 3: can't reserve [mem] peut être traitée en essayant video=efifb:off sur la ligne de commande du noyau.

L’erreur BAR0 is 0M ou le code 12 sous Windows peut survenir avec un GPU doté de beaucoup de mémoire vidéo dans une VM OVMF. Par défaut, OVMF utilise une fenêtre MMIO 64 bits de 32 Go ; elle peut être insuffisante à partir de 24 Go de VRAM. Les pistes documentées sont le type de CPU host, phys-bits=host, éventuellement avec +pdpe1gb, le réglage explicite de la fenêtre ou SeaBIOS.

-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536

Le code 43 de Windows est générique et ne désigne pas une cause unique. Il faut essayer le périphérique dans une VM Linux, tester un autre slot ou une autre machine, contrôler les journaux, essayer un autre vBIOS et désactiver Resizable BAR ou Smart Access Memory. Certains GPU AMD, à partir de Vega selon le wiki, peuvent produire ce code lorsque cette fonction est activée sur l’hôte ; elle n’est pas supportée en VM et doit être désactivée.

Les GPU NVIDIA mobiles et certaines configurations vGPU peuvent nécessiter une usurpation des identifiants vendeur et appareil afin de ressembler à une version desktop. Certains logiciels refusant de fonctionner dans une VM ne posent plus ce problème avec les pilotes NVIDIA 465 et plus récents, mais ce constat ne transforme pas le code 43 en diagnostic automatique.

Certaines cartes AMD, dont des Navi 5xxx et 6xxx citées dans le wiki, peuvent mal se réinitialiser après un cycle d’alimentation. Le correctif vendor-reset constitue une piste, avec une stabilité non garantie. Maintenir le BIOS de la carte mère à jour peut aussi améliorer les groupes IOMMU. Désactiver CSM ou le mode legacy peut aider le GPU, à condition que Proxmox VE ait été installé en UEFI.

L’audio HDMI qui craque peut nécessiter MSI. La vérification porte sur la ligne MSI: Enable+ dans lspci -vv, et l’option Linux suivante peut être utilisée :

snd-hda-intel enable_msi=1

Certaines applications Windows peuvent aussi faire tomber la VM. Pour ce cas, l’option ci-dessous limite les effets de certains accès MSR et réduit le bruit des journaux si l’option associée est utilisée :

options kvm ignore_msrs=1
report_ignored_msrs=0

SR-IOV et vGPU : partager sans confondre les modèles

Le passthrough classique réserve l’équipement entier à une VM. SR-IOV suit une autre logique : un périphérique expose plusieurs fonctions virtuelles, ou VF, qui peuvent chacune être attribuées à une VM. Les cartes réseau sont le cas courant. Plusieurs VF peuvent exister par port physique et conserver les fonctionnalités matérielles complètes, comme l’offload de checksum.

La création des VF dépend du pilote. Elle peut passer par une option telle que max_vfs=4 pour certains pilotes Intel, ou par sysfs. Le paquet Debian sysfsutils permet d’assurer la persistance de ce réglage.

echo 4 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs

Les périphériques médiés suivent encore une autre approche. Une carte physique crée alors des cartes virtuelles que l’hôte ne voit pas comme des périphériques PCI(e) ordinaires. Le pilote doit explicitement prendre en charge cette fonction. Pour Intel GVT-g, les prérequis mentionnés incluent le module kvmgt et le paramètre i915.enable_gvt=1, avec les processeurs Core de 5e, 6e et 7e génération ainsi que les Xeon E3 v4, v5 et v6.

L’attribution se fait avec la propriété mdev de hostpciX. Proxmox VE crée le périphérique au démarrage de la VM et le supprime lorsqu’elle s’arrête.

qm set VMID -hostpci0 00:02.0,mdev=i915-GVTg_V5_4

Pour le passthrough à une VM imbriquée, une IOMMU virtuelle peut être émulée dans la VM parente :

qm set VMID -machine q35,viommu=intel
qm set VMID -machine q35,viommu=virtio

HA, migration et mapping : les limites à planifier

Un périphérique PCI ou USB passé bloque actuellement la migration à chaud. Une VM équipée d’un GPU direct ne se déplace donc pas en continu vers un autre nœud comme une VM sans dépendance locale. La migration hors ligne reste possible si tous les disques sont présents sur des stockages définis sur les deux hôtes, mais la configuration de passthrough devra parfois être adaptée à l’emplacement du matériel sur la cible.

En haute disponibilité, une ressource ne peut tourner que sur les nœuds disposant de toutes ses dépendances, y compris le passthrough matériel. Une règle stricte d’affinité de nœud doit donc limiter la VM aux hôtes capables de l’accueillir. Avec une politique d’arrêt Migrate, un service lié localement ne peut pas migrer et l’arrêt du nœud reste bloqué jusqu’à une intervention manuelle. Ces comportements doivent être intégrés à la stratégie de reprise présentée dans l’article sur le quorum, le QDevice et la haute disponibilité.

Les Resource Mappings de niveau Datacenter répondent au problème des identifiants PCI différents selon les nœuds. Un identifiant logique choisi par l’administrateur référence un périphérique local distinct sur chaque hôte. La HA évite ainsi de démarrer une VM avec un mauvais équipement et détecte les changements matériels.

pvesh create /cluster/mapping/pci --id device1 --map node=node1,path=0000:01:00.0,id=0002:0001 --map node=node2,path=0000:02:00.0,id=0002:0001
qm set ID -hostpci0 <nom>

Un mapping peut contenir plusieurs périphériques par nœud : le premier libre est retenu. Cette possibilité est particulièrement utile pour les VF SR-IOV. Les utilisateurs non-root peuvent également configurer ces mappings. Cela ne rend pas la migration à chaud possible, mais évite de traiter le matériel local comme un détail invisible de la configuration.

Sources consultées

• Documentation Proxmox VE, chapitre Qemu/KVM Virtual Machines, consultée le 5 octobre 2026.
• Wiki Proxmox VE, PCI Passthrough, consulté le 5 octobre 2026.