Différences

Ci-dessous, les différences entre deux révisions de la page.

--- sysadmin:linux:virtualisation:kvm:configurer-gpu-passthrough [2025/12/17 09:44] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ sysadmin:linux:virtualisation:kvm:configurer-gpu-passthrough [2026/01/03 16:09] (Version actuelle) – yoann
@@ Ligne 1: / Ligne 1: @@
+{{tag>sysadmin virtualisation vm kvm gpu passthrough}}
+:TODO_DOCUPDATE:
+====== KVM : Activer le GPU passthrough ======
+L'usage direct du GPU présent sur la carte vidéo additionnelle de l'hôte par une VM (**GPU passthrough**) permet d'obtenir le plus haut niveau de performance exigé par certaines applications s'exécutant sur un système virtualisé ayant besoin d'exploiter au maximum les capacités du GPU comme le rendu 3D ou le machine learning.
+Le GPU et les contrôleurs intégrés à la carte graphique additionnelle de l'hôte (contrôleur audio, parfois usb et série)  seront dédiés à l'usage exclusif de la VM : le système invité les pilotera directement.
+<note>
+Dans ce mode de fonctionnement, l'affichage sur l’hôte sera alors assuré par une autre carte vidéo : le plus souvent la carte intégrée à la carte mère.
+</note>
+===== Environnement =====
+  * Ubuntu 25.10 (questing)
+  * Linux 6.17.0-8-generic
+  * libvirtd (libvirt) 11.6.0
+  * AMD AMD Ryzen 7 7800X3D ; 32 GO RAM ; carte-mère Asus TUF GAMING X670E-PLUS WIFI
+===== Prérequis =====
+Pour que cela soit possible, le PCI passthrough doit être supporté matériellement :
+  * Côté processeur : avec les fonctionnalité **VT-d** pour Intel ou **AMD-IOV/AMD-Vi**  pour AMD ;
+  * Côté carte mère : le **IOMMU**((**I**nput-**O**utput **M**emory **M**anagement **U**nit)) intégré au chipset permet aux périphériques qui en sont capables (GPU, contrôleur réseau, contrôleur de stockage) d'accéder directement à la mémoire (**D**irect **M**emory **A**ccess ou DMA) sans solliciter le CPU. Il assure également un rôle d'isolation des entrées/sorties et des accès à la mémoire pour éviter qu'une machine virtuelle ne fasse une attaque DMA sur le matériel du serveur physique.
+C'est dans le BIOS de l’hôte qu'il faudra activer ces options.
+Pour vérifier que les options de virtualisation nécessaires sont présentes sur le CPU de l’hôte :
+Via la commande **lscpu** :
+<code bash>
+lscpu | grep "Virtualisation"
+</code>
+La commande doit retourner :
+<file>
+Virtualisation: VT-x   # Intel
+Virtualisation: AMD-V  # AMD
+</file>
+Via le fichier **''/proc/cpuinfo''** :
+  * Pour les processeurs Intel la fonctionnalité de vmx doit être listée ;
+  * Pour les processeurs AMD la fonctionnalité de virtualisation du processeur est désignée **SVM** ((**S**ecure **V**irtual **M**achine)).
+<code bash>
+# La commande doit retourner une valeur supérieure à 0
+egrep -c '(vmx|svm)' /proc/cpuinfo
+</code>
+Vérifier que l'IOMMU est détecté :
+<code bash>
+journalctl -b 0 --grep "IOMMU"
+</code>
+===== Configuration de l’hôte =====
+==== Rechercher l'ID matériel et le groupe IOMMU ====
+<note>
+Afin qu'il puisse être correctement assigné et utilisé par la VM, le GPU et les périphériques partageant le même groupe IOMMU doivent avoir leur pilote remplacé par le pilote VFIO afin qu'il ne soient pas utilisés par l’hôte.
+</note>
+On cherche d'abord à déterminer l'ID du GPU et des périphériques associés au même groupe IOMMU.
+<code bash>
+# Lister les périphérique PCI en affichant leurs IDs (ID Vendor:ID Device) et le groupe IOMMU
+lspci -nn -vmm
+</code>
+Dans l'exemple ci-dessous, un extrait du retour de la commande ''lspci''. La carte graphique ''10de:2786'' et le contrôleur audio ''10de:22bc'' font parti du même groupe IOMMU, ils seront donc paramétrés ensembles.
+<file txt [highlight_lines_extra="4,5,10,14,15,20"]>
+...
+Slot:   01:00.0
+Class:  VGA compatible controller [0300]
+Vendor: NVIDIA Corporation [10de]
+Device: AD104 [GeForce RTX 4070] [2786]
+SVendor:        Gigabyte Technology Co., Ltd [1458]
+SDevice:        Device [40ed]
+Rev:    a1
+ProgIf: 00
+IOMMUGroup:     13
+Slot:   01:00.1
+Class:  Audio device [0403]
+Vendor: NVIDIA Corporation [10de]
+Device: AD104 High Definition Audio Controller [22bc]
+SVendor:        Gigabyte Technology Co., Ltd [1458]
+SDevice:        Device [40ed]
+Rev:    a1
+ProgIf: 00
+IOMMUGroup:     13
+...
+</file>
+Les identifiants des périphériques correctement déterminés, on peut à présent modifier la configuration de l’hôte afin de forcer le chargement des pilotes VFIO en leiu et place des pilotes initiaux.
+Affiche les pilotes utilisés par l’hôte avant modification :
+<code bash [highlight_lines_extra="4"]>
+lspci -kd 10de:2786
+:00.0 VGA compatible controller: NVIDIA Corporation AD104 [GeForce RTX 4070] (rev a1)
+        Subsystem: Gigabyte Technology Co., Ltd Device 40ed
+        Kernel driver in use: nvidia
+        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
+</code>
+Ici on peut voir qu'on utilise le pilote propriétaire nvidia.
+==== Mise à jour du bootloader ====
+On met à jour grub via le fichier ''/etc/default/grub''. on inclus les paramètres ci-dessous en fonction de l'architecture dans la variable ''GRUB_CMDLINE_LINUX_DEFAULT'' sans écraser les valeurs pré-existantes.
+<file>
+# Mettre à jour la variable sans écraser le contenu existant
+GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt vfio-pci.ids=10de:2786,10de:22bc"  # Intel
+GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=on iommu=pt vfio-pci.ids=10de:2786,10de:22bc"    # AMD
+</file>
+<note>
+Bien renseigner les valeurs des IDs retournés par la commande lspci.
+</note>
+<code bash>
+update-grub
+</code>
+==== Mise à jour de modprobe ====
+Modifier la configuration de modprobe en éditant le fichier ''/etc/modprobe.d/vfio.conf'', insérer le contenu suivant :
+<file>
+options vfio-pci ids=10de:2786,10de:22bc
+</file>
+Empêcher le chargement des pilotes nvidia en créant le fichier ''/etc/modprobe.d/disable‑nvidia.conf'' avec le contenu suivant
+<file>
+blacklist nouveau
+blacklist nvidia
+blacklist nvidia_drm
+</file>
+Redémarrer le système
+<code bash>
+systemctl reboot
+</code>
+<note>
+Si après redémarrage, l'affichage reste noir sur l' écran du système hôte c'est bon signe : il faut penser à connecter l'écran sur la sortie vidéo de la carte intégrée car la carte vidéo additionnelle n'est plus directement exploitée par l’hôte.
+</note>
+Après redémarrage vérifier les pilotes chargés pour le GPU sur le système hôte
+<code bash>
+lspci -kd 10de:2786
+</code>
+On doit obtenir un retour de la forme :
+<file conf [highlight_lines_extra="3"] >
+:00.0 VGA compatible controller: NVIDIA Corporation AD104 [GeForce RTX 4070] (rev a1)
+        Subsystem: Gigabyte Technology Co., Ltd Device 40ed
+        Kernel driver in use: vfio-pci
+        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
+</file>
+<note>
+Si après redémarrage l'affichage n'a pas basculé et les pilotes vfio ne sont pas utilisés, confère section [[sysadmin:linux:virtualisation:kvm:configurer-gpu-passthrough#gpu_hote_non_isole|dépannage : GPU  hôte non isolé]].
+</note>
+==== Vérifier les logs ====
+Une fois que l’affichage de l’hôte fonctionne avec la carte intégrée et que la carte additionnelle utilise les pilotes VFIO, le paramétrage coté l’hôte est terminé.
+Vérifier cependant les **logs** et les **services** système. Dans le cas présent :
+  * La command ''systemctl status'' retourne un état "dégradé" car le service ''nvidia-persistenced.service'' est en faute.
+  * De nombreux messages sont générés en permanence dans le journal système et son occupation disque croit rapidement.
+Exemple de messages :
+<file>
+déc. 30 13:19:56 juggernaut kernel: NVRM: No NVIDIA devices probed.
+déc. 30 13:19:56 juggernaut kernel: nvidia-nvlink: Unregistered Nvlink Core, major device number 507
+déc. 30 13:19:56 juggernaut (udev-worker)[3044]: nvidia: Process '/sbin/modprobe nvidia-modeset' failed with exit code 1.
+déc. 30 13:19:56 juggernaut kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 507
+déc. 30 13:19:56 juggernaut kernel: NVRM: GPU 0000:01:00.0 is already bound to vfio-pci.
+déc. 30 13:19:56 juggernaut kernel: NVRM: The NVIDIA probe routine was not called for 1 device(s).
+déc. 30 13:19:56 juggernaut kernel: NVRM: This can occur when another driver was loaded and
+                                     NVRM: obtained ownership of the NVIDIA device(s).
+déc. 30 13:19:56 juggernaut kernel: NVRM: Try unloading the conflicting kernel module (and/or
+                                     NVRM: reconfigure your kernel without the conflicting
+                                     NVRM: driver(s)), then try loading the NVIDIA kernel module
+                                     NVRM: again.
+</file>
+Comme la carte n'est plus utilisée directement par l’hôte, on désinstalle les pilotes propriétaire nvidia :
+<code bash>
+# Lister les paquets installés
+apt list --installed | grep nvidia
+# Suppression des paquets installés
+apt remove --purge nvidia-*
+apt autoremove --purge
+</code>
+===== Configuration de la VM =====
+:TODO_DOCUPDATE:
+<file>
+virt-install --name="mistral-7b" \
+--metadata title="Test Mistral M8x7B",description="Mistral 8x7B / Ollama / Debian 13" \
+--vcpus=8 \
+--memory=16384 \
+--osinfo=debian13 \
+--features kvm_hidden=on \
+--machine q35 \
+--disk path=/home/yoann/KVM/mistral-7b/vda,bus=virtio,format=qcow2 \
+--cdrom=/home/yoann/KVM/sysinstall/debian-13.2.0-amd64-netinst.iso \
+--graphics spice \
+--video virtio \
+--network network=default,model=virtio \
+--console pty,target_type=virtio \
+--hostdev pci_0000_01_00_0 \
+--hostdev pci_0000_01_00_1 \
+--wait -1
+</file>
+===== Dépannage =====
+==== GPU hôte non isolé ====
+Dans un premier temps, on essaie de modifier la configuration de modprobe en tentant de charger le pilote vfio au moment où udev charge les pilotes du GPU. C'est la méthode recommandée car ainsi on n’agrandit pas initramfs en y ajoutant des pilotes.
+Dans le fichier ''/etc/modprobe.d/vfio.conf'' ajouter la directive selon le pilote utilisé :
+<file>
+softdep drm pre: vfio-pci
+</file>
+Pour les pilotes propriétaires nvidia :
+<file>
+softdep nvidia pre: vfio-pci
+</file>
+Pour exemple le fichier après modification :
+<file>
+softdep nvidia pre: vfio-pci
+options vfio-pci ids=10de:2786,10de:22bc
+</file>
+Si après redémarrage les pilotes vfio ne sont toujours pas chargés pour le GPU, il faudra modifier initramfs.
+=== Modification du initramfs via dracut ===
+Ubuntu utilise dracut pour générer/modifier le fichier initramfs. Créer le fichier de configuration ''/etc/dracut.conf.d/10-vfio.conf'' avec le contenu suivant :
+<file>
+force_drivers+=" vfio_pci vfio vfio_iommu_type1 "
+</file>
+Mettre à jour initramfs :
+<code bash>
+update-initramfs -u
+systemctl reboot
+</code>
+<note>
+C'est cette modification qui a fonctionné pour mon système hôte.
+</note>
+===== Références =====
+  * [[https://infotechys.com/gpu-passthrough-on-kvm/| Paramétrer l'accès direct au GPU pour les VMs KVM (infotechys.com) (en)]]
+  * [[https://github.com/HarbourHeading/KVM-GPU-Passthrough?tab=readme-ov-file| Paramétrer l'accès direct CPU et GPU pour une VM KVM (github.com) (en)]]
+  * [[https://www.informatiweb.net/tutoriels/informatique/bios/activer-iommu-ou-vt-d-dans-le-bios.html|Activer les options de virtualisation dans le BIOS UEFI (informatiweb.net) ]]
+  * [[https://itsfoss.gitlab.io/blog/how-to-enable-iommu-vt-d-from-the-bios-uefi-firmware-of-your-motherboard/|Activer les options de virtualisation dans le BIOS UEFI (itsfoss.gitlab.io) (en)]]
+  * [[https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit|Le composant matériel IOMMU (wikipedia.org) (en) ]]
+  * https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Isolating_the_GPU
+  * [[https://www.baeldung.com/linux/nvidia-gpu-enable-disable | Comment activer ou désactiver le GPU (baeldung.com) (en)]]

wikinotes

Outils pour utilisateurs

Outils du site

Différences

Outils de la page