Protocole RDP - Microsoft déprécie vGPU RemoteFX...

De cette acquisition va naitre « RemoteFX », une évolution du protocole RDP uniquement disponible dans les environnements Hyper-V. Elle permet de prendre en charge le transfert d’une instance virtualisée d'un GPU physique (vGPU) vers une VM Windows 7, 8 et 10, ce qui s’avère particulièrement intéressant pour les déploiements VDI qui imbriquent des applications fortement consommatrices de ressources graphiques, comme la CAO ou la vidéo en temps réel.

Mais voilà, en octobre 2019, Microsoft publie un document qui présente les fonctionnalités qui allaient disparaitre et celles qui seraient remplacées à partir de la version 1803 de Windows Server. Et vGPU RemoteFX en fait partie...

C'est tout simplement pour des raisons liées à des problèmes de sécurité que Microsoft a pris la décision de déprécier vGPU RemoteFX. Les différentes mises à jour du Patch Tuesday de juillet 2020 désactivent la fonctionnalité, mais il est encore possible de la réactiver manuellement jusqu'au 9 févier 2021.

Chronologie de dépréciation :

• Déclassement : Le processeur graphique virtuel (vGPU) RemoteFX a été supprimé avec la publication de Windows 10, version 1809 et windows server 2019.
• Désactivation : Le processeur graphique virtuel (vGPU) RemoteFX sera désactivé sur toutes les plateformes Windows applicables dans les mises à jour de sécurité Windows de juillet 2020 (14 juillet 2020).
• Suppression : Le processeur graphique virtuel (vGPU) RemoteFX sera supprimé de toutes les plateformes Windows applicables dans les mises à jour de sécurité Windows d'avril 2021 (13 avril 2021). Pour plus d’informations, consultez l’article KB 4570006.

Microsoft a été le premier à utiliser l'acronyme « vGPU » (virtual Graphics Processing Unit) pour désigner une fonctionnalité de RemoteFX qui permettait à plusieurs utilisateurs, au travers du protocole RDP, de pouvoir renvoyer DirectX vers des processeurs graphiques. Le constructeur NVIDIA l'a ensuite repris pour l'associer à sa technologie GRID mais la signification n'était plus vraiment la même. Pour NVIDIA, les applications de plusieurs VMs peuvent réellement utiliser une partie d’un GPU, la VM considérant cette partie GPU comme un vrai processeur graphique physique.

En 2010, quand Microsoft a sorti vGPU RemoteFX, les GPUs n’étaient pas généralisés parce qu’à cette époque, personne n’avait besoin de puissance GPU sur ses serveurs. Il n’y avait effectivement pas encore vraiment d’usage qui s’y prêtait, les seuls besoins se retrouvaient surtout dans des jeux et des stations de travail qui exécutaient des applications de CAO. Une exception quand même pour quelques clients « haut de gamme » qui utilisaient des solutions de virtualisation très couteuse (un utilisateur/serveur) car aucune fonctionnalité de partage GPU n’existait encore dans les hyperviseurs. Le seul mode disponible était le « PCIe Passthrough » où le GPU ne pouvait être affecté qu’à une seule machine virtuelle.

Malheureusement, le mode GPU Passthrough présente de gros inconvéniants :

• Le coût : Une VM pour un GPU
• La limitation des fonctionnalités hyperviseur : Pas de migration à chaud des VMs (vMotion) et pas de snapshot en direct (entre autre)…
• La sécurité : le mode Passthrough présente des vulnérabilités en matière de sécurité car il n’y a pas de couche sur l'hyperviseur pour protéger la machine virtuelle.

En fait, les exigences croissantes des OS et des protocoles en matière de CPU nécessitaient de pouvoir déléguer une partie des traitements graphiques sur un GPU partagé et c’est surtout pour cela que Microsoft a développé vGPU RemoteFX. Même si cette fonctionnalité n’était pas conçue pour accélérer des applications graphiques 3D, ni même pour être utilisée dans des environnements VDI, elle pouvait tirer parti des GPU en toute sécurité pour une meilleure évolutivité des serveurs et pour améliorer les performances de protocole pour les postes de travail et les applications ordinaires.

Mais comme les options de partage virtuel de GPU n’existaient pas dans les hyperviseurs, Microsoft a dû adopter une approche avant-gardiste pour bénéficier des avantages d’un GPU en s’affranchissant des problèmes liés au mode GPU Passthrough. Microsoft a développé des technologies d’interception d’API, qui font que lors de l’appel de certaines API, et plus principalement de celles qui prennent en charge les fonctions graphiques du système d’exploitation et du protocole, plutôt que d’accéder directement au pilote GPU natif, une couche d’interception logicielle prenait le relai et les convertissait en appels vers le GPU.

Les inconvénients liés à ces technologies faisaient que les applications d’une VM pilotée par RemoteFX ne voyaient pas directement de processeur graphique. Mais ce n’était pas forcement gênant car elles n’avaient généralement pas besoin de GPU, hormis les applications 3D, et même si la couche d'interception réduisait une partie des performances du processeur graphique et ne procurait pas d'avantage considérable en termes d'expérience utilisateur, elle était hautement évolutive et sans restriction au niveau du nombre d'utilisateurs.

Avec l’arrivée de Windows Server 2016, Microsoft a amélioré les fonctions graphiques de RemoteFX, notamment en ajoutant OpenCL/OpenGL mais également en implémentant une passerelle PCIe DDA (Discrete Device Assignment) car un nombre croissant d’utilisateurs VDI utilisent aujourd'hui des applications qui nécessitent de la puissance graphique. Mais les technologies d'interception d'API ne sont pas vraiment préconisées, parce qu’elles nécessitent des mises à jour régulières, qu'elles dégradent les performances et qu'il existe de nombreuses alternatives pour le partage de GPU, telles que NVIDIA GRID vGPU, AMD MxGPU et Intel GVT-g. Et c’est très certainement pour toutes ces raisons (outre la sécurité) que vGPU RemoteFX a fait son temps.

Mais DDA (PCIe Passthrough) n’est pas vraiment une alternative à RemoteFX vGPU. Alors comment doit-on interpréter cette phrase de Microsoft : « Nous mettons au point de nouvelles options d’accélération graphique pour les environnements virtualisés » ? Elle sous-entend très certainement quelque chose de bien plus intéressant que DDA, car lors d’une présentation en juin 2018, dont une partie importante était consacrée au protocole RDP et à la désapprobation de vGPU RemoteFX, Ivan Mladenov révélait quelques modifications très importantes pour RDP qui pourraient étendre considérablement l'attrait de Microsoft.

Une nouvelle fonctionnalité de Windows Server 2019 ferait référence à « GPU-P » (P pour partitionnement). Apparemment, cette approche GPU-P est très similaire à celle adoptée pour le partage de GPU par AMD MxGPU. Bien que cette technologie soit moins performante que d’autres technologies de partage de GPU, l’attrait de la standardisation de SR-IOV et de son modèle de sécurité en ferait un outil pertinent, et plus particulièrement pour les contextes Cloud, Azure oblige...

Technologie GPU-P dans Azure

Avec sa série « NVv4 », Microsoft introduit dans Azure des bureaux virtuels WVD (Windows Virtual Desktop) équipés de GPU partitionnés AMD Radeon Instinct MI25 et des CPU AMD EPYC 7V12 (Rome). Aujourd’hui, ces machines virtuelles ne prennent en charge que le système d'exploitation Windows et intègrent la technologie multithreading AMD.

Bureaux virtuels WVD avec GPU AMD MxGPU

Microsoft annonce que GPU-P, actuellement en cours d'évaluation (les installations de Windows Server 2019 ne prendront pas en charge vGPU RemoteFX), sera l’alternative à RemoteFX. Et Microsoft va encore plus loin en indiquant que GPU-P sera remplacé par GPU-PV (PV pour les systèmes Para-Virtualisés) et que GPU-PV fera tout ce que fait vGPU RemoteFX aujourd'hui.

A suivre donc...