Passthrough PCIe sur Proxmox vs ESXi : GPU, HBA, NIC — ce qui est le plus simple et le plus rapide

Résumé percutant : quoi choisir

Si vous voulez « le plus prévisible pour un homelab moyen et beaucoup de PME »

Proxmox est généralement plus facile à comprendre parce que tout est Linux de bout en bout. Vous voyez chaque réglage : groupes IOMMU, liaison de pilote, routage des interruptions, particularités de reset. Quand ça échoue, ça échoue bruyamment — et vous pouvez inspecter l’hôte comme une machine Linux normale.

Si vous faites du passthrough d’un HBA pour ZFS, Proxmox est particulièrement confortable : ZFS sur l’hôte plus passthrough en VM est un débat religieux, mais Proxmox vous propose les deux approches avec moins de moments « boîte noire ».

Si vous voulez « garde‑fous d’entreprise et cycle de vie prévisible »

ESXi est l’histoire d’entreprise la plus propre : listes de compatibilité des périphériques, plan de gestion stable et modèles opérationnels qui montent en échelle avec les équipes. Pour le passthrough spécifiquement, ESXi est excellent lorsque votre matériel est sur le chemin heureux et que vos besoins correspondent aux attentes de VMware.

Quand vous déviez du chemin heureux — GPU grand public, comportement de reset atypique, NICs de niche — ESXi se transforme en videur poli : il ne se battra pas, il vous empêchera simplement d’entrer.

GPU

• Facilité : Proxmox gagne généralement pour le passthrough GPU DIY. ESXi est bon si vous êtes dans des GPU supportés / modes supportés (et la licence si vous faites du vGPU).
• Vitesse : quasi‑native sur les deux quand c’est configuré correctement. Votre goulot est plus probablement la planification CPU, la topologie PCIe ou la gestion pilote/alimentation que l’hyperviseur.

HBA (contrôleurs SAS/SATA)

• Facilité : Proxmox gagne si votre objectif est « donner à la VM l’intégralité de l’HBA et la laisser exécuter ZFS/TrueNAS ». ESXi convient, mais vous passerez plus de temps dans la compatibilité et le « est‑ce permis ».
• Vitesse : le passthrough est effectivement natif, mais la vraie histoire de performance est la profondeur des files, la modulation des interruptions et le comportement firmware/pilote.

NIC (10/25/40/100G, SR‑IOV, charges style DPDK)

• Facilité : ex aequo, selon l’objectif. ESXi a des workflows SR‑IOV matures ; Proxmox a des outils Linux et moins de contraintes produit.
• Vitesse : SR‑IOV ou passthrough complet peuvent être excellents sur les deux. Pour le réseau VM général, souvent les NICs paravirtualisés (vmxnet3/virtio‑net) sont « suffisamment rapides » et plus indulgents opérationnellement.

Vérité sèchement drôle : le passthrough vous donne des performances natives plus des problèmes natifs.

Faits intéressants et court historique (utile, pas pour le quiz)

1. Intel VT‑d et AMD‑Vi (IOMMU) rendent possible une isolation DMA sérieuse. Avant cela, le « passthrough » était une roulette russe côté sécurité et stabilité.
2. VFIO (Virtual Function I/O) est devenu l’approche Linux dominante parce qu’il sépare proprement l’accès au périphérique de l’espace utilisateur (QEMU) et s’appuie sur l’IOMMU pour la sécurité.
3. Le remappage des interruptions est important pour la correction et la sécurité. Sans lui, certaines plateformes ne peuvent pas virtualiser MSI/MSI‑X à grande échelle en toute sécurité.
4. SR‑IOV (Single Root I/O Virtualization) a été créé pour éviter l’assignation complète en découpant une NIC en « fonctions virtuelles » avec isolation appliquée par le matériel.
5. Les bugs de reset GPU ne sont pas des légendes. Certains GPU n’implémentent pas correctement un reset par fonction (FLR), d’où les incidents de type « ça marche après cycle d’alimentation ».
6. ACS (Access Control Services) impacte les groupes IOMMU. Les cartes mères grand public regroupent souvent plusieurs slots, vous forçant à passer plus de périphériques que désiré — ou à utiliser un override ACS avec ses compromis.
7. NVMe a été conçu pour des files profondes et une faible latence. La virtualiser mal ressemble à « ça marche » jusqu’à ce que vous mettiez une base de données dessus et observiez des p99 étranges.
8. VMware DirectPath I/O existe depuis des années et est mature, mais il est volontairement conservateur : il privilégie la supportabilité et le comportement prévisible plutôt que le « laissez‑moi bricoler ».
9. vMotion et passthrough ont toujours eu une relation délicate. Vous ne pouvez pas migrer à chaud une VM qui possède un périphérique physique, sauf si vous utilisez des techniques spécifiques de partage/médiation.

Comment le passthrough fonctionne vraiment (et où ça casse)

Les périphériques PCIe font deux choses qui importent ici : ils exposent un espace de configuration (registres, capacités) et ils effectuent des DMA dans la mémoire système. Le passthrough signifie que l’OS invité accède directement au périphérique, et que l’hyperviseur se tient essentiellement à l’écart — sauf qu’il doit quand même protéger l’hôte.

Les trois piliers : IOMMU, isolation et resets

• L’IOMMU mappe le DMA du périphérique vers la mémoire invitée. Sans cela, un périphérique assigné à une VM pourrait DMA dans le noyau hôte et altérer la réalité.
• L’isolation dépend des groupes IOMMU. Si deux périphériques partagent le même groupe, vous ne pouvez souvent pas en affecter un seul en toute sécurité (car ils peuvent potentiellement DMA l’un vers l’autre ou partager des bizarreries de traduction en amont).
• Le comportement de reset compte. Quand une VM redémarre, le périphérique doit revenir dans un état propre. Si le périphérique ne peut pas se réinitialiser (ou si la plateforme ne le réinitialise pas), vous obtenez des problèmes « ça marche une fois ».

Chemin Proxmox : VFIO + QEMU + pilotes Linux

Sur Proxmox, vous :

1. Activez l’IOMMU dans le firmware et la ligne de commande du noyau.
2. Liez le périphérique PCIe cible à vfio-pci (et non à son pilote hôte habituel).
3. Ajoutez des lignes hostpci à la config de la VM, en contrôlant éventuellement la ROM BAR, les MSI et autres particularités.
4. Laissez le pilote invité prendre en charge le périphérique.

Avantage : vous pouvez tout voir et modifier. Inconvénient : vous pouvez tout voir et modifier. Vous êtes désormais l’équipe d’intégration.

Chemin ESXi : DirectPath I/O sous les règles vSphere

Sur ESXi, vous :

1. Activez l’IOMMU dans le firmware.
2. Marquez le périphérique pour le passthrough dans la configuration de l’hôte.
3. Redémarrez l’hôte (souvent nécessaire pour relier le périphérique).
4. Ajoutez le périphérique à une VM, en acceptant des contraintes comme l’absence de vMotion.

ESXi est moins « bidouillable » mais plus « encadré ». Lorsqu’il refuse une configuration, c’est généralement parce qu’il ne peut pas garantir la supportabilité ou la sécurité sur cette plateforme.

Où ça casse dans la vraie vie

• Mauvais regroupement IOMMU (commun sur les cartes mères grand public) : vous ne pouvez pas isoler un GPU de sa fonction audio ou d’un contrôleur USB derrière le même pont upstream.
• Échecs de reset : le périphérique ne revient pas après l’arrêt d’une VM ; l’hôte le voit mais le pilote invité timeoute ; seul un reboot hôte règle le problème.
• Tempêtes d’interruptions ou pics de latence : vous avez passé un périphérique à fort IOPS et maintenant le CPU 0 pleure parce que les interruptions sont mal réparties.
• Incompatibilité firmware/driver : le BIOS de l’hôte est ancien ; le firmware de l’HBA est ancien ; le pilote invité attend autre chose ; vous avez maintenant une histoire fantôme de stockage.

Une citation, parce que ça colle à la vie ops : L’espoir n’est pas une stratégie. — James R. Schlesinger

Blague #1 : Si votre GPU ne se réinitialise qu’après un reboot de l’hôte, félicitations — vous avez inventé la « haute disponibilité par patience ».

Qu’est‑ce qui est plus simple : Proxmox vs ESXi selon le type de périphérique

Passthrough GPU

Proxmox est plus simple lorsque vous êtes en dehors des GPU d’entreprise. Vous pouvez passer presque n’importe quel GPU PCIe si vous pouvez l’isoler, le binder à VFIO et gérer les particularités de reset. La culture communautaire existe parce que les problèmes sont fréquents et reproductibles.

ESXi est plus simple lorsque votre GPU est supporté et que votre workflow correspond aux attentes de VMware. Si vous avez besoin de vGPU (GPU partagées dans le temps, plusieurs VMs sur un GPU), l’écosystème ESXi est historiquement plus mature, mais c’est aussi là que la licence et l’activation par le fournisseur deviennent importants.

Réalité pratique : la partie la plus difficile n’est rarement pas « cliquer passthrough ». C’est obtenir un comportement stable à travers redémarrages, mises à jour de pilotes et événements d’alimentation. Proxmox vous donne plus de leviers. ESXi vous en donne moins, mais plus sûrs.

Passthrough HBA (SAS HBAs, cartes RAID en mode IT)

Si vous faites de l’ingénierie stockage, vous connaissez déjà la règle : le firmware RAID ment. Si vous voulez ZFS ou une pile stockage qui attend une visibilité directe des disques, vous voulez un HBA en mode IT (ou un vrai HBA) et la VM qui le possède.

Proxmox rend cela naturel : binder l’HBA à VFIO, le passer à la VM, laisser TrueNAS/OmniOS/Linux voir les disques, gérer SMART et faire votre travail. Vous pouvez garder les périphériques de gestion et de boot sur l’hôte.

ESXi convient aussi, mais vous passerez plus de temps à garantir que le contrôleur et le firmware sont une combinaison supportée et que l’hôte n’essaie pas de faire des choses intelligentes. Dans les grandes organisations, c’est une fonctionnalité : moins de machines bizarres.

Passthrough NIC : périphérique complet vs SR‑IOV vs paravirtual

Pour la plupart des charges, vous n’avez pas besoin du passthrough complet de la NIC. virtio‑net (Proxmox) et vmxnet3 (ESXi) sont excellents. Ils préservent aussi les fonctionnalités de migration et rendent la vie opérationnelle plus calme.

Quand vous en avez besoin — NFV, latence ultra‑faible, forts débits paquet, ou une VM routeur/pare‑feu à 25/100G — vous décidez entre :

• Passthrough complet : conceptuellement le plus simple, mais tue la mobilité et peut compliquer le réseau hôte.
• VFs SR‑IOV : meilleur compromis pour beaucoup de designs ; vous gardez du contrôle hôte et pouvez mapper plusieurs VMs sur un port physique.
• Stacks DPDK/espace utilisateur : souvent associées au passthrough ou SR‑IOV ; performance excellente, mais vous héritez d’un problème d’ajustement.

Le gagnant en facilité dépend de votre équipe : les équipes centrées Linux trouvent SR‑IOV et le tuning IRQ sur Proxmox simples ; les équipes VMware trouvent les workflows ESXi plus faciles à industrialiser.

Qu’est‑ce qui est plus rapide : réalité des performances selon la charge

Performance GPU : généralement quasi‑native, jusqu’à ce que ce ne soit plus le cas

Quand un GPU est passé correctement, vous êtes proche du bare‑metal pour le débit brut. Les pertes de performance viennent généralement de :

• Planification CPU : vos vCPU ne sont pas pinés, l’hôte est surbooké, ou les threads sensibles à la latence sautent entre cœurs.
• Mauvaises correspondances NUMA : GPU sur une socket, mémoire VM sur une autre. Les pénalités de bande passante et latence peuvent être marquées.
• Gestion d’alimentation : ASPM agressif ou états C qui rendent la latence en piques (dépend de la plateforme).

Proxmox vous donne un accès direct aux outils Linux pour le pinning NUMA et les hugepages ; ESXi a des contrôles de planification CPU/mémoire matures aussi, mais la cause racine du « pourquoi c’est plus lent » est parfois moins transparente.

Passthrough HBA : l’hyperviseur est rarement le goulot

Pour les HBA, le passthrough revient à « brancher le périphérique à la VM ». Les problèmes de performance se rattachent presque toujours à :

• Mauvais mode firmware (IR/RAID au lieu d’IT/HBA).
• Inadéquation profondeur de file et modulation d’interruptions.
• Comportement des disques (disques SMR, gestion d’alimentation, timers de récupération d’erreur).

Les deux hyperviseurs peuvent fournir du quasi‑natifs. La différence est opérationnelle : Proxmox facilite la corrélation des logs hôte, erreurs PCIe et messages noyau. ESXi garde l’environnement consistant mais peut cacher des détails bas niveau derrière ses abstractions.

Performance NIC : le paravirtualisé est sous‑estimé

À 10G, virtio‑net et vmxnet3 sont généralement excellents. À 25/100G, vous commencez à vous soucier de :

• Offloads (TSO/GSO/GRO/LRO) et si votre charge en profite.
• Distribution des IRQ et queues RSS.
• Surcharge du vSwitch versus files matérielles directes.

Le passthrough complet et SR‑IOV peuvent réduire la surcharge, mais ils réduisent aussi votre capacité à migrer à chaud et à appliquer des politiques centralisées. Si votre but est « rapide », le passthrough peut gagner. Si votre but est « rapide et gérable », le paravirtualisé l’emporte souvent.

Blague #2 : Le NIC le plus rapide est celui que vous ne dépannez pas à 3 h du matin.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici ce que j’exécute réellement quand une construction de passthrough sent mauvais. Chaque tâche inclut : une commande, une sortie réaliste, ce que cela signifie, et la décision à prendre.

1) Confirmer que l’IOMMU est activé (hôte Proxmox/Linux)

cr0x@server:~$ dmesg | grep -E "DMAR|IOMMU|AMD-Vi" | head
[    0.812345] DMAR: IOMMU enabled
[    0.812901] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.813210] DMAR: Interrupt remapping enabled

Signification : L’IOMMU et le remappage des interruptions sont actifs. C’est la base pour un passthrough sûr.

Décision : Si vous ne voyez pas ça, arrêtez‑vous. Corrigez les paramètres BIOS (VT‑d/AMD‑Vi) et la cmdline du noyau avant de toucher aux configs VM.

2) Vérifier que la cmdline du noyau inclut les flags IOMMU (Proxmox)

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

Signification : intel_iommu=on active VT‑d ; iommu=pt utilise le mode passthrough pour réduire la surcharge sur les périphériques hôtes.

Décision : Si absent, mettez à jour GRUB et redémarrez. Ne « tentez quand même » pas. Vous perdrez des heures.

3) Repérer le périphérique à passer (ID PCI)

cr0x@server:~$ lspci -nn | egrep -i "vga|3d|ethernet|sas|raid|nvme"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)
05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 02)

Signification : Vous avez trois candidats classiques au passthrough : GPU (et sa fonction audio), un HBA, et une NIC 10GbE.

Décision : Notez les adresses BDF (01:00.0, 03:00.0, 05:00.0). Vous les utiliserez dans la config VM ou les étapes de binding.

4) Vérifier les groupes IOMMU (pouvez‑vous isoler le périphérique ?)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename $g):"; ls -1 $g/devices/; done | sed -n '1,20p'
Group 0:
0000:00:00.0
Group 1:
0000:00:01.0
0000:01:00.0
0000:01:00.1
Group 2:
0000:00:03.0
0000:03:00.0
Group 3:
0000:05:00.0

Signification : Les fonctions GPU 01:00.0 et 01:00.1 sont ensemble (bon), l’HBA est isolé, la NIC est isolée. C’est ce que vous voulez.

Décision : Si votre GPU partage un groupe avec des périphériques aléatoires, déplacez les slots, changez les réglages BIOS « PCIe ACS », ou acceptez un override ACS (avec compromis sécurité/isolation).

5) Confirmer quel pilote possède actuellement le périphérique (avant le binding VFIO)

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI Device 0087
	Kernel driver in use: mpt3sas
	Kernel modules: mpt3sas

Signification : L’hôte utilise actuellement le pilote HBA. Si vous le passez à la VM, l’hôte doit lâcher prise.

Décision : Si l’hôte utilise ce périphérique pour son propre stockage, ne procédez pas. Démarrez l’hôte depuis autre chose d’abord (SATADOM mirrorré, NVMe séparé, etc.).

6) Binder un périphérique à vfio-pci (Proxmox/Linux)

cr0x@server:~$ echo "options vfio-pci ids=1000:0087,10de:2204,10de:1aef" | sudo tee /etc/modprobe.d/vfio.conf
options vfio-pci ids=1000:0087,10de:2204,10de:1aef

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

Signification : Vous avez indiqué à l’hôte de binder ces IDs PCI à VFIO au démarrage.

Décision : Redémarrez l’hôte pendant une fenêtre de maintenance. Le hot‑rebinding est possible, mais en production on préfère la répétabilité ennuyeuse.

7) Vérifier que vfio-pci est maintenant utilisé

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI Device 0087
	Kernel driver in use: vfio-pci
	Kernel modules: mpt3sas

Signification : Le pilote hôte est détaché ; VFIO possède le périphérique. C’est l’état que vous voulez pour le passthrough.

Décision : Si c’est toujours sur le pilote natif, vous avez un problème d’initramfs ou d’ordre de modules. Corrigez‑le avant de toucher aux configs VM.

8) Ajouter le passthrough à la config d’une VM Proxmox (hostpci)

cr0x@server:~$ sudo qm set 120 --hostpci0 01:00,pcie=1 --hostpci1 03:00,pcie=1
update VM 120: -hostpci0 01:00,pcie=1 -hostpci1 03:00,pcie=1

Signification : La VM 120 obtiendra le GPU (les deux fonctions quand vous spécifiez 01:00) et l’HBA.

Décision : Si vous avez besoin de l’audio GPU aussi et que Proxmox ne le prend pas en charge implicitement, passez les deux fonctions explicitement. Démarrez ensuite la VM et vérifiez la détection côté invité.

9) Vérifier que QEMU démarre avec les périphériques attachés (Proxmox)

cr0x@server:~$ sudo journalctl -u pvedaemon -n 20 | tail
Dec 28 10:12:41 server pvedaemon[2123]:  starting task UPID:server:00003A1B:0002C2F9:676FFB29:qmstart:120:root@pam:
Dec 28 10:12:43 server pvedaemon[2123]: VM 120 started with pid 14592

Signification : La VM a démarré. Cela ne prouve pas que le périphérique s’est initialisé, mais écarte un refus immédiat de QEMU.

Décision : Si la VM ne démarre pas, inspectez la sortie de la tâche pour des erreurs VFIO/IOMMU et allez directement vérifier l’isolation de groupe et le binding pilote.

10) Dans l’invité, confirmer que le GPU/HBA est visible (invité Linux)

cr0x@server:~$ lspci -nn | egrep -i "vga|sas|scsi"
00:10.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
00:11.0 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
00:12.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)

Signification : La VM voit le matériel réel. Maintenant la bataille est pilote et stabilité, pas l’attachement.

Décision : Si absent, vous avez probablement passé le mauvais BDF, le périphérique est encore lié au pilote hôte, ou le type de machine/paramètre PCIe de la VM est incorrect.

11) Vérifier les erreurs PCIe/AER sur l’hôte (stabilité du lien)

cr0x@server:~$ dmesg | egrep -i "aer|pcie bus error|vfio|DMAR" | tail -n 8
[  912.344120] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
[  912.344141] pcieport 0000:00:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[  912.344148] pcieport 0000:00:01.0: AER:   device [8086:1901] error status/mask=00000001/00002000
[  912.344152] pcieport 0000:00:01.0: AER:    [ 0] RxErr

Signification : Les erreurs corrigées arrivent, mais des rafales fréquentes peuvent se corréler avec des hangs GPU, des chutes NIC, ou des bizarreries NVMe. Ça peut être l’intégrité du signal, des risers, l’alimentation, ou le BIOS.

Décision : Si vous voyez des erreurs corrigées répétées sous charge, vérifiez câblage/risers, réinsérez les cartes, mettez à jour le BIOS, et envisagez de forcer la vitesse PCIe à une génération inférieure pour la stabilité.

12) Vérifier la distribution des interruptions (hôte) pour une NIC/HBA passée

cr0x@server:~$ cat /proc/interrupts | egrep -i "vfio|ixgbe|i40e|mpt3sas" | head
  55:   182934   0   0   0  IR-PCI-MSI  524288-edge      vfio-pci
  56:   176211   0   0   0  IR-PCI-MSI  524289-edge      vfio-pci

Signification : Les interruptions atterrissent uniquement sur le CPU0 (la première colonne). Ça peut aller à faible débit, mais c’est une cause classique de pics de latence.

Décision : Si la latence p99 compte, configurez l’équilibrage/pinning des IRQ pour répartir les interruptions sur des cœurs alignés avec la localité NUMA.

13) Mesurer la latence stockage dans l’invité (vérif rapide)

cr0x@server:~$ iostat -x 1 3
Linux 6.6.15 (vm-storage) 	12/28/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda            120.0   250.0    6.0    18.0      96.0     3.20    8.50     4.10    10.60   0.70  25.2

Signification : await est la latence moyenne de requête en ms. Si vous attendiez un comportement NVMe et voyez 8–15ms, quelque chose en amont est défaillant (périphérique, disques, file d’attente, mode contrôleur).

Décision : Si la latence est élevée, vérifiez que l’HBA est en mode IT, contrôlez les disques et inspectez les erreurs PCIe hôte. Ne blâmez pas d’abord l’hyperviseur.

14) ESXi : vérifier si un périphérique est éligible pour passthrough (tâche de parité conceptuelle)

cr0x@server:~$ esxcli hardware pci list | egrep -n "0000:03:00.0|Passthru" -A2
214:0000:03:00.0
215:   Class Name: Serial Attached SCSI controller
216:   Passthru Capable: true

Signification : ESXi reconnaît le périphérique et indique qu’il peut être passé.

Décision : Si Passthru Capable est false, arrêtez‑vous et vérifiez le support plateforme/BIOS/IOMMU et si ESXi a un pilote/quirk pour ce périphérique.

Playbook de diagnostic rapide : trouver le goulot sans deviner

Ceci est la séquence « entrer dans la salle de crise et être utile en 10 minutes ». C’est ordonné. Ne sautez pas d’étapes par ennui.

Première étape : vérifier l’attachement et l’isolation

1. L’IOMMU est‑il activé ? (dmesg/cmdline ou paramètres hôte ESXi). Sinon, rien d’autre n’a d’importance.
2. Le périphérique est‑il isolé dans son groupe IOMMU ? Sinon, attendez instabilité ou refus de démarrage.
3. Le périphérique est‑il lié au bon pilote ? Proxmox : vfio-pci. ESXi : marqué pour passthrough et nécessite reboot.

Deuxième étape : vérifier le reset et le comportement du cycle de vie

1. Cold boot de l’hôte → démarrer la VM → arrêter la VM → redémarrer la VM. Répétez une fois.
2. Si ça échoue au deuxième démarrage, suspectez des limitations FLR/reset. Très courant pour les GPU.
3. Consultez les logs hôte pour des erreurs VFIO de reset ou des problèmes de réentraînement du lien PCIe.

Troisième étape : vérifier les réalités matérielles ennuyeuses

1. Erreurs PCIe (AER) dans dmesg ou les logs ESXi. Les erreurs corrigées en rafales sont un signe.
2. Thermique et alimentation : GPU + HBA + NIC dans un même châssis peuvent créer des transitoires d’alimentation.
3. Alignement firmware : BIOS, VBIOS GPU, firmware HBA. Un firmware ancien cause de nouvelles douleurs.

Quatrième étape : mesurer dans l’invité avec le bon prisme

1. GPU : vérifiez les clocks et l’utilisation, pas seulement les FPS. Si les clocks baissent, ce n’est pas l’hyperviseur.
2. Stockage : regardez la latence (iostat -x) et les profondeurs de file, pas seulement le débit.
3. Réseau : regardez les paquets perdus, le CPU d’IRQ et la distribution RSS, pas seulement le chiffre iperf.

Cinquième étape : seulement alors, tunez

1. Pinning NUMA et hugepages pour une latence cohérente.
2. Équilibrage/pinning des IRQ pour la stabilité NIC/HBA sous charge.
3. Désactiver les états d’alimentation agressifs si la gigue de latence vous tue.

Erreurs courantes (symptôme → cause racine → correctif)

1) La VM ne démarre pas après avoir ajouté hostpci

Symptôme : La tâche Proxmox échoue ; QEMU se plaint de VFIO ou « group not viable ».

Cause racine : Le périphérique partage un groupe IOMMU avec un autre périphérique en cours d’utilisation, ou l’IOMMU n’est pas activé.

Fix : Activez VT‑d/AMD‑Vi, vérifiez dmesg ; déplacez la carte dans un autre slot ; évitez l’ACS override sauf si vous acceptez le compromis d’isolation.

2) Le GPU fonctionne une fois, puis écran noir au reboot de la VM

Symptôme : Premier boot OK ; après arrêt/restart, le pilote invité se bloque ou le périphérique disparaît.

Cause racine : Le GPU n’a pas de FLR/reset fiable ; l’hôte ne peut pas réinitialiser proprement la fonction.

Fix : Essayez un autre modèle de GPU ; utilisez vendor‑reset si disponible ; préférez des GPU serveur/workstation pour la disponibilité ; planifiez un reboot hôte comme récupération (et documentez‑le).

3) La performance stockage est « correcte » jusqu’à la charge base de données, puis p99 explose

Symptôme : Les benchs semblent ok ; la charge réelle a des pics de latence et des timeouts.

Cause racine : HBA en mode RAID/IR, inadéquation de file, ou interruptions fixées sur un seul cœur ; parfois des disques SMR faisant des choses SMR.

Fix : Assurez‑vous du mode IT ; tunez les profondeurs de file ; répartissez les interruptions ; validez les modèles de disques et le comportement d’écriture.

4) VM en passthrough NIC a un gros débit mais pertes aléatoires de paquets

Symptôme : iperf montre le line rate ; le trafic réel subit des pertes et des retransmissions.

Cause racine : Déséquilibre IRQ, mauvaise configuration RSS, buffers d’anneau trop petits, ou erreurs PCIe sous charge.

Fix : Vérifiez les interruptions, tunez les paramètres du pilote dans l’invité, vérifiez la stabilité du lien (AER) et alignez la topologie NUMA (NIC proche du CPU/mémoire utilisée).

5) ESXi indique qu’un périphérique n’est « pas capable » même si le matériel le supporte

Symptôme : ESXi refuse le périphérique pour DirectPath I/O.

Cause racine : IOMMU désactivé dans le BIOS, bug firmware plateforme, ou périphérique/pilote pas sur le chemin supporté par ESXi.

Fix : Activez l’IOMMU dans le BIOS, mettez à jour le BIOS, validez le support du périphérique, et pensez à SR‑IOV/paravirtual si le périphérique est un cas particulier.

6) Vous avez passé un HBA… et maintenant le stockage hôte a disparu

Symptôme : L’hôte boot parfois ; après des changements, le disque racine manque ou le pool ZFS introuvable.

Cause racine : Vous avez passé le contrôleur qui contient vos disques de boot ou de données. Self‑own classique.

Fix : Séparez le stockage de boot de celui passé en passthrough. Traitez‑le comme une exigence de conception, pas comme une suggestion.

Trois mini‑histoires d’entreprise (anonymisées, plausibles, douloureusement familières)

Incident causé par une mauvaise hypothèse : « les groupes IOMMU sont par slot, non ? »

L’équipe a hérité d’un petit cluster virtualisé qui avait grandi organiquement : quelques serveurs très cores, NICs mélangées, et un nœud GPU « spécial » pour les expériences ML. Le plan était simple : ajouter un deuxième GPU dans un slot vide, passer les deux à des VMs séparées, et laisser le groupe data‑science s’auto‑servir.

Ils ont fait la config Proxmox soigneusement — binding VFIO, entrées hostpci, même la documentation de quel VM a quelle carte. Le premier GPU a fonctionné. Le second… a fonctionné, mais seulement quand la première VM était arrêtée. Quand les deux étaient up, une VM gèlerait sous charge et l’autre enregistrerait des erreurs PCIe.

L’hypothèse erronée était subtile : ils supposaient que la carte mère isolait chaque slot dans son propre groupe IOMMU. En réalité, deux slots partageaient le même pont PCIe upstream sans séparation ACS, et la plateforme groupait plusieurs périphériques ensemble. Le « slot vide » n’était pas indépendant opérationnellement. Il était juste physiquement vide.

La correction n’a pas été un paramètre noyau intelligent. Ils ont déplacé un GPU dans un slot sur un autre root complex, mis à jour le BIOS, et accepté que la topologie de la carte mère — pas l’hyperviseur — soit la contrainte réelle. La note post‑incident était courte et nette : « La topologie PCIe est une donnée d’entrée de conception, pas une après‑pensée. »

Optimisation qui a mal tourné : « Forçons la performance max partout »

Une équipe façon fintech avait des services sensibles à la latence et l’habitude du tuning. Ils ont déplacé une VM appliance réseau sur Proxmox et lui ont donné des VFs SR‑IOV pour atteindre des débits paquets inaccessibles avec virtio‑net pur. Ça a marché. Ils ont donc fait les rituels habituels : désactiver les C‑states CPU, mettre le gouverneur CPU en performance, et pousser la coalescence d’interruptions NIC pour réduire la charge.

Le débit s’est amélioré sur papier. L’utilisation CPU a baissé. Tout le monde s’est félicité. Puis la latence tail côté client s’est empirée, de manière intermittente et seulement pour certains schémas de trafic. Il a fallu trop de temps pour voir la corrélation : des rafales lourdes provoquaient des micro‑rafales dans la VM appliance, et les nouveaux réglages de coalescence ont transformé « beaucoup de petites interruptions opportunes » en « quelques interruptions massives ».

Pire, la désactivation des C‑states a changé le comportement thermique. Les ventilateurs ont eu des montées étranges, et un hôte a commencé à logguer des erreurs PCIe corrigées sous charge soutenue. Rien n’a planté, mais le système vivait plus près du bord. L’« optimisation » a dépensé plusieurs petites marges de sécurité.

Le rollback fut ennuyeux : revenir aux valeurs de coalescence par défaut, garder des réglages d’alimentation raisonnables, et ne pinner les CPU / tuner les IRQ que là où la mesure le justifiait. Ils ont gardé SR‑IOV car il résolvait le problème central, mais ont arrêté d’essayer d’être plus malin que le matériel sans modèle de latence clair. Leçon : le tuning sans modèle de latence n’est que du culte cargo avec un vocabulaire amélioré.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « On a fait un test de reboot planifié »

Une société média faisait des VMs de transcodage accélérées GPU sur ESXi. Ils avaient une fenêtre de changement pour patcher : firmware hôte, mises à jour ESXi, et pilotes invités. L’environnement était stable, donc la tentation était de faire les mises à jour et d’appeler ça fait.

Au lieu de cela, leur lead ops a insisté pour un « test cycle de reboot » sur un hôte : patcher, puis faire passer chaque VM par start/stop/start deux fois, et faire un reboot hôte complet entre les passes. Ça semblait excessif. Ça a aussi pris du temps qu’ils n’avaient pas envie de dépenser.

Au deuxième redémarrage de VM après le patch, un GPU a échoué à s’initialiser. Ça n’arrivait pas systématiquement. Ça ne se voyait pas dans des tests smoke basiques. Mais c’était réel, et le mode d’échec était exactement celui qui devient un incident à 2 h du matin quand un hôte redémarre de manière inattendue.

Parce qu’ils l’ont détecté en staging, ils ont pu rollback la combinaison de pilotes et planifier une mise à jour firmware prise en charge par le fournisseur plus tard. Pas de drame. Pas d’impact client. Juste une invitation calendrier et un runbook corrigé. La pratique ennuyeuse — tester le comportement du cycle de vie, pas seulement le premier boot — a fait la différence entre « léger retard » et « grosse panne ».

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

Checklist de conception (avant de toucher aux fichiers de config)

• Définissez les non‑négociables : avez‑vous besoin de migration à chaud, HA restart, snapshots, ou s’agit‑il d’une « pet VM » liée à un hôte ?
• Choisissez la stratégie périphérique : passthrough complet vs SR‑IOV vs paravirtual. Par défaut, optez pour paravirtual sauf si vous pouvez nommer le goulot.
• Validez la topologie : quel socket CPU est lié au slot ? Quel groupe IOMMU ? Ne devinez pas.
• Séparez le boot des périphériques passthrough : l’hôte doit booter et être gérable sans le contrôleur passé.
• Documentez la récupération de reset : que faites‑vous quand le périphérique ne se réinitialise pas ? Reboot hôte ? Cycle d’alimentation ? Détachement/rattachement scripté ?

Étapes Proxmox (baseline pragmatique)

1. Activez VT‑d/AMD‑Vi dans le BIOS/UEFI. Activez « Above 4G decoding » si vous faites des GPU/NVMe avec de grandes BARs.
2. Ajoutez les params noyau (intel_iommu=on ou amd_iommu=on, plus iommu=pt), redémarrez.
3. Vérifiez les groupes IOMMU ; relocalisez les cartes si nécessaire.
4. Binder les périphériques à vfio-pci via /etc/modprobe.d/vfio.conf, mettez à jour initramfs, redémarrez.
5. Ajoutez les entrées hostpci à la VM ; utilisez pcie=1 pour les périphériques modernes.
6. Démarrez l’invité, installez les pilotes fournisseurs, validez la stabilité sur plusieurs cycles start/stop.
7. Ce n’est qu’après : pinning NUMA, hugepages, tuning IRQ si vous avez des objectifs de latence mesurés.

Étapes ESXi (baseline opérationnellement sûr)

1. Activez l’IOMMU dans le BIOS/UEFI.
2. Confirmez que le périphérique est vu et « passthru capable ».
3. Marquez le périphérique pour passthrough dans la configuration hôte ; redémarrez l’hôte.
4. Ajoutez le périphérique à la VM ; acceptez que vMotion soit généralement hors jeu.
5. Validez les pilotes invités et le comportement du cycle de vie (boucles start/stop/reboot).
6. Si vous avez besoin de mobilité, évaluez SR‑IOV (pour NIC) ou vGPU/médiation (pour GPU) dans vos contraintes support.

Checklist opérationnelle (ce que vous écrivez dans le runbook)

• Comment confirmer que le périphérique est attaché (commandes hôte et invité).
• Comment récupérer d’un échec de reset (étapes exactes, besoins fenêtre maintenance).
• Comment patcher en sécurité (ordre : firmware, hyperviseur, pilotes invités ; boucles de validation).
• Quels logs collecter pour l’escalade (dmesg/AER hôte, logs VM, logs pilotes invités).
• Quelles fonctionnalités sont désactivées (migration, snapshots, suspend/resume), pour éviter les surprises.

FAQ

1) Le passthrough PCIe est‑il « plus rapide » que virtio/vmxnet3 ?

Parfois. Pour des taux de paquets élevés, une latence faible, ou des offloads spécialisés, passthrough/SR‑IOV peut l’emporter. Pour des charges générales, les périphériques paravirtualisés sont souvent proches en performance et bien plus simples à exploiter.

2) Pourquoi mon passthrough GPU fonctionne au premier boot mais échoue après reboot VM ?

Comportement de reset. Certains GPU n’implémentent pas un FLR fiable, ou la plateforme ne peut pas réinitialiser proprement le périphérique. Vous vous retrouvez à devoir redémarrer l’hôte ou faire un cycle d’alimentation pour récupérer.

3) Dois‑je passer un HBA à une VM TrueNAS/ZFS ?

Si vous voulez que la VM possède les disques directement avec visibilité complète (SMART, gestion des erreurs), oui — passer un HBA est une conception courante et saine. Assurez‑vous simplement que l’hôte ne dépend pas de cet HBA pour le boot ou le stockage de gestion.

4) L’override ACS sur Proxmox est‑il sûr ?

Il peut faire « fonctionner » les choses en séparant des groupes IOMMU, mais ce n’est pas une isolation magique. Vous échangez des garanties de sécurité contre de la flexibilité. En production, préférez du matériel qui fournit des groupes propres sans override.

5) Puis‑je migrer à chaud une VM utilisant le passthrough ?

Généralement non. Le passthrough complet attache la VM à l’hôte physique. Certaines approches médiées (SR‑IOV, vGPU) peuvent restaurer une mobilité partielle, mais elles viennent avec des contraintes plateforme.

6) Quel est le plus gros piège performance du passthrough ?

NUMA et interruptions. Un périphérique passé peut être « rapide » mais donner une terrible latence tail si les interruptions et la localité mémoire sont mal alignées.

7) Ai‑je besoin de hugepages pour le passthrough GPU ?

Pas strictement. Les hugepages peuvent réduire la pression TLB et améliorer la cohérence pour certaines charges, mais elles ajoutent des contraintes d’allocation. Utilisez‑les quand vous avez mesuré un bénéfice ou des patterns de charge connus.

8) Pour les NICs, devrais‑je préférer SR‑IOV au passthrough complet ?

Souvent oui. SR‑IOV offre des performances proches du passthrough tout en laissant le host garder le contrôle de la fonction physique. Mais il ajoute de la complexité opérationnelle (cycle de vie des VF, correspondance des pilotes, posture sécurité).

9) Pourquoi ESXi dit que mon périphérique n’est pas passthrough‑capable ?

Le plus souvent : IOMMU désactivé dans le BIOS, firmware obsolète, ou le périphérique n’est pas sur le chemin supporté qu’ESXi attend. ESXi est conservateur ; il refuse les configs qu’il ne peut pas garantir.

10) Lequel est « plus simple » globalement pour un hôte mixte GPU + HBA + NIC en passthrough ?

Proxmox est plus simple si vous voulez bricoler et dépanner à l’échelle du noyau Linux. ESXi est plus simple si vous voulez des garde‑fous et que votre matériel est mainstream et supporté.

Conclusion : prochaines étapes utiles

Si vous choisissez une plateforme pour le passthrough PCIe, ne partez pas d’une idéologie. Commencez par votre budget d’échec et vos besoins de migration.

• Si vous avez besoin de mobilité et d’opérations en flotte, par défaut utilisez des périphériques paravirtualisés et réservez le passthrough aux cas où il compte vraiment. ESXi brille souvent ici.
• Si vous avez besoin du contrôle maximal des périphériques et que vous êtes à l’aise dans les logs noyau et la topologie PCIe, Proxmox est un très bon choix — surtout pour le bricolage GPU et le passthrough HBA.
• Quel que soit votre choix, traitez le passthrough comme un projet d’intégration matériel : validez les groupes IOMMU, le comportement de reset et la stabilité du cycle de vie avant de promettre quoi que ce soit aux parties prenantes.

Prochaine étape pratique : choisissez une charge cible, construisez un hôte unique, et exécutez la boucle de test cycle de vie (start/stop/reboot deux fois) avant de monter en échelle. Cet exercice ennuyeux empêche la plupart des surprises coûteuses.