Performances des hyperviseurs

Le nombre maximal d'opérations à virgules flottantes sur un système Fedora 8 virtualisé avec KVM est environ 83,46 % égale à la version native, environ 97,28 % avec Xen. Cela suggère que l'efficacité du traitement de KVM sur les nombres à virgules flottantes n'est pas aussi bon que Xen. KVM doit vérifier si chaque instruction d'exécution est une interruption, un défaut de page, entrée/sortie ou une instruction commune et décider de quitter ou de rester en mode invité, cette décision gaspille beaucoup de temps. Au contraire, Xen permet aux systèmes invités d'exécuter des instructions de calcul avec virgule flottante sur le processeur hôte pour gagner du temps de résolution[3]. KVM, qui permet l'utilisation de partition physique de l'hôte, offre des performances native pour la lecture des données, mais n'est capable d'atteindre que 62 % des performances natives pour l'écriture [4].

Walters et al. ont testé les performances et la capacité d'évolution de VMWare Server, Xen et OpenVZ pour des applications distribuées HPC. Leurs travaux portent sur des tests de transmission sur le réseau, et sur le comportement du système de fichier. Leurs résultats montrent que Xen surpasse OpenVZ et VMWare Server en utilisation de la bande passante, Xen est capable d'utiliser 94,5 % de la bande passante du système hôte [5].

Les résultats sur les systèmes de fichiers montrent qu'OpenVZ a des performances très proches d'un système natif, avec des performances de 90 % d'un système natif dans le pire des cas (opérations sur des fichiers de 32 Mo). Les systèmes invités d'OpenVZ résident dans le système de l'hôte comme des répertoires de fichiers. Xen, qui utilise la gestion par volumes logiques (LVM) pour le stockage d'invité, présente des performances plus faibles avec des surcharges de 46 % en lecture et 40 % en écriture [6]. KVM, qui permet l'utilisation de partition physique de l'hôte, offre les performances du système hôte pour la lecture des données, mais n'est capable d'atteindre que 62 % des performances par rapport à un système natif pour l'écriture [4].

Les hyperviseurs ont besoin d'isoler les interruptions et les accès à la mémoire. C'est très coûteux quant aux performances, auparavant cette opération était réalisée par un mécanisme de translation de code. Depuis quelques années, les fabricants de processeurs ont ajouté des instructions spécialisées (Intel VT-x / EPT et AMD-V / RVI) afin de permettre la virtualisation assistée par le matériel. KVM + QEMU et VirtualBox, utilisent ces instructions. Le procédé impose à l'hyperviseur d'exposer explicitement les extensions de virtualisation du jeu d'instructions au système d'exploitation invité sous-jacent [2].

Les surcoûts quant aux performances pour virtualiser un système comportent trois aspects principaux : la virtualisation du processeur, de la mémoire et des entrées/sorties. Les hyperviseurs très performants tels que Xen et VMware sont en mesure de réaliser la virtualisation du processeur et de la mémoire avec très peu de ressources [7].

L'utilisation d'un hyperviseur au-dessous du système d'exploitation diffère du schéma habituel où le système d'exploitation est l'entité la plus privilégiée dans le système. Afin de protéger l'hyperviseur de débordements du système d'exploitation invité et des domaines les uns sur les autres, les OS invités doivent être modifiés pour fonctionner à un niveau de privilège inférieur [8].

De nombreuses architectures de processeur ne fournissent que deux niveaux de privilèges. Dans une virtualisation efficace, des niveaux de privilèges supplémentaires sont disponibles sur x86, car il prend en charge quatre niveaux de privilèges distincts dans le matériel [8].

L'utilisation du processeur a des implications critiques sur les performances des autres caractéristiques du système, à savoir sur la consommation d'énergie. L'implication ne se limite pas au cas où le processeur fonctionne à 100 %. Plus la charge du processeur augmente, plus la consommation de ce dernier est importante [9].

Dans l'évaluation des performances d'une machine virtuelle, les processus sont gérés par la machine virtuelle à la place du système d'exploitation sous-jacent. Les threads émulés des environnements multi-thread, en dehors des capacités du système d'exploitation d'origine, sont gérés dans l'espace utilisateur à la place de l'espace noyau, permettant le travail avec des environnements sans support natif des threads [10].

De bonnes performances sur un microprocesseur multi-cœur sont obtenues grâce à l'implémentation de threads natifs pouvant attribuer automatiquement le travail à plusieurs processeurs, ils permettent un démarrage plus rapide de processus sur certaines machines virtuelles. Un thread a la possibilité de bloquer les autres threads pour effectuer une opération d'entrée/sortie. Pour éviter le problème, les threads doivent utiliser des opérations d'entrée/sortie asynchrones. La complexité accrue peut être cachée par la mise en œuvre de processus d'entrée/sortie séparés natifs qui coopèrent avec les threads [10].

La mémoire virtuelle est la partie la plus difficile à créer avec la paravirtualisation :

L'architecture X86 ne possède pas de gestion logicielle du TLB (mémoire cache du processeur); lorsque la place manque, les TLB sont nettoyées automatiquement par le processeur en ré-écrivant sur la structure de la table de pages. Pour obtenir la meilleure performance possible, toutes les traductions de page valides pour l'espace de l'adresse actuelle doivent être présents dans la table de pages [11].

La virtualisation des entrées/sorties par un hyperviseur pose un problème complexe. Les périphériques d'entrée/sortie sont généralement partagés entre toutes les machines virtuelles dans une machine physique, l'hyperviseur doit vérifier que les accès des périphériques sont légaux cela nécessite que l'hyperviseur ou un domaine privilégié doit intervenir sur tous les accès d'entrée/sortie du client de machine virtuelle. L'intervention conduit à plus de latence aux entrées/sorties et plus de ressources CPU en raison de changements de contexte entre les machines virtuelles invitées et l'hyperviseur [7].

Les machines virtuelles hébergent un système d'exploitation, des applications, des services et éventuellement des données. Elles exigent une grande place de stockage sur le disque. Une quantité importante de l'activité d'entrée/sortie est réservée pour garder plusieurs machines virtuelles vivantes sur un seul serveur. Les applications nécessitant une grande quantité d'entrée/sortie, comme les serveurs de base de données, pourraient faire face à d'importants ralentissements si les sous-systèmes d'entrée/sortie ne sont pas en mesure de faire face à la charge accrue. Le stockage est une ressource clé pour un environnement virtualisé. Après tout, une machine virtuelle est techniquement un ensemble de fichiers qui peut contenir un système d'exploitation avec ses applications installées [10].