Pass-through GPU sous Hyper-V : un guide indispensable pour les débutants

Par défaut, les machines virtuelles Hyper-V utilisent un adaptateur graphique émulé, suffisant pour les tâches d’affichage de base, mais dont les performances sont insuffisantes pour les charges de travail accélérées par GPU, comme le rendu 3D, l’inférence en apprentissage automatique ou les calculs basés sur CUDA. Le transfert direct du GPU Hyper-V résout ce problème en attribuant une carte vidéo physique directement à une VM, en contournant l’émulation et en donnant au système d’exploitation invité un accès complet au GPU matériel.

Ce guide présente les deux méthodes disponibles pour attribuer un GPU dans Hyper-V : l’attribution directe d’appareil (DDA) et le partitionnement du GPU (GPU-P). Lisez cet article pour découvrir comment satisfaire aux conditions à remplir concernant le matériel et les logiciels, configurer chaque méthode sur Windows Server et les versions clientes de Windows, et résoudre les problèmes courants.

NAKIVO pour la sauvegarde Hyper-V

Sauvegardes sans agent et cohérentes avec les applications pour Hyper-V. Protection contre les ransomwares, amorçage instantané des machines virtuelles à partir de la sauvegarde, prise en charge d'autres plateformes virtuelles et physiques, et bien plus encore.

Découvrez la solution

Quoi de neuf ?

Ce guide a été mis à jour pour tenir compte des changements introduits dans Windows Server 2025 et les versions récentes de Windows client :

• Windows Server 2025 introduit le partitionnement du GPU (GPU-P) en tant que fonctionnalité d’entreprise entièrement prise en charge, permettant à plusieurs VM de partager un seul GPU physique grâce à l’isolation basée sur SR-IOV.
• La migration à chaud est désormais prise en charge pour les VM avec des partitions GPU dans Windows Server 2025, ce qui permet d’effectuer la maintenance de l’hôte sans interruption des VM.
• La prise en charge du clustering avec basculement a été étendue : les VM GPU-P peuvent être configurées en tant que rôles en cluster, et les VM reposant sur DDA peuvent redémarrer sur un autre nœud du cluster si un GPU compatible est disponible.
• Le composant vGPU RemoteFX a été entièrement supprimé dans Windows Server 2025 (déconseillé depuis Windows Server 2019).
• Conseils de dépannage mis à jour et considérations relatives aux sauvegardes des VM utilisant un GPU.

Qu’est-ce que le passage direct du GPU ?

Lorsqu’une VM Hyper-V démarre, elle reçoit un adaptateur vidéo émulé qui effectue le rendu graphique à l’aide du processeur hôte. Cela suffit pour accéder à la console et utiliser les fonctions de base du bureau, mais ne permet pas d’exposer les fonctionnalités matérielles dont dépendent les charges de travail utilisant un GPU : les nuanceurs de calcul, le codage vidéo matériel, les cœurs CUDA ou la prise en charge de DirectX 12.

Le passage direct du GPU supprime cette couche d’émulation. Au lieu d’acheminer les graphiques via un adaptateur virtuel, Hyper-V attribue une carte vidéo physique à la VM au niveau de PCI Express (PCIe). Le système d’exploitation invité communique directement avec le GPU à l’aide du pilote natif du fournisseur plutôt que d’une couche d’abstraction Hyper-V. Du point de vue des applications exécutées dans la VM, le GPU se comporte comme s’il était installé sur une machine physique.

Hyper-V prend en charge deux mécanismes à cet effet. L’affectation directe d’appareil (DDA) attribue l’intégralité du GPU physique à une seule VM. Le partitionnement du GPU (GPU-P) divise une carte en fractions isolées afin que plusieurs VM puissent la partager. Ces deux mécanismes sont présentés en détail plus loin dans ce guide.

Remarque : Un GPU peut être intégré à la puce du processeur (ce qui est courant dans les processeurs Intel et AMD récents) ou monté sur une carte vidéo dédiée connectée à la carte mère via PCIe. Le transfert direct et le partitionnement du GPU ciblent généralement les GPU dédiés, bien que GPU-P puisse également fonctionner avec les cartes graphiques intégrées sur les versions clientes de Windows.

Principaux avantages du transfert direct du GPU dans Hyper-V

Une carte graphique physique connectée par transfert direct du GPU peut être utile aux particuliers, aux développeurs, aux concepteurs et à toute autre personne ayant besoin d’une accélération graphique matérielle dans une machine virtuelle. Parmi les cas d’utilisation courants, citons :

• l’exécution d’applications exigeantes en ressources graphiques, telles que la modélisation 3D, le dessin avec AutoCAD, les simulations d’ingénierie, le développement de jeux et le rendu accéléré par matériel ;
• l’exécution de jeux qui nécessitent des fonctionnalités d’accélération matérielle ; certains titres peuvent ne pas fonctionner sans carte graphique physique ;
• l’exécution de charges de travail d’apprentissage automatique (ML) et d’intelligence artificielle (IA) qui exploitent les capacités de calcul du GPU.

Le transfert direct du GPU présente les avantages suivants :

• De meilleures performances graphiques. Les VM bénéficient d’un accès direct à la carte graphique pour les applications ou les jeux exigeants. La lecture vidéo est plus fluide et le rendu accéléré par matériel avec les dernières API graphiques devient possible.
• Une utilisation flexible du matériel. Un seul hôte Hyper-V peut exécuter plusieurs VM ayant des charges graphiques variées lorsque des postes de travail dédiés ne seraient pas pratiques.
• Une réduction des coûts. Le transfert direct du GPU peut réduire les coûts matériels en consolidant les charges de travail. Cette fonctionnalité s’applique également aux déploiements d’infrastructure de postes de travail virtuels (VDI).

Transfert direct du GPU ou partitionnement du GPU (GPU-P)

Hyper-V propose deux approches pour attribuer des ressources GPU aux machines virtuelles :

• L’attribution directe de périphérique (DDA) attribue un GPU physique entier exclusivement à une seule VM. La VM bénéficie d’un accès complet au matériel et de performances maximales, mais aucune autre VM ne peut utiliser ce GPU. DDA est disponible dans Windows Server 2016 et les versions ultérieures (éditions Datacenter). Les VM reposant sur DDA ne peuvent pas faire l’objet d’une migration à chaud.
• Le partitionnement du GPU (GPU-P) divise un GPU physique en plusieurs partitions isolées à l’aide de SR-IOV, ce qui permet à plusieurs VM de partager le même matériel. Chaque VM reçoit une partie dédiée des ressources GPU (mémoire, calcul et encodeurs), avec une isolation imposée par le matériel. GPU-P est disponible en tant que fonctionnalité d’entreprise entièrement prise en charge dans Windows Server 2025 et peut également être utilisé sur les versions clientes de Windows 10/11 via PowerShell.

DDA est préférable lorsqu’une charge de travail nécessite l’intégralité du GPU ou lorsque le matériel ne prend pas en charge le partitionnement. GPU-P est mieux adapté aux environnements dans lesquels plusieurs VM ont besoin d’une accélération GPU sans nécessiter 100 % des ressources de la carte. GPU-P prend également en charge la migration à chaud et le clustering avec basculement dans Windows Server 2025, contrairement à DDA.

Un GPU physique peut fonctionner en mode DDA ou GPU-P, mais pas dans les deux modes simultanément.

Conditions à remplir

Pour configurer une VM avec un GPU en transfert direct sur un hôte Hyper-V, vous devez remplir certaines conditions matérielles et logicielles. Toutes les cartes vidéo ne prennent pas en charge cette fonctionnalité.

Conditions à remplir côté matériel

• Le processeur de l’hôte Hyper-V doit prendre en charge les fonctionnalités de virtualisation Intel VT-d ou AMD-V. La fonctionnalité appropriée doit être activée dans les paramètres UEFI/BIOS.
• L’unité de gestion de la mémoire d’entrée-sortie (IOMMU) doit être prise en charge par le processeur. Cette fonctionnalité est requise pour le transfert direct PCI Express, y compris le transfert direct du GPU.
• Pour le partitionnement du GPU avec migration à chaud dans Windows Server 2025, le processeur doit prendre en charge certaines fonctionnalités de suivi DMA (accès direct à la mémoire). Les processeurs Intel Sapphire Rapids (ou plus récents) et AMD EPYC Milan (ou plus récents) répondent à cette condition.
• Une carte vidéo équipée d’un GPU prenant en charge les technologies de virtualisation GPU, telles que NVIDIA GRID ou AMD MxGPU (GPU multiutilisateur). Ces technologies sont propres à chaque fournisseur. Le matériel de classe serveur améliore les taux de réussite. Les appareils plus anciens qui utilisent des interruptions PCI (INTx) ne sont pas pris en charge.
• Pour le partitionnement du GPU, le GPU doit prendre en charge SR-IOV (virtualisation d’E/S à racine unique). Les modèles pris en charge comprennent les GPU NVIDIA A2, A10, A16 et A40.

Conditions à remplir côté logiciel

• Windows Server 2016 ou une version ultérieure pour DDA. Windows Server 2025 Datacenter est recommandé pour le partitionnement du GPU avec prise en charge du clustering et de la migration à chaud.
• Windows 10 (version 1903 ou ultérieure) ou Windows 11 pour le partitionnement du GPU sur les systèmes clients. DDA n’est pas pris en charge sur les versions clientes de Windows.
• Le rôle Hyper-V doit être activé dans Windows.
• Les pilotes GPU les plus récents doivent être installés sur l’hôte Hyper-V et dans le système d’exploitation invité de la VM.
• Seules les VM Hyper-V de génération 2 peuvent être utilisées pour le transfert direct du GPU avec DDA.

Limitations et configurations non prises en charge

Notez que les configurations suivantes ne sont pas prises en charge lors de l’utilisation du transfert direct du GPU :

• Les VM sur lesquelles la mémoire dynamique Hyper-V est activée ne peuvent pas utiliser le transfert direct du GPU. La mémoire dynamique doit être désactivée avant l’attribution d’un GPU.
• Le passthrough GPU avec DDA est disponible uniquement dans les éditions Centre de données de Windows Server. Le partitionnement GPU dans les environnements en cluster nécessite également l’édition Centre de données.
• Si le sous-système Windows pour Linux est déployé sur l’hôte Hyper-V, une erreur de code 43 peut se produire sur la VM lorsqu’un GPU lui est attribué par partitionnement.
• Dans les versions antérieures à Windows Server 2025, les fonctionnalités de clustering telles que la haute disponibilité (HA) et la migration à chaud des VM ne sont pas prises en charge pour les VM utilisant un GPU. Windows Server 2025 ajoute la prise en charge de la migration à chaud pour les VM GPU-P et le redémarrage après basculement pour les VM DDA.
• La sauvegarde et la restauration des VM ainsi que les points de contrôle automatiques ne sont pas pris en charge pour les VM auxquelles un GPU est attribué. Désactivez les points de contrôle automatiques avant d’attribuer un GPU.

Configuration du passthrough GPU : ce que vous devez savoir

La méthode utilisée pour attribuer un GPU à une VM Hyper-V dépend de votre version de Windows et du niveau de partage matériel dont vous avez besoin. Microsoft a proposé trois approches au fil du temps, mais seules deux restent prises en charge.

vGPU RemoteFX (obsolète). Disponible de Windows Server 2012 R2 à Windows Server 2016, RemoteFX étendait le protocole RDP (Remote Desktop Protocol) pour partager un seul GPU hôte entre plusieurs VM. Cette solution était utile dans les environnements VDI à haute densité, où il n’était pas pratique de consacrer une carte complète à chaque VM. Toutefois, RemoteFX limitait la mémoire vidéo dédiée à 1 Go par VM et la fréquence d’images à 30 FPS. Microsoft l’a déclarée obsolète dans Windows Server 2019 et Windows 10 build 1809 en raison de vulnérabilités de sécurité liées à l’architecture de son implémentation dans Hyper-V, et l’a enlevé complètement dans Windows Server 2025. Si vous exécutez encore une version fournie avec RemoteFX, un mise à jour spécifique est disponible pour enlever ce composant.

Attribution directe de périphérique (DDA). Introduit dans Windows Server 2016, DDA a remplacé RemoteFX pour les scénarios nécessitant les performances complètes du GPU. Il transmet un périphérique PCIe complet (GPU, lecteur NVMe ou autre adaptateur) directement à une seule VM, sans partage ni couche d’émulation. La VM charge le pilote natif du fournisseur et bénéficie d’un accès sans restriction à la mémoire vidéo et à la fréquence d’images. DDA est l’équivalent Hyper-V du passthrough PCI de VMware. Le compromis concerne la flexibilité : une seule VM peut utiliser la carte, la VM ne peut pas faire l’objet d’une migration à chaud (elle est liée à un chemin PCIe physique sur l’hôte) et DDA est disponible uniquement dans les éditions Centre de données de Windows Server. Dans Windows Server 2025, les VM utilisant DDA prennent désormais en charge le clustering avec basculement : le cluster peut redémarrer la VM sur un autre nœud si un GPU compatible est disponible, mais la migration à chaud n’est pas prise en charge.

Partitionnement du GPU (GPU-P). GPU-P est le successeur moderne de RemoteFX. Dans Windows Server 2025, cette technologie divise un seul GPU physique en plusieurs fractions isolées à l’aide de SR-IOV, en attribuant à chaque VM une part dédiée des ressources de calcul, de mémoire et d’encodage, avec une isolation imposée par le matériel. Contrairement à DDA, GPU-P prend en charge la migration à chaud et le clustering avec basculement dans Windows Server 2025 Centre de données, ce qui en fait une solution viable pour les environnements de production qui nécessitent la mobilité des VM. Dans les versions clientes de Windows (Windows 10 build 1903 ou ultérieur et Windows 11), GPU-P est disponible via PowerShell, mais s’appuie sur la paravirtualisation WDDM plutôt que sur le véritable partitionnement SR-IOV. L’hôte et l’invité doivent exécuter la même version du système d’exploitation, et les pilotes GPU doivent être copiés manuellement de l’hôte vers l’invité.

En pratique, la règle est simple : si vous avez besoin du GPU complet pour une seule VM sous Windows Server, utilisez DDA. Si plusieurs VM ont besoin de l’accélération GPU ou si vous avez besoin de la migration à chaud, utilisez GPU-P sous Windows Server 2025. Sous Windows client, GPU-P via PowerShell est la seule solution prise en charge.

Configuration du passthrough GPU dans Hyper-V

Suivez les étapes ci-dessous pour préparer l’environnement et configurer le passthrough GPU dans Hyper-V.

Préparation de la configuration du passthrough GPU

1. Assurez-vous que votre matériel et vos logiciels répondent aux conditions à remplir pour la virtualisation GPU.
2. Activez les fonctionnalités de virtualisation Intel VT-d ou AMD-V pour votre processeur dans l’UEFI/BIOS de l’hôte Hyper-V.
3. Activez IOMMU . L’emplacement du paramètre IOMMU varie selon les cartes mères et les versions de l’UEFI/BIOS. Dans certains cas, il se trouve dans la configuration du North Bridge. IOMMU peut également être activé lorsque vous activez Intel VT-d ou AMD-V. Vérifiez la fonctionnalité Memory Remap dans l’UEFI/BIOS.

   Vous pouvez vérifier si IOMMU est activé sur un hôte Hyper-V à l’aide de la commande PowerShell suivante (à exécuter en tant qu’administrateur) :

   (Get-VMHost).IovSupport; (Get-VMHost).IovSupportReasons

   True = activé ; False = désactivé.

4. Enlevez tous les points de contrôle de la VM qui utilisera le transfert direct du GPU.

   Pour désactiver les points de contrôle automatiques d’une VM, exécutez :

   Set-VM -Name VMName -AutomaticStopAction TurnOff

Transfert direct du GPU sous Windows Server

Les étapes suivantes utilisent DDA pour attribuer un GPU physique à une VM sous Windows Server.

1. Définissez le type de cache et les limites de l’espace MMIO (E/S mappées en mémoire) pour la VM. Exécutez cette commande PowerShell en tant qu’administrateur :

   Set-VM -Name VMName -GuestControlledCacheTypes $True -LowMemoryMappedIoSpace 3Gb -HighMemoryMappedIoSpace 33280Mb

   Vous pouvez également exécuter trois commandes distinctes :

   Set-VM -GuestControlledCacheTypes $true -VMName YourVMName
   Set-VM -LowMemoryMappedIoSpace 3Gb -VMName YourVMName
   Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName YourVMName

   Ces limites définissent la fenêtre de mémoire qui rend le périphérique accessible à la VM. Vous pouvez utiliser un script de profil de machine de Microsoft pour calculer les valeurs MMIO optimales. Les valeurs correctes varient selon les cartes graphiques. Si un message indiquant que les ressources sont insuffisantes s’affiche au démarrage de la VM, arrêtez-la et ajustez ces valeurs. La valeur de 33280 Mo est utilisée pour l’espace MMIO au-dessus de 32 bits (3 Go s’appliquent à la fenêtre MMIO 32 bits).

2. Identifiez le chemin d’emplacement PCI Express de la carte graphique que vous souhaitez transférer.

   Vous pouvez le trouver dans le Gestionnaire de périphériques. Ouvrez le Gestionnaire de périphériques en exécutant la commande suivante :

   Devmgmt.msc

   Dans le Gestionnaire de périphériques :

   • Cliquez avec le bouton droit sur l’adaptateur d’affichage cible sous Cartes graphiques, puis cliquez sur Propriétés .
   • Sélectionnez l’onglet Détails .
   • Sélectionnez Chemins d’accès aux emplacements dans la liste déroulante des propriétés, puis copiez la valeur.

   

   Vous pouvez également utiliser PowerShell pour récupérer le chemin d’emplacement :

   Get-PnpDevice | Where-Object {$_.Present -eq $true} | Where-Object {$_.Class -eq "Display"}|select Name,InstanceId

   et :

   Get-PnpDevice -Class Display | ForEach-Object { Write-Output "$($_.FriendlyName) has a device id of $($_.DeviceId) and is located at $($_ | Get-PnpDeviceProperty DEVPKEY_Device_LocationPaths | Select-Object -ExpandProperty Data | Where-Object { $_ -like "PCIROOT*" })"; }

   La sortie doit contenir une chaîne semblable à :

   « PCIROOT(0)#PCI(0300)#PCI(0000) »

   

3. Désactivez la carte graphique dans le Gestionnaire de périphériques. Cliquez avec le bouton droit sur l’adaptateur vidéo, puis cliquez sur Désactiver l’appareil .
4. Démontez l’adaptateur d’affichage désactivé à l’aide de PowerShell :

   Dismount-VmHostAssignableDevice -LocationPath "PCIROOT(0)#PCI(0300)#PCI(0000)" -Force

   L’indicateur -Force est requis lorsqu’aucun pilote de partition n’est installé. Le fournisseur du périphérique peut fournir ce pilote facultatif d’atténuation des risques de sécurité. Si vous prévoyez de l’installer, faites-le avant de démonter le périphérique PCIe de l’hôte.

   Le chemin d’emplacement utilisé ci-dessus est donné à titre d’illustration ; remplacez-la par votre valeur spécifique.

5. Assignez la carte vidéo à la VM :

   Add-VMAssignableDevice -VMName VMName -LocationPath "PCIROOT(0)#PCI(0300)#PCI(0000)"

6. Mettez la VM sous tension et vérifiez que la carte vidéo physique apparaît dans le Gestionnaire de périphériques à côté de l’adaptateur vidéo Microsoft Hyper-V par défaut.
7. Installez les pilotes de la carte vidéo dans le système d’exploitation invité de la VM. Téléchargez les pilotes depuis le site officiel de NVIDIA ou d’AMD.
8. Pour déconnecter la carte vidéo de la VM, arrêtez la VM et exécutez :

   Remove-VMAssignableDevice -VMName YourVMName -LocationPath $locationPath

   Reconnectez ensuite le GPU à l’hôte Hyper-V :

   Mount-VMHostAssignableDevice -LocationPath $locationPath

Essayez NAKIVO Backup & Replication pour Hyper-V

Commencez votre essai gratuit de 15 jours pour effectuer des sauvegardes Hyper-V sans agent et cohérentes avec les applications, avec une récupération complète et granulaire instantanée ainsi qu'une protection intégrée contre les ransomwares.

ESSAYEZ GRATUITEMENT

Configuration sous Windows 10 et 11

Sur les versions clientes de Windows (Windows 10 build 1903 et versions ultérieures, Windows 11), DDA n’est pas disponible. Le partitionnement GPU est la méthode prise en charge :

1. Vérifiez si votre carte graphique prend en charge le partitionnement GPU. Sous Windows 10, exécutez :

   Get-VMPartitionableGpu

   Sous Windows 11 :

   Get-VMHostPartitionableGpu

2. Utilisez la cmdlet Add-VMGpuPartitionAdapter pour attribuer une partition GPU à la VM. Toutefois, vous devez copier les pilotes GPU de l’hôte Hyper-V vers la machine virtuelle. La version du pilote doit être identique sur l’hôte et l’invité. Le script Easy-GPU-PV peut automatiser ce processus. Téléchargez le script sous forme de fichier ZIP, puis extrayez-le dans un dossier sur l’hôte Hyper-V. Ce script exploite les mécanismes de paravirtualisation GPU utilisés par le sous-système Windows pour Linux (WSL2) et Windows Sandbox.
3. Ouvrez PowerShell en tant qu’administrateur et autorisez l’exécution des scripts :

   Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

4. Arrêtez la VM. Exécutez le script pour copier les pilotes GPU de l’hôte vers la VM :

   .\Update-VMGpuPartitionDriver.ps1 -VMName YourVMName -GPUName "AUTO"

5. Configurez la VM pour le partitionnement GPU :

   Set-VM -VMName VMName -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 1Gb -HighMemoryMappedIoSpace 32Gb
   Add-VMGpuPartitionAdapter -VMName YourVMName

6. Après avoir mis à jour les pilotes GPU sur l’hôte Hyper-V, mettez également à jour les pilotes dans la VM. La VM doit être hors tension :

   .\Update-VMGpuPartitionDriver.ps1 -VMName YourVMName -GPUName "AUTO"

7. Pour retirer la partition GPU de la VM :

   Remove-VMGpuPartitionAdapter -VMName "YourVMName"

   Une fois la configuration effectuée avec succès, l’adaptateur d’affichage correspondant doit apparaître dans le Gestionnaire de périphériques de la VM. Vous verrez également des effets visuels tels que la transparence du bureau dans le thème Windows de la machine invitée.

Notez que certains jeux et certaines applications peuvent ne pas fonctionner même après la configuration du passthrough GPU. Cela peut se produire lorsqu’une application effectue une vérification de compatibilité matérielle et que les informations GPU indiquées dans le système d’exploitation invité diffèrent de celles de l’hôte. Certaines applications détectent également leur exécution dans une VM.

Si les applications qui dépendent d’OpenGL ne fonctionnent pas dans la VM, l’installation de Pack de compatibilité OpenGL peut aider.

Lorsque vous utilisez le partitionnement GPU sous Windows 10 ou 11, l’adaptateur vidéo affiché dans le Gestionnaire de périphériques utilise un pilote Microsoft plutôt que celui du modèle de GPU physique. Les outils spécifiques aux fournisseurs, tels que le Panneau de configuration NVIDIA, ne sont pas disponibles dans la VM.

Un autre problème peut survenir si vous fermez une session RDP sans vous déconnecter au préalable. Dans ce cas, la VM peut perdre l’accès à la mémoire GPU et les applications qui dépendent du GPU signaleront que la mémoire vidéo est inaccessible. La reconnexion via RDP ne résout pas le problème ; vous devez redémarrer les applications concernées.

Résolution des problèmes de passthrough GPU

Si la carte vidéo ne fonctionne pas correctement après avoir été attribuée à une VM, vérifiez les points suivants :

• Vérifiez que les derniers pilotes GPU sont installés et qu’aucune erreur liée aux pilotes n’est présente. Ouvrez le Gestionnaire de périphériques et vérifiez l’état du périphérique. Installez les pilotes à partir du site web du fournisseur (NVIDIA, AMD, Intel) plutôt que de vous fier à Windows Update.
• Assurez-vous qu’un espace MMIO suffisant a été alloué à la VM.
• Confirmez que le passthrough GPU est officiellement pris en charge par le fournisseur pour votre carte graphique spécifique. Les cartes vidéo grand public ne prennent pas toutes en charge cette fonctionnalité. Certains fournisseurs limitent le passthrough GPU aux modèles haut de gamme.
• Vérifiez que l’application exécutée dans la VM prend en charge votre carte vidéo et ses pilotes.
• Activez la stratégie de groupe suivante pour autoriser l’utilisation du GPU via le Bureau à distance :

  Computer ConfigurationTemplatesComponentsDesktop ServicesDesktop Session HostSession Environmenthardware graphics adapters for all Remote Desktop Services sessions

  Définissez cette valeur sur Activé .

• Si vous voyez une erreur telle que L’opération a échoué, car l’objet est introuvable ou Erreur 12 , ajoutez les clés de registre suivantes à :

  HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsHyperV

  Valeurs :

  RequireSecureDeviceAssignment = 0 (REG_DWORD)

  RequireSupportedDeviceAssignment = 0 (REG_DWORD)

  Vous pouvez définir ces valeurs avec PowerShell :

  Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV" -Name "RequireSecureDeviceAssignment" -Type DWORD -Value 0 -Force
  Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV" -Name "RequireSupportedDeviceAssignment" -Type DWORD -Value 0 -Force

• Pour contourner les vérifications du pilote de l’hyperviseur dans la VM, utilisez le Kit de pilotes Windows pour entreprises (WDK) :
  • Montez l’ISO du WDK dans le lecteur DVD virtuel de la VM.
  • Exécutez E:LaunchBuildEnv.cmd (où E: est le lecteur DVD virtuel), puis exécutez PowerShell .
  • Accédez au répertoire contenant le script Remove-HypervisorChecks.ps1 .
  • Exécutez la commande pour supprimer les vérifications de l’hyperviseur pour le pilote vidéo (exemple NVIDIA) :

    ./Remove-HypervisorChecks.ps1 -Nvidia -DriverPath "C:\path-to-driver\package.exe"

  • Attendez la fin de l’exécution du script.
  • Copiez le pilote obtenu (patched-driver.zip) dans la VM, activez le mode test et installez le pilote.
• Si vous rencontrez l’erreur 43, assurez-vous que le GPU et son contrôleur audio (les cartes NVIDIA incluent souvent un périphérique audio) sont attribués ensemble à la VM.
• Si une erreur apparaît lors de l’exécution de :

  Update-VMGpuPartitionDriver.ps1 -VMName “YourVMName” -GPUName “AUTO”

  Cela peut être dû à la présence de plusieurs partitions (volumes) sur le disque dur virtuel. Essayez de définir l’attribut hidden sur les partitions non système, ou de les retirer temporairement après avoir sauvegardé les données. Vous pouvez également spécifier explicitement la partition système dans le script ou la commande PowerShell.

Considérations relatives à la sauvegarde et à la récupération des machines virtuelles avec GPU

Les workflows de sauvegarde Hyper-V standard supposent qu’une machine virtuelle est portable : vous pouvez la restaurer sur n’importe quel hôte compatible et la démarrer. Les machines virtuelles avec GPU remettent cette hypothèse en cause. Qu’il soit attribué via DDA ou GPU-P, le GPU de la machine virtuelle est lié à du matériel physique qui peut ne pas exister ou ne pas être configuré de manière identique sur la cible de récupération. La sauvegarde est donc simple, mais la récupération dépend de la disponibilité du matériel.

Le GPU ajoute également un enjeu de cohérence des données. Le logiciel de sauvegarde capture l’état du disque, mais ne peut pas créer d’instantané du contenu de la mémoire vidéo du GPU. Pour les machines virtuelles exécutant des charges de travail GPU intensives, cela signifie que la sauvegarde reflète une vue hors ligne ou cohérent en cas de plantage de l’état du matériel, même lorsque les données du disque sont cohérentes du point de vue de l’application. Pour réduire cet écart, utilisez des points de contrôle de production avec Service de clonage de volume (VSS) ou un outil de sauvegarde compatible VSS, qui garantit que les données transférées de la mémoire du GPU vers le disque sont capturées dans un état cohérent.

Le choix entre sauvegardes au niveau de l’hôte et au niveau de l’invité est moins évident pour les machines virtuelles avec GPU que pour les machines virtuelles standard :

• La sauvegarde au niveau de l’hôte capture les fichiers VHDX et la configuration de la machine virtuelle. Il s’agit de l’approche standard, mais elle nécessite de remapper manuellement le GPU après la restauration.
• La sauvegarde au niveau de l’invité nécessite l’installation d’un agent de sauvegarde dans la machine virtuelle. Cette approche est souvent plus pratique pour les charges de travail GPU, car elle traite la machine virtuelle comme un serveur standard et évite la complexité du transfert direct du GPU pendant la capture des données.

Avec les configurations DDA utilisant un transfert direct exclusif, la machine virtuelle est liée à un chemin PCI Express spécifique sur l’hôte. Si vous restaurez une machine virtuelle compatible DDA sur un autre hôte, elle ne démarrera probablement pas, car le chemin PCIe d’origine (tel que PciRoot(0x0)/Pci(0x3,0x0)…) peut ne pas exister ou être attribué à un autre appareil.

Pour résoudre une incompatibilité matérielle après la récupération :

1. Supprimez l’appareil GPU manquant de la configuration de la machine virtuelle.
2. Démontez un GPU compatible sur le nouvel hôte.
3. Réattribuez le nouveau GPU à la machine virtuelle restaurée à l’aide de PowerShell.

Avec le partitionnement du GPU dans Windows Server 2025 et Windows 11, la configuration est plus flexible, mais elle introduit ses propres considérations en matière de récupération. GPU-P nécessite que les versions des pilotes GPU de l’hôte et de l’invité correspondent. Si vous restaurez une VM sur un hôte exécutant une version différente du pilote, l’accélération GPU risque de ne pas s’initialiser.

Lors de la récupération (en particulier dans un Cluster de basculement Hyper-V), l’hôte cible doit disposer d’une capacité suffisante de partitionnement GPU. Si le GPU de l’hôte est déjà entièrement partitionné entre d’autres VM en cours d’exécution, la VM restaurée ne démarrera pas ou utilisera le rendu logiciel.

Windows Server 2025 améliore la mobilité des VM avec GPU. Les VM GPU-P prennent en charge la migration à chaud dans les configurations en cluster et autonomes. En cas de basculement, le cluster peut redémarrer la VM sur un autre nœud, à condition qu’un GPU compatible soit configuré pour DDA ou GPU-P sur l’hôte cible.

Suivez ces recommandations pour la sauvegarde et la récupération des VM avec GPU :

• Documentez les chemins PCI et consignez les commandes PowerShell utilisées pour attribuer le GPU. Un script prêt à l’emploi réduit les temps d’arrêt lors de la restauration sur un autre hôte.
• Standardisez le matériel en utilisant des modèles de GPU et des versions de pilote identiques sur tous les nœuds du cluster. Ainsi, la VM restaurée retrouvera le même environnement matériel, quel que soit l’hôte sur lequel elle démarre.
• Effectuez régulièrement des tests de restauration de VM avec GPU sur différents hôtes afin de vérifier que votre équipe de récupération sait réattribuer les périphériques PCI.
• Créez un script post-restauration qui détecte les GPU disponibles et les attribue automatiquement à la VM restaurée.

Conclusion

L’utilisation d’une machine virtuelle avec un GPU en accès direct sur un hôte Hyper-V peut être une solution optimale pour certaines charges de travail, mais les limitations nécessitent une planification minutieuse. Le matériel de classe serveur et Windows Server sont généralement recommandés pour l’accès direct aux GPU discrets basé sur DDA. Vérifiez la compatibilité logicielle et matérielle avant de commencer la configuration. Effectuez régulièrement des sauvegardes des VM Hyper-V afin de vous prémunir contre toute perte de données en cas de problème lors de la configuration du GPU ou de son fonctionnement continu.

Essayez NAKIVO Backup & Replication

Profitez d'un essai gratuit pour découvrir toutes les fonctionnalités de protection des données de la solution. 15 jours gratuits. Aucune restriction en termes de fonctionnalités ou de capacité. Aucune carte bancaire requise.

Essayez gratuitement