Aller au contenu

PCI passthrough, vGPU, SR-IOV

Day 1 · DéployerNiveau 3 · MaîtriserProcédureRédigé · à valider en lab

Attribuer à une VM un périphérique PCIe physique (GPU, carte réseau, HBA), une fraction de GPU (vGPU, mediated device) ou une fonction virtuelle SR-IOV, en passant par un mapping de ressource au niveau Datacenter pour rester propre en cluster.

Trois façons de partager du matériel

Mode Principe Partage Migration à chaud
Passthrough PCI Périphérique entier donné à une VM Non (1 VM) Non
vGPU / mdev Le pilote hôte découpe le GPU en instances Oui (N VM) Expérimentale, NVIDIA uniquement, option live-migration-capable du mapping
SR-IOV La carte expose des fonctions virtuelles (VF) PCI Oui (N VF) Non

Avant de toucher la prod

  • BIOS/UEFI : VT-d / AMD-Vi sur « Enabled » (« Auto » ne suffit pas), SR-IOV activé si besoin, ACS si proposé.
  • Matériel compatible : GPU listé par le fabricant pour le passthrough ou vGPU, licence NVIDIA vGPU si concernée.
  • Pilote NVIDIA vGPU compatible PVE 9 (au minimum 570.158.02 / GRID 18.3 selon le guide de mise à niveau).
  • VM cible en q35 + OVMF, arrêtée.
  • Acceptation que la VM ne migrera plus à chaud et que la HA devra disposer du même matériel sur un autre nœud.

Étapes

1. Vérifier l'IOMMU

AMD : IOMMU actif par défaut. Intel : actif par défaut depuis le noyau 6.8, donc sur PVE 9 ; sinon ajouter intel_iommu=on. iommu=pt peut améliorer les performances si le matériel le supporte.

dmesg | grep -e DMAR -e IOMMU -e AMD-Vi        # "IOMMU enabled" ou "AMD-Vi" attendu
dmesg | grep remapping                          # interrupt remapping actif
pvesh get /nodes/pve01/hardware/pci --pci-class-blacklist ""   # colonne iommugroup

Le périphérique doit être seul dans son groupe IOMMU (avec ses propres fonctions, ex. l'audio HDMI d'un GPU). Sinon : changer de slot. pcie_acs_override est un dernier recours non supporté par le MSP.

2. Charger VFIO (passthrough complet et SR-IOV)

cat > /etc/modules-load.d/vfio.conf <<EOF
vfio
vfio_iommu_type1
vfio_pci
EOF
update-initramfs -u -k all
reboot
lsmod | grep vfio

Pour un GPU, empêcher l'hôte de le prendre (ex. blacklist nouveau dans /etc/modprobe.d/blacklist.conf). Ces modules ne sont pas nécessaires pour le vGPU (mdev).

3. SR-IOV : créer les VF (si applicable)

echo 4 > /sys/bus/pci/devices/0000:41:00.0/sriov_numvfs      # temporaire
apt install sysfsutils
echo "bus/pci/devices/0000:41:00.0/sriov_numvfs = 4" > /etc/sysfs.d/sriov-nic.conf

4. Créer le mapping de ressource

Datacenter → Resource Mappings → section PCI Devices → Add : nom gpu-a16, puis cocher pour chaque nœud le périphérique correspondant. Pour le vGPU, cocher Use with Mediated Devices. Les droits se donnent sur /mapping/pci/gpu-a16 (privilège Mapping.Use pour l'utiliser dans une VM).

pvesh get /nodes/pve01/hardware/pci --pci-class-blacklist ""   # relever l'ID 0000:81:00.0
pvesh create /cluster/mapping/pci --id gpu-a16 \
  --map node=pve01,path=0000:81:00.0,id=10de:25b6 \
  --map node=pve02,path=0000:81:00.0,id=10de:25b6

Pour SR-IOV, un même mapping peut lister plusieurs VF par nœud : au démarrage de la VM, la première VF libre est utilisée, dans l'ordre des chemins déclarés.

5. Attribuer à la VM

VM 101 → Hardware → Add → PCI Device → Mapped Device gpu-a16. Cocher PCI-Express ; Primary GPU seulement si la VM doit afficher par ce GPU. Pour le vGPU, choisir le MDev Type.

qm set 101 --hostpci0 mapping=gpu-a16,pcie=1
# vGPU : lister les types puis attribuer
ls /sys/bus/pci/devices/0000:81:00.4/mdev_supported_types
qm set 101 --hostpci0 mapping=gpu-a16,mdev=nvidia-xxx,pcie=1
# sans mapping (mono-nœud) : qm set 101 --hostpci0 0000:81:00.0,pcie=1

Démarrer la VM et installer le pilote du fabricant dans l'invité.

Vérifications

qm config 101 | grep hostpci
# hostpci0: mapping=gpu-a16,pcie=1
lspci -nnk -s 81:00.0
# Kernel driver in use: vfio-pci   (passthrough complet, VM démarrée)

Dans l'invité : lspci (Linux) ou le Gestionnaire de périphériques (Windows) montre la carte ; nvidia-smi répond pour un GPU NVIDIA.

Rollback

VM arrêtée : supprimer le périphérique (qm set 101 --delete hostpci0). Retirer /etc/modules-load.d/vfio.conf et les blacklists, update-initramfs -u -k all, redémarrer le nœud pour rendre le périphérique à l'hôte.

Pièges vus en support

  • Passthrough d'un contrôleur qui porte aussi les disques boot ou la carte réseau de management : nœud injoignable au démarrage de la VM.
  • Groupe IOMMU partagé : tous les périphériques du groupe partent dans la VM.
  • VM avec périphérique passé en HA sans mapping équivalent sur le nœud de repli : redémarrage impossible ailleurs.
  • Snapshot avec RAM et sauvegarde en mode suspend : non fiables avec un périphérique passé.
  • Après un changement de noyau, échec du passthrough : démarrer le noyau précédent et l'épingler (proxmox-boot-tool kernel pin), puis ticket MSP.

Quand ouvrir un ticket iTop

Étude de faisabilité GPU/vGPU ou SR-IOV : P4 avant achat. VM qui ne démarre plus après ajout du périphérique, nœud figé : P2. Joindre dmesg | grep -i -e vfio -e iommu, la sortie pvesh get /nodes/<nœud>/hardware/pci, qm config <vmid>.

Ouvrir un ticket iTop

Pour aller plus loin