Performances graphiques dans les machines virtuelles modernes : clés réelles

Lorsqu'on configure un environnement virtuel moderne et qu'on l'utilise comme un véritable ordinateur de bureau, l'une des premières surprises est souvent de constater que, malgré un fonctionnement fluide du processeur et de la mémoire vive, l'expérience graphique dans les machines virtuelles est moins agréable : fenêtres qui se déplacent lentement, menus au défilement saccadé, vidéos YouTube moins fluides que sur l'ordinateur hôte. Ce problème persiste même sur des machines relativement performantes, dotées de processeurs modernes et de cartes graphiques intégrées puissantes.

Ce comportement n'est pas le fruit du hasard. La virtualisation introduit une couche supplémentaire entre le matériel et le système d'exploitation invité, et cette couche a un coût, notamment pour les graphismes 2D/3D et l'accélération GPU . Parallèlement, l'industrie propose de nombreuses technologies (GPU passthrough, vGPU, SR-IOV, GVT-g, GRID, MxGPU, VirGL, etc.) qui promettent d'améliorer les choses, mais il n'est pas toujours évident de savoir à quoi s'attendre de chacune d'elles, quelles sont leurs limitations, ni si l'investissement en vaut réellement la peine.

Pourquoi les performances graphiques d'une machine virtuelle ne sont jamais exactement les mêmes que celles de l'hôte

Du point de vue du système hôte, une machine virtuelle est simplement un processus en espace utilisateur. L'hyperviseur doit en permanence traduire les appels de la machine virtuelle vers le matériel physique, ce qui engendre inévitablement une surcharge . Cette surcharge est relativement faible en termes d'utilisation du processeur et de la mémoire vive pour de nombreuses charges de travail, mais elle est généralement plus perceptible au niveau des graphismes et des entrées/sorties (disque et réseau).

Dans une configuration typique avec KVM/QEMU et un serveur Debian ou Ubuntu comme hôte, les machines virtuelles de bureau utilisent généralement un périphérique graphique virtuel tel qu'un GPU Virtio (souvent avec un serveur VNC ou SPICE pour l'accès au bureau). Cette architecture implique que tout le rendu de la machine virtuelle transite par une couche supplémentaire (l'hyperviseur, le protocole distant, le compositeur hôte, etc.), ce qui entraîne une latence plus élevée, un nombre d'images par seconde plus faible et une expérience globale moins fluide que sur le système physique.

Même avec un matériel performant (par exemple, un Ryzen 7 avec Radeon Renoir intégrée capable de gérer sans problème un bureau 4K), la machine virtuelle peine à reproduire cette fluidité si elle utilise uniquement des graphismes virtuels standard ou le rendu logiciel. Les pages web complexes, les animations de bureau et la lecture de vidéos à haut débit sont les premiers cas où la baisse de performances devient perceptible.

De plus, il faut tenir compte de la perte de performance générale liée à la virtualisation : lors de tests de performance classiques , une machine virtuelle bien configurée perd environ 5 à 10 % de performances CPU , 7 à 15 % de bande passante RAM et 15 à 25 % d’IOPS disque par rapport à un système physique. Dans de nombreuses situations, cette perte est négligeable, mais combinée à l’augmentation de la charge de traitement graphique, elle peut considérablement dégrader l’expérience utilisateur.

La question clé n'est donc pas tant de savoir si les performances natives peuvent être atteintes (la réponse honnête est qu'elles ne le sont presque jamais à 100 %), mais quels mécanismes existent pour se rapprocher au maximum du comportement de l'hôte et quels compromis chacun implique.

Virtio-GPU, VirGL et graphismes 3D « logiciels » dans KVM/QEMU

Dans de nombreux environnements KVM, le Virtio-GPU est désormais privilégié par défaut pour une solution plus performante que les anciennes cartes VGA émulées. Il permet de partager certaines capacités d'accélération entre l'hôte et la machine virtuelle, et, associé à SPICE ou à un client compatible, offre généralement des performances 2D satisfaisantes pour les applications bureautiques légères, la navigation web et les environnements de développement sans trop d'effets graphiques.

Cependant, lorsque VirGL est activé pour fournir l'accélération 3D dans la machine virtuelle, les résultats peuvent varier considérablement en fonction du GPU physique, des pilotes et de la charge de travail. VirGL délègue l'exécution des commandes OpenGL de la machine virtuelle à l'hôte , mais la traduction et le contexte supplémentaire peuvent rendre le bureau, sur du matériel intégré modeste, encore plus lent qu'en l'absence d'accélération 3D : animations qui se figent, défilement moins fluide, vidéos qui utilisent le CPU au lieu du GPU, etc.

Sur les machines dotées de GPU intégrés comme AMD Renoir ou équivalent, il n'est pas rare que l'activation de VirGL laisse l'hôte avec une puissance de traitement insuffisante, ce qui entraîne des performances allant de « acceptables mais perfectibles » à « totalement insupportables ». Dans ce contexte, s'attendre à ce que VirGL transforme une machine virtuelle en un clone graphique parfait de l'hôte est irréaliste , surtout en résolution 4K avec plusieurs bureaux virtuels ouverts.

Par conséquent, si vous recherchez une expérience de bureau comparable à celle d'un véritable PC, VirGL n'est généralement pas la solution miracle. Il est utile pour certains tests 3D légers ou applications nécessitant une certaine accélération, mais il ne remplace pas un GPU physique dédié dans chaque machine virtuelle.

Transfert direct du GPU : performances quasi natives au prix d’une rigidité accrue

La méthode la plus directe pour obtenir des performances graphiques quasi identiques à celles de l'hôte consiste à utiliser le GPU passthrough via IOMMU. Dans ce cas, la machine virtuelle perçoit le GPU physique comme s'il était indépendant : les pilotes natifs sont installés au sein du système invité, ce qui permet d'atteindre des performances proches de celles d'un système physique, aussi bien en 2D qu'en 3D.

L'inconvénient est que cette configuration est assez rigide : le GPU est « accaparé » par la machine virtuelle pendant son exécution, et l'hôte ne peut plus l'utiliser pour son propre bureau. Cela ne pose pas de problème sur un serveur sans interface graphique, mais la situation se complique sur un ordinateur portable ou un ordinateur de bureau où l'hôte et la machine virtuelle sont censés partager le même écran et la même session.

De plus, de nombreuses configurations de transfert direct conçues pour les jeux ou la CAO nécessitent un moniteur physiquement connecté à la sortie GPU attribuée à la machine virtuelle. Cela implique de changer de source sur le moniteur ou d'utiliser deux écrans, ce qui va à l'encontre du principe d'une expérience visuelle « fusionnée » entre l'hôte et la machine virtuelle.

Des projets comme Looking Glass permettent de capturer le framebuffer de la machine virtuelle (avec un GPU dédié) et de l'afficher sur le bureau hôte sans changer physiquement d'écran. Cependant, cette solution engendre davantage de dépendances, d'étapes de configuration et de risques de panne . Pour ceux qui recherchent une solution simple et intégrée à Debian ou à d'autres distributions, ce n'est pas toujours le choix idéal.

En résumé, le transfert direct du GPU classique est idéal lorsque la puissance graphique maximale est requise pour une machine virtuelle spécifique (édition 3D, IA, jeux, CAO) et que l'hôte n'a pas besoin d'utiliser ce GPU pour sa propre interface. Cependant, pour plusieurs postes de travail partageant le même écran, son utilité est plus limitée, à moins d'accepter des compromis en termes d'ergonomie.

SR-IOV, vGPU et GPU partagé matériel : comment ils fonctionnent et quelles sont leurs limitations ?

Contrairement au modèle « un GPU par VM », les technologies de GPU partagé matériel (vGPU) permettent de diviser un seul appareil physique en plusieurs instances virtuelles, de sorte que chaque VM bénéficie d'une part dédiée de la puissance graphique sans avoir à payer pour un GPU par invité.

Au sein de cette catégorie, on retrouve plusieurs familles : NVIDIA vGPU/GRID (RTX vWS, etc.) , AMD MxGPU , Intel GVT-g et, plus généralement, la virtualisation basée sur SR-IOV. Dans tous ces cas, l’objectif est de transmettre les commandes graphiques de chaque machine virtuelle aussi directement que possible au GPU, évitant ainsi une traduction coûteuse par l’hyperviseur et améliorant les performances par rapport à l’émulation graphique ou à la paravirtualisation classiques.

La théorie semble parfaite, mais en pratique, il existe plusieurs nuances importantes :

• Il ne s'agit pas d'une technologie «magique» ou totalement transparente. La machine virtuelle sait toujours qu'elle communique avec un périphérique spécial, nécessite des pilotes spécifiques et présente des restrictions concernant les migrations à chaud, les instantanés et la gestion dynamique de la mémoire.
• De nombreuses solutions vGPU, notamment dans le cas de NVIDIA et AMD, Elles sont liées à des cartes professionnelles très coûteuses., avec des licences supplémentaires et, parfois, des modèles d'abonnement peu attrayants pour une utilisation à domicile ou dans de petits environnements sur site.
• Le support officiel se concentre généralement sur les hyperviseurs et les systèmes d'exploitation certifiés (vSphere, Citrix Hypervisor, RHEL, etc.), notamment dans les distributions comme Debian. Il pourrait y avoir plus de frictions et moins de documentation..

En résumé, SR-IOV et vGPU améliorent clairement les performances graphiques par rapport à Virtio/VirGL, mais ils ne rendent pas la virtualisation indiscernable du matériel nu et nécessitent de composer avec des limitations techniques et économiques qu'il convient de prendre en compte avant le lancement.

Intel GVT-g / KVMGT, Proxmox et accélération pour ordinateurs de bureau légers

Dans le domaine des GPU intégrés, notamment ceux d'Intel, l'une des technologies les plus intéressantes est Intel GVT-g (également appelé KVMGT) . Son objectif est précisément de permettre à plusieurs machines virtuelles de partager le GPU intégré du processeur, chacune disposant de sa propre « tranche » accélérée, au lieu de devoir passer exclusivement par une seule machine virtuelle.

Pour des usages tels que la navigation web, les applications bureautiques, les environnements de développement intégrés (IDE) et les applications 2D/3D légères, GVT-g peut constituer une amélioration significative par rapport aux graphismes Virtio de base , en réduisant le décalage lors du déplacement de fenêtres ou de l'ouverture de menus, et en fournissant une accélération matérielle pour certaines opérations qui autrement reposeraient entièrement sur le processeur.

Cependant, la configuration manuelle sur une installation KVM/QEMU nue sous Linux peut s'avérer fastidieuse : il faut modifier la configuration IOMMU, charger des modules spécifiques, définir les types de périphériques vGPU, etc. Des environnements comme Proxmox VE simplifient ce processus en proposant des assistants via l'interface web pour configurer le PCI passthrough et les GPU virtuels (tels que Intel KVMGT) sans avoir à manipuler des fichiers de bas niveau.

Il convient de clarifier plusieurs points concernant ce que l'on peut réellement attendre de GVT-g :

• L'amélioration graphique existe, mais elle ne fait pas de miracles. Pour les tâches bureautiques classiques ne nécessitant pas de lourdes charges de travail 3D, le gain d'expérience est généralement suffisant pour que la machine virtuelle se rapproche davantage d'un ordinateur physique modeste, mais ce n'est pas une solution pour les jeux exigeants ou le rendu 3D intensif.
• Il ne se « connecte » pas comme par magie à l'hyperviseur. Le noyau, le GPU intégré et l'hyperviseur doivent prendre en charge cette technologie, et bien que Proxmox l'expose mieux qu'une installation manuelle, il existe toujours des exigences matérielles et de version.
• Toutes les plateformes iGPU ou Intel ne le prennent pas en charge de la même manière. Ces dernières années, la virtualisation graphique a été réorientée, et une partie de l'attention s'est portée sur les produits mobiles ou de centres de données.

Par conséquent, si vous possédez un processeur Intel compatible et que vous souhaitez améliorer les performances sans passer par le monde des GPU professionnels, GVT-g dans un environnement comme Proxmox est une option raisonnable pour améliorer l'expérience sur les ordinateurs de bureau légers au sein de machines virtuelles.

SR-IOV dans les GPU modernes : ce qu’il apporte et pourquoi il n’est pas une solution miracle

SR-IOV est une extension PCI Express qui permet d'exposer un périphérique physique sous forme de plusieurs fonctions virtuelles, chacune pouvant être assignée à une machine virtuelle. Ce concept, bien établi pour les cartes réseau, a également été appliqué à certains GPU modernes, permettant ainsi à un seul GPU de fournir plusieurs instances de vGPU avec une isolation satisfaisante.

Dans le domaine des cartes graphiques intégrées, l'une des plateformes qui a suscité le plus d'intérêt est Intel Lunar Lake avec processeur graphique Xe2 , qui prend en charge, sur certains modèles, la technologie SR-IOV sur le GPU intégré. En théorie, cela permettrait à plusieurs machines virtuelles Linux ou Windows d'accéder à des performances graphiques accélérées quasi natives, avec une meilleure allocation des ressources que les solutions purement logicielles.

Toutefois, se fier uniquement à SR-IOV pour décider des achats de matériel est risqué pour plusieurs raisons :

• La prise en charge réelle de SR-IOV sur les GPU reste très inégale. Cela varie selon les fabricants et les modèles. Chez Intel, certaines cartes graphiques intégrées pour ordinateurs portables proposent cette fonctionnalité, contrairement aux cartes graphiques dédiées Xe2 pour ordinateurs de bureau. Quant aux gammes Flex pour centres de données, elles ciblent un segment différent et affichent des prix bien plus élevés.
• SR-IOV Cela nécessite toujours des conducteurs et un entretien spécifiques.Cela n'est pas transparent pour les machines virtuelles, et des incompatibilités peuvent survenir avec certaines versions du noyau ou de l'hyperviseur.
• L'expérience pratique montre que, bien que Amélioration de la latence et du nombre d'images par seconde, Les frais généraux liés à la virtualisation ne sont pas complètement éliminés.Les autres goulots d'étranglement (processeur, mémoire, disque, réseau) ne se résolvent pas d'eux-mêmes.

En d'autres termes, SR-IOV est utile, mais ce n'est pas une solution miracle qui transforme n'importe quelle machine virtuelle en un clone parfait de l'hôte . De plus, compte tenu de l'état actuel du marché, se concentrer uniquement sur la recherche d'un ordinateur portable équipé d'un processeur Mobile Xe2 pour cette seule fonctionnalité pourrait s'avérer inutile si vous n'avez pas de charges de travail graphiques particulièrement exigeantes.

Serveurs physiques versus environnements virtualisés : impact global sur le processeur, la RAM et le disque

Au-delà du GPU, il est également important de comprendre comment le CPU, la mémoire et le stockage se comportent dans un environnement virtualisé par rapport à un serveur physique, car un goulot d'étranglement dans l'une de ces ressources peut aggraver la sensation de « machine virtuelle lente », même si le composant graphique n'est pas le problème principal.

De manière générale, un serveur physique offre les performances les plus élevées , car le système d'exploitation communique directement avec le matériel, sans passer par un hyperviseur. En revanche, avec la virtualisation (KVM, Proxmox, VMware, Hyper-V, etc.), l'hyperviseur doit gérer l'accès de plusieurs machines virtuelles aux mêmes ressources physiques, ce qui engendre une charge de gestion supplémentaire.

Les indicateurs de performance typiques montrent que :

• La Processeur dans la machine virtuelle Ses performances sont généralement inférieures de 5 à 8 % à celles obtenues sur un système bare metal, selon l'hyperviseur.
• La RAM Elle perd une partie de sa bande passante effective (de l'ordre de 7 à 13 %), en raison de la traduction d'adresses et de la comptabilisation de la mémoire interne.
• El disque Vous pourriez constater une réduction de 15 à 25 % des IOPS, en particulier lorsqu'il existe plusieurs couches superposées (stockage distant, mise en cache, etc.).

Cette pénalité, bien que gérable, doit être prise en compte lors de l'évaluation visant à déterminer si une application avec des exigences de latence très faibles (par exemple, des bases de données hautes performances ou des moteurs de jeux en temps réel) est mieux maintenue sur des serveurs physiques dédiés ou peut être facilement déplacée vers des machines virtuelles sans en subir les conséquences.

De même, dans les charges de travail gourmandes en GPU (IA, rendu 3D, CAO), un environnement bare metal avec des GPU dédiés conservera toujours un léger avantage sur la virtualisation, même avec vGPU et passthrough, simplement parce qu'il évite toute la comptabilisation supplémentaire effectuée par l'hyperviseur.

Quels types de charges de travail fonctionnent le mieux dans des environnements physiques et lesquels dans des machines virtuelles ?

Toutes les applications ne fonctionnent pas de la même manière dans une machine virtuelle. Certaines s'adaptent parfaitement à la virtualisation, tandis que d'autres continuent de fonctionner mieux sur un serveur physique. Comprendre cette distinction est essentiel pour déterminer où il est judicieux d'investir dans des GPU, des CPU ou les deux.

Voici quelques exemples de situations où un serveur physique dédié est généralement l'option privilégiée :

• Bases de données hautes performances (Oracle, SAP HANA, SQL Server Enterprise) qui dépendent d'une latence minimale et de milliers d'IOPS constants.
• Applications de rendu et de calcul haute performance (Blender, AutoCAD, charges de travail importantes en IA/ML) où le GPU et le sous-système disque fonctionnent à leur limite.
• Serveurs de jeu ou streaming en temps réeloù une faible latence et une réponse constante font toute la différence.

En revanche, la virtualisation excelle avec les applications qui tirent parti de la flexibilité, de l'évolutivité et d'une gestion centralisée , telles que :

• Serveurs Web, microservices et API (Nginx, Apache, Kubernetes) qui correspondent bien à la logique de mise à l'échelle horizontale avec plusieurs machines virtuelles ou conteneurs.
• Bureaux virtuels et VDI (Windows 365, Citrix, etc.), où l'isolation et l'administration centralisée priment sur le nombre maximal d'images par seconde.
• Plateformes de développement et de test (Jenkins, GitLab Runners, bancs d'essai éphémères) qui nécessitent un clonage rapide, des instantanés et une facilité de restauration.

Dans le cas particulier des postes de travail Linux ou Windows utilisés pour la navigation web, les applications bureautiques et la programmation sur un hyperviseur comme KVM ou Proxmox, la virtualisation est parfaitement viable . L'essentiel est de dimensionner correctement le processeur, la RAM et l'espace disque, et d'utiliser la meilleure option graphique disponible pour le matériel (Virtio-GPU avec une bonne configuration, GVT-g si un GPU Intel compatible est disponible, ou même le passthrough/vGPU lorsque cela est pertinent).

Processeur, mémoire et disque : leur impact sur l’expérience graphique dans la machine virtuelle

Souvent, tout le « décalage » d'une machine virtuelle est attribué à la carte graphique, mais dans de nombreux cas, des problèmes préalables de surcharge du processeur, de la mémoire ou du disque entraînent une interface maladroite, indépendamment du GPU.

Si la machine virtuelle ne dispose pas d'un nombre suffisant de vCPU ou si le processeur physique est surchargé (surallocation vCPU:pCPU très élevée), l'hyperviseur ne peut pas planifier les processus de la machine virtuelle à temps. Des indicateurs comme « CPU Ready » dans VMware ou des compteurs équivalents dans KVM/Proxmox permettent de détecter ce problème : si le cœur virtuel passe trop de temps à attendre son tour (plus de 10 % de l'intervalle), la machine virtuelle devient lente même si le GPU est sous-utilisé.

Un phénomène similaire se produit avec la mémoire. Si la RAM allouée à la machine virtuelle est insuffisante, le système invité utilisera la mémoire d'échange (swap), et chaque changement de fenêtre entraînera des lectures et écritures sur disque . Si la mémoire est surdimensionnée sur l'hôte et que celui-ci recourt également à la mémoire d'échange, le système hôte et les machines virtuelles seront pénalisés. Il est donc crucial d'éviter toute surallocation de mémoire excessive en production.

En matière de stockage, un sous-système disque présentant une latence élevée et un faible nombre d'IOPS disponibles entraînera des temps de chargement d'applications extrêmement longs, des temps de démarrage importants et des blocages fréquents lors de l'écriture de fichiers temporaires. Les machines virtuelles dont les disques sont stockés sur des disques durs lents ou dans des baies de stockage surchargées seront bien plus pénalisées par la virtualisation.

Enfin, l'accumulation d'instantanés de disque (par exemple, plusieurs VMDK delta chaînés dans VMware) engendre une surcharge de lecture/écriture, car les données sont réparties sur plusieurs fichiers. Conserver d'anciens instantanés pendant une période prolongée est un moyen sûr de dégrader les performances de toutes les machines virtuelles concernées.

Meilleures pratiques pour améliorer les performances graphiques (et globales) des machines virtuelles

Pour tirer le meilleur parti du matériel disponible et rapprocher l'expérience de la machine virtuelle de celle d'un ordinateur physique convenable, il convient de prendre en compte plusieurs recommandations pratiques :

• Processeur et mémoire de taille appropriée. Veillez à ne pas manquer de vCPU ou de RAM, mais n'augmentez pas non plus le nombre de cœurs et de mémoire « au cas où ». Les machines virtuelles dotées d'un trop grand nombre de vCPU peuvent engendrer des problèmes de co-arrêt et de planification, ce qui dégrade les performances au lieu de les améliorer.
• Utilisez le stockage rapide. Les disques SSD, NVMe ou le stockage réseau avec un nombre d'IOPS suffisant réduisent considérablement les temps de démarrage et de chargement des applications, ce qui rend le bureau plus fluide.
• Maintenez vos pilotes et outils d'intégration à jour. Sur les hyperviseurs commerciaux, l'installation de VMware Tools, des pilotes vGPU et de logiciels similaires améliore la gestion de la souris, les résolutions dynamiques et l'accélération graphique. Sur KVM/Proxmox, l'utilisation des pilotes Virtio et des agents invités optimise la communication entre l'hôte et la machine virtuelle.
• Évitez les couches de virtualisation redondantes. L'exécution de KVM à l'intérieur d'un autre hyperviseur (ou de VMware sur Hyper-V, etc.) introduit une surcharge supplémentaire et peut réduire considérablement les performances.

Il est également conseillé de surveiller les ressources depuis l'hôte, et pas seulement depuis la machine virtuelle. Des outils comme esxtop dans ESXi, les tableaux de bord avancés de vCenter ou les métriques de Proxmox et RHEL pour KVM permettent de visualiser la consommation de ressources (CPU, RAM, disque et réseau) de chaque machine virtuelle et de détecter les machines virtuelles « polluantes » qui dégradent l'expérience des autres.

Globalement, les performances graphiques des machines virtuelles modernes résultent de la combinaison de nombreux éléments : du choix entre les technologies Virtio-GPU, VirGL, le transfert direct ou les technologies vGPU comme SR-IOV ou Intel GVT-g, au type de stockage, à la surallocation du processeur et de la mémoire, et à la qualité du réseau sous-jacent. Lorsque tous ces paramètres sont correctement paramétrés, les machines virtuelles peuvent offrir une expérience utilisateur très proche de celle d'une machine physique pour la plupart des usages courants , réservant les serveurs physiques et les GPU dédiés aux charges de travail exceptionnelles où chaque milliseconde et chaque image par seconde comptent.

Article connexe:

Machines virtuelles prêtes pour la production ? Stabilité, performances et quand les choisir ?

Isaac

Écrivain passionné par le monde des octets et de la technologie en général. J'aime partager mes connaissances à travers l'écriture, et c'est ce que je vais faire dans ce blog, vous montrer toutes les choses les plus intéressantes sur les gadgets, les logiciels, le matériel, les tendances technologiques et plus encore. Mon objectif est de vous aider à naviguer dans le monde numérique de manière simple et divertissante.