Guide technique13 février 202618 min de lecture

    Proxmox GPU, USB et PCI Passthrough : le guide complet IOMMU / VFIO

    Attribuer un GPU NVIDIA ou AMD, un contrôleur USB, une carte réseau ou n'importe quel périphérique PCI directement à une VM Proxmox — avec des performances quasi bare-metal. Ce guide couvre la configuration IOMMU, VFIO, les pièges courants et les cas d'usage réels.

    Le hardware passthrough : donner un accès direct au matériel

    Par défaut, Proxmox virtualise le matériel : chaque VM reçoit des périphériques émulés (carte réseau virtio, GPU virtuel, contrôleur SCSI virtuel). C'est suffisant pour la plupart des workloads — mais pas pour tous.

    Le hardware passthrough (ou PCI passthrough) permet d'attribuer un périphérique physique directement à une VM, en contournant l'émulation. La VM voit le matériel comme si elle tournait en bare-metal, avec les drivers natifs et les performances natives.

    Les cas d'usage sont nombreux : GPU passthrough pour le gaming, le calcul IA/ML ou le VDI, USB passthrough pour les dongles domotique (Zigbee, Z-Wave) ou les clés de licence, PCI passthrough pour les cartes réseau hautes performances, les contrôleurs RAID ou les cartes d'acquisition.

    Émulation vs Passthrough

    Émulation (par défaut)

    VM → Driver virtuel → QEMU → Host → Matériel
    Overhead d'émulation (CPU host sollicité)
    Matériel partageable entre VM
    Live migration possible

    Passthrough (VFIO)

    VM → Driver natif → Matériel (direct)
    Performance quasi bare-metal
    Matériel dédié à une seule VM
    Live migration impossible (device attaché)

    Le passthrough utilise IOMMU (Intel VT-d / AMD-Vi) pour mapper la mémoire DMA du périphérique directement dans l'espace mémoire de la VM, sans passer par le host.

    Prérequis matériels et BIOS

    Le passthrough ne fonctionne pas sur n'importe quel matériel. Voici ce qu'il faut vérifier avant de commencer :

    Checklist prérequis

    • CPU avec IOMMU : Intel VT-d (la plupart des Core depuis la 4ème gen, tous les Xeon) ou AMD-Vi (tous les Ryzen, EPYC)
    • IOMMU activé dans le BIOS : souvent sous "VT-d" (Intel) ou "IOMMU" / "SVM" (AMD) dans les paramètres avancés du BIOS
    • Groupes IOMMU isolés : chaque slot PCIe doit idéalement être dans son propre groupe IOMMU — les cartes mères serveur (Supermicro, Dell, HPE) le font bien, certaines cartes grand public regroupent tout
    • GPU secondaire pour le passthrough : le host Proxmox a besoin d'un affichage (même minimal) — ne passez pas le GPU principal utilisé pour la console
    • BIOS UEFI (OVMF) pour la VM : le GPU passthrough fonctionne nettement mieux avec UEFI qu'avec SeaBIOS, surtout pour Windows

    Attention aux groupes IOMMU

    Le passthrough PCI fonctionne par groupe IOMMU : tous les périphériques d'un même groupe doivent être passés ensemble à la même VM (ou tous rester sur le host). Sur certaines cartes mères grand public, tous les slots PCIe partagent le même groupe — rendant le passthrough sélectif impossible. Vérifiez vos groupes avec find /sys/kernel/iommu_groups/ -type l avant de vous lancer. Le patch ACS override peut aider, mais il réduit la sécurité IOMMU.

    Configuration IOMMU étape par étape

    La première étape, commune à tout type de passthrough (GPU, USB, PCI), est d'activer IOMMU au niveau du kernel Linux de l'hôte Proxmox.

    Étape 1 : Paramètres du bootloader

    Le paramètre iommu=pt (passthrough mode) indique au kernel de ne pas traduire les adresses DMA pour les périphériques du host — ce qui améliore les performances réseau et disque de l'hôte tout en activant IOMMU pour les VM.

    Étape 2 : Charger les modules VFIO

    Le principe : on blackliste les drivers GPU du host pour que le GPU ne soit pas initialisé au boot, puis on le réserve via VFIO pour qu'il soit disponible exclusivement pour le passthrough aux VM.

    Étape 3 : Vérifier l'IOMMU

    # Vérifier que IOMMU est actif
    dmesg | grep -e DMAR -e IOMMU
    # Doit afficher : "DMAR: IOMMU enabled" ou "AMD-Vi: IOMMU enabled"
    
    # Lister les groupes IOMMU et leurs périphériques
    find /sys/kernel/iommu_groups/ -type l | sort -V
    
    # Script pratique pour visualiser les groupes :
    for g in $(find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V); do
      echo "IOMMU Group $(basename $g):"
      for d in $g/devices/*; do
        echo -e "\t$(lspci -nns $(basename $d))"
      done
    done

    GPU Passthrough : NVIDIA et AMD

    Le GPU passthrough est le cas d'usage le plus recherché. Il permet d'obtenir des performances graphiques natives dans une VM — gaming, rendu 3D, transcodage vidéo, calcul IA/ML (CUDA, ROCm).

    Gaming / VDI

    • VM Windows avec GPU dédié
    • Performance DirectX / Vulkan native
    • Looking Glass pour le display
    • Idéal pour homelab gaming

    IA / ML / Compute

    • CUDA / cuDNN / TensorRT (NVIDIA)
    • ROCm (AMD)
    • Training et inférence en VM
    • Isolation des workloads GPU

    Transcodage vidéo

    • NVENC / NVDEC (NVIDIA)
    • VCE / VCN (AMD)
    • Plex, Jellyfin hardware transcode
    • Streaming et montage vidéo

    VDI / Postes virtuels

    • Bureaux virtuels accélérés
    • CAO/DAO (SolidWorks, AutoCAD)
    • vGPU avec NVIDIA A-series/L-series
    • Multi-utilisateur avec SR-IOV

    Configuration de la VM pour GPU passthrough

    # Créer une VM avec UEFI (OVMF) — obligatoire pour le GPU passthrough
    qm create 100 --name gpu-vm --memory 16384 --cores 8 \
      --bios ovmf --efidisk0 local-lvm:1,format=raw,efitype=4m,pre-enrolled-keys=1 \
      --machine q35 --cpu host,hidden=1 \
      --net0 virtio,bridge=vmbr0
    
    # Attacher le GPU (remplacer 01:00 par l'adresse PCI réelle)
    qm set 100 --hostpci0 01:00,pcie=1,rombar=1,x-vga=1
    
    # Pour NVIDIA (éviter l'erreur code 43) :
    qm set 100 --args '-cpu host,kvm=off'
    
    # Attacher le GPU + audio du même groupe IOMMU :
    # qm set 100 --hostpci0 01:00,pcie=1,rombar=1,x-vga=1

    Paramètres clés expliqués

    ParamètreRôle
    machine: q35Chipset moderne avec support PCIe natif (vs i440fx qui émule PCI)
    cpu: host,hidden=1Expose le CPU réel à la VM et masque la virtualisation (nécessaire pour NVIDIA)
    bios: ovmfUEFI firmware — requis pour le GOP (Graphics Output Protocol) des GPU modernes
    pcie=1Expose le device en mode PCIe (vs PCI legacy), nécessaire pour les GPU récents
    rombar=1Charge la ROM optionnelle du GPU (firmware VBIOS) — requis pour l'initialisation
    x-vga=1Marque ce GPU comme affichage principal de la VM

    NVIDIA

    • Fonctionne très bien une fois configuré
    • Nécessite hidden=1 / kvm=off (anti-détection VM)
    • CUDA, NVENC, cuDNN — écosystème IA/ML dominant
    • vGPU possible (série A/L avec licence)

    AMD

    • Plus simple à configurer (pas de détection VM)
    • Reset bug corrigé sur les GPU récents (RDNA2+)
    • ROCm pour le compute (support croissant)
    • Ancien « reset bug » sur Polaris/Vega (contournable avec vendor-reset)

    USB Passthrough

    Le USB passthrough est plus simple que le GPU passthrough et supporte le hot-plug — on peut attacher et détacher des périphériques USB à une VM en cours d'exécution.

    Deux méthodes de USB passthrough

    Par périphérique (USB ID)

    Passe un périphérique USB spécifique, identifié par son vendor:product ID. Le périphérique peut être sur n'importe quel port USB.

    # Trouver l'ID USB lsusb # Bus 001 Device 005: ID 1a86:7523 ... # Attacher à la VM qm set 100 --usb0 host=1a86:7523

    Par contrôleur USB (PCI)

    Passe un contrôleur USB entier (avec tous ses ports) via PCI passthrough. Tous les ports de ce contrôleur sont alors dans la VM.

    # Trouver le contrôleur USB lspci | grep USB # 00:14.0 USB controller: Intel ... # Passer le contrôleur entier qm set 100 --hostpci1 00:14.0

    Cas d'usage courants : dongles Zigbee/Z-Wave (Home Assistant, Jeedom), clés de licence USB (HASP, CodeMeter), lecteurs de cartes, imprimantes, scanners, récepteurs GPS/GNSS, adaptateurs série RS-232/RS-485 pour l'industriel.

    PCI Passthrough générique

    Au-delà du GPU et de l'USB, tout périphérique PCI/PCIe peut être passé à une VM. Les cas d'usage les plus courants :

    PériphériqueUsageDifficulté
    Carte réseau (NIC)Réseau 10/25/100 GbE dédié, DPDK, pfSense/OPNsenseFacile
    Contrôleur HBA / RAIDAccès direct aux disques (TrueNAS, ZFS en VM)Facile
    GPU (détaillé ci-dessus)Gaming, IA/ML, transcodage, VDIModéré
    Carte d'acquisition vidéoCapture HDMI/SDI, streaming, vidéosurveillanceFacile
    Carte son / audio proProduction audio, faible latenceFacile
    Carte série / industrielleSCADA, automates, contrôle industrielFacile
    Intel QSV (iGPU)Transcodage hardware avec l'iGPU Intel (GVT-g)Avancé

    vGPU et SR-IOV : partager un GPU entre VM

    Le passthrough classique attribue un GPU entier à une seule VM. Pour partager un GPU entre plusieurs VM, deux technologies existent :

    NVIDIA vGPU (mediated passthrough)

    • GPU partagé entre N VM (profils configurables)
    • Séries A (datacenter), L (inférence)
    • Licence NVIDIA vGPU requise (coûteuse)
    • Drivers vGPU spécifiques (pas les drivers gaming)

    SR-IOV (Intel / AMD)

    • Partage matériel natif (Virtual Functions)
    • Intel Flex (Arctic Sound), cartes réseau SR-IOV
    • Pas de licence supplémentaire pour Intel
    • Support matériel limité (GPU spécifiques)

    En pratique : le vGPU et le SR-IOV sont surtout pertinents pour les environnements VDI multi-utilisateurs et les clusters de calcul partagé. Pour un homelab ou une infra PME avec 1-2 GPU, le passthrough classique (1 GPU = 1 VM) est plus simple et plus performant.

    Troubleshooting : problèmes courants

    NVIDIA Code 43 (Windows)

    Le driver NVIDIA détecte la VM et refuse de fonctionner. Solution : ajouter cpu: host,hidden=1 dans la config VM et utiliser le chipset q35 avec OVMF (UEFI). Depuis les drivers 5xx+ (2024), NVIDIA a supprimé cette restriction sur les GPU GeForce.

    AMD Reset Bug

    Sur les GPU AMD Polaris et Vega, le GPU ne se réinitialise pas correctement après un reboot de la VM — il faut rebooter le host entier. Solution : utiliser le module vendor-reset ou passer à un GPU RDNA2+ (RX 6000/7000/9000) qui n'a pas ce problème.

    Écran noir après passthrough GPU

    Le GPU ne s'initialise pas dans la VM. Vérifiez : BIOS OVMF (pas SeaBIOS), rombar=1 activé, x-vga=1 pour le display. Si le GPU est le seul dans le système, le host doit utiliser un autre affichage (iGPU, console série, ou headless).

    Groupe IOMMU partagé

    Le GPU partage son groupe IOMMU avec d'autres périphériques (bridge PCI, audio, etc.). Solutions : passer tous les périphériques du groupe ensemble, changer de slot PCIe, ou activer le patch ACS override (pcie_acs_override=downstream,multifunction) — avec la réserve que cela réduit l'isolation IOMMU.

    BAR memory trop grande (error: not enough IO)

    Les GPU modernes (RTX 3090/4090, RX 7900 XT) ont des BAR très grandes (> 256 Mo). Solution : activer Resizable BAR (ReBAR) dans le BIOS du host et ajouter x-pci-vendor-id ou laisser le chipset q35 gérer les addresses 64-bit.

    Limitations et compromis

    AspectÉmulation (virtio)Passthrough (VFIO)
    Performance70-95% du natif~99% du natif
    Live migrationOuiNon (device physique attaché)
    Partage entre VMOuiNon (1 device = 1 VM)
    Snapshot/backupNormalVM doit être éteinte
    ComplexitéAucuneIOMMU, VFIO, groupes, drivers
    PortabilitéVM déplaçable librementLiée au matériel physique

    Le compromis fondamental

    Le passthrough offre des performances maximales mais réduit la flexibilité : pas de live migration, pas de snapshot à chaud, VM liée au matériel physique. Utilisez-le uniquement quand l'émulation ne suffit pas (GPU compute, gaming, périphériques spécialisés). Pour le réseau et le stockage standard, les drivers virtio offrent d'excellentes performances sans ces contraintes.

    Notre approche chez RDEM Systems

    Chez RDEM Systems, nous utilisons le passthrough de manière ciblée :

    Passthrough dans notre infrastructure

    Cartes réseau dédiées

    Passthrough de NIC 10 GbE pour les VM qui nécessitent des performances réseau maximales ou un accès direct au réseau physique (firewalls, routeurs virtuels).

    Contrôleurs HBA pour le stockage

    Passthrough de contrôleurs SAS/SATA en mode HBA pour les VM de stockage (TrueNAS, ZFS) — accès direct aux disques sans l'overhead de la virtualisation du stockage.

    Approche sélective

    Nous privilégions les drivers virtio par défaut (réseau, stockage) pour conserver la live migration et la flexibilité. Le passthrough n'est utilisé que quand la performance émulée ne suffit pas — ce qui est rare avec les virtio modernes.

    Pour un deploiement cle en main, decouvrez nos offres de serveur dedie Proxmox avec passthrough GPU : nous configurons IOMMU, VFIO et les drivers pour vos workloads specialises.

    Bonnes pratiques

    Checklist passthrough Proxmox

    • Vérifier les groupes IOMMU avant d'acheter du matériel — une carte mère avec des groupes mal isolés rend le passthrough sélectif impossible
    • Toujours utiliser OVMF (UEFI) pour le GPU passthrough — SeaBIOS ne supporte pas le GOP des GPU modernes
    • Chipset q35 pour les VM avec passthrough PCI — le chipset i440fx émule du PCI legacy et cause des problèmes avec les GPU PCIe
    • Blacklister les drivers GPU sur le host (nouveau, nvidia, amdgpu) pour éviter que le host n'initialise le GPU avant VFIO
    • Garder un accès au host : IPMI/iDRAC/iLO, ou un second GPU/iGPU pour la console Proxmox — si le GPU passé à la VM est le seul, vous perdez l'affichage host
    • Planifier les backups avec VM éteinte pour les VM avec passthrough — les snapshots à chaud ne capturent pas l'état du device physique
    • Tester le reboot de la VM avant de mettre en production — certains GPU (AMD Polaris/Vega) ne se réinitialisent pas correctement

    Questions fréquentes

    Documentation officielle

    Pour approfondir les concepts abordés dans cet article :

    Articles connexes

    Besoin de GPU passthrough ou d'infra Proxmox sur mesure ?

    Nous déployons des clusters Proxmox avec passthrough GPU, USB et PCI pour vos workloads spécialisés — IA/ML, VDI, transcodage. Configuration IOMMU, VFIO et optimisation incluses.