Critères considérés pour la présélection des hyperviseurs

Moyens techniques d’aide à la virtualisation

Dans cette section, nous présentons les différentes technologies de virtualisation dévelop-pées par les entreprises majeure du domaine : Intel et AMD. Intel Virtualization Technol-ogy (VT) est une famille de technologies supportant la virtualisation pour des plateformes Intel IA-32, Xeon et Itanium. Cela comprend des éléments pour le processeur, la mémoire et la virtualisation d’entrées/sorties. AMD-V offre des supports comparables pour le pro-cesseur, la mémoire et la virtualisation d’entrées/sorties. Pour ces différents composants nous détaillerons brièvement les technologies utilisées.

Virtualisation CPU

Le chipset 80286 d’Intel a été le premier de la gamme des architectures processeurs x86 à fournir deux principales méthodes d’adressage de la mémoire : un mode dit « réel » et un mode « protégé ». Un troisième mode dit « virtuel » permet plusieurs utilisations du mode « réel » en simultané. Le mode « réel » est rapidement devenu obsolète du fait de ses limitations : seulement 1Mo de mémoire peut être adressé et une seule application peut être exécutée à la fois. Le mode « virtuel » est également peu utilisé du fait de son adressage mémoire sur 16 bit et l’utilisation croissante de processeurs 32 voire 64 bits.
Le mode protégé comprend quatre niveaux de privilèges détaillés dans le Figure IV.4. Le niveau 0 (au centre de la figure) est le plus privilégié et est utilisé pour les segments de code les plus critiques d’un système, généralement le noyau d’un système d’exploitation. Les autres niveaux, avec progressivement moins de privilèges, sont utilisés par des segments de code moins critiques. Par exemple, les applications sont généralement exécutées au niveau 3. Bien que l’emploi de ces niveaux de privilèges soient conseillés par Intel, ils ne sont pas tous utilisés. En effet un système d’exploitation tel que Linux utilise seulement deux niveaux : le niveau 0 pour le noyau du système d’exploitation et le niveau 3 pour les applications.
Intel VT est connu sous le nom de VT-x pour les plateformes IA-32 et Xeon tandis qu’il prend le nom de VT-i pour la plateforme Itanium. La technologie VT-x ajoute deux nouveaux modes d’exécution au processeur, VMX root et VMX non-root. L’hyperviseur s’exécute en mode VMX root alors que les machines virtuelles s’exécutent en mode VMX non-root. Ces deux modes supportent les quatre niveaux de privilèges présentés dans le paragraphe précédent et permettent ainsi à l’hyperviseur une plus grande flexibilité pour le choix de privilèges à accorder à une machine virtuelle.
La transition entre ces deux modes est assurée par deux nouvelles instructions : VM entry qui assure la transition entre les modes VMX root et VMX non–root, et VM exit qui assure la transition entre les modes VMX non-root et VMX root. Ces instructions sont gérées par une nouvelle structure de données nommée virtual-machine control structure (VMCS).
AMD-v introduit également un mode d’exécution additionnel nommé « mode invité » qui est analogue au mode non-root d’Intel VT-x. L’accès au mode invité se fait par l’inter-médiaire de l’instruction VMRUN. Lorsque l’instruction VMRUN est appelée par une machine virtuelle, l’accès au matériel est assuré par une structure de données nommée Virtual Machine Control Block (VMCB) correspondant à cette machine virtuelle. Cette structure enregistre les informations relatives aux événements et interruptions pouvant être interceptés par l’hyperviseur pour cette machine virtuelle.
Ces différentes technologies que sont Intel VT-x et AMD-v introduisent des extensions aux modes d’exécution existants.

Virtualisation mémoire

Les processeurs Intel x86 utilisent une table de pages afin de faire correspondre les adresses mémoires virtuelles aux adresses physiques, ces tables sont gérées par la Memory Management Unit (MMU) et sont principalement mises en cache dans le Translation Lookkaside Buffer (TLB). Les OS invités utilisent les tables de pages des MMU émulées. Ces tables permettent au système invité d’avoir l’illusion d’assurer la correspondance entre les adresses virtuelles et les adresses physiques, or c’est l’hyperviseur qui réalise cette opération.
Un autre type d’adresse mémoire, nommé « pseudo-physique », est utilisé afin d’as-surer le bon fonctionnement de la traduction. Le système d’exploitation invité assure la traduction entre les adresses virtuelles et les adresses « pseudo-physiques » tandis que l’hy-perviseur maintient séparément des tables de traduction dites fantômes afin d’assurer la traduction des adresses pseudo-physiques en adresses physiques. Cependant, cette utilisa-tion pose un problème de performance, car à chaque mise à jour des tables de page d’un système invité l’hyperviseur doit mettre à jour les pages fantômes.
Des mécanismes tel que les Nested Page Tables (NPT) d’AMD ou les Extended Page Tables (EPT) d’Intel permettent de palier ce problème de performance.
En effet, en utilisant un mécanisme de pagination imbriqué, le processeur enregistre à la fois l’adresse mémoire virtuelle et l’adresse physique de l’OS invité comme respectivement, adresse physique invitée et adresse physique réelle au sein du TLB. L’utilisation de l’identifieur d’adresse, Address Space Identifier (ASID), assure la correspondance entre les entrées du TLB et les machines virtuelles associées. De cette manière, des entrées de différentes machines virtuelles peuvent coexister au sein du TLB au même moment. Le processeur, par ce mécanisme, n’a plus qu’à synchroniser le TLB après chaque modification des pages de tables des OS invités.

Virtualisation d’entrées/sorties

La famille Intel VT comprend également un composant nommé Vt-d pour la virtu-alisation d’entrées/sorties. Ce composant permet par exemple d’allouer un périphérique à une seule machine virtuelle. L’accès au périphérique se fait sans contrôle de la part de l’hyperviseur.

Évaluation des performances d’un hyperviseur

L’évaluation d’hyperviseur a été le sujet de nombreuses études. Certaines études com-parent les hyperviseurs entre eux alors que d’autres s’intéressent de façon plus indirecte aux différences de performance entre une application s’exécutant sur un hyperviseur et cette même application s’exécutant sur un système d’exploitation classique.
Dans cette section, nous décrivons différentes études afin de présenter les méthodes d’évaluations utilisées et de mettre en évidence l’innovation apportée par notre méthode d’évaluation.
Les auteurs de [Xu et al. 2008] comparent la dégradation du temps d’exécution d’une application entre une machine physique exécutant un système d’exploitation non virtualisé et différentes solutions de virtualisation. Le logiciel Ubench [PhysTech 2005] est utilisé pour effectuer les mesures. La machine physique sert de référence afin d’évaluer les différences entre les hyperviseurs considérés.
Dans [McDougall & Anderson 2010], différentes techniques de virtualisation sont com-parées en utilisant également comme référence un système d’exploitation non virtualisé. Dans cette étude, le logiciel VMark [Herndon et al. 2006] est utilisé pour évaluer les per-formances. Le logiciel NAS [Jin et al. 1999] est choisi dans [Bhukya et al. 2010] afin de comparer l’hyperviseur Xen et une solution issue de VMware [Walters 1999]. L’auteur examine en particulier l’influence du nombre de processeurs assignés à l’hyperviseur.
Dans [Umeno et al. 2006], les auteurs comparent les performances d’une configuration avec et sans utilisation de la virtualisation. Ils s’intéressent plus particulièrement aux per-formances processeurs, mémoires et réseaux. Pour ce faire ils utilisent l’algorithme de calcul BYTEMark [Seungkwon & Youngil 2007] pour mesurer le taux de charge des processeurs, le logiciel LMbench [McVoy & Staelin 1996] permet d’estimer le taux de transfert mémoire tandis que le logiciel Iozone mesure la bande passante réseau. Les résultats obtenus leur permettent d’évaluer la stabilisation du serveur en utilisant des machines virtuelles.
Le logiciel RandomWriter et l’algorithme Sort [TASF 2007] sont utilisés dans [Kon-tagora & Gonzalez-Velez 2010] afin d’évaluer un réseau de machines virtuelles. Ce réseau est composé de dix-sept machines physiques. Chaque machine exécute VMWare Worksta-tion pour fournir un système d’exploitation virtualisé. Une machine physique est définie comme maître ; les seize autres sont utilisées dans différentes configurations.
La précision des mesures de performances dépend de la manière dont le temps est mesuré. Dans les études précédemment décrites, le temps d’exécution est basé sur le logi-ciel. Par exemple dans [Kontagora & Gonzalez-Velez 2010] la commande Unix « top » est utilisée. La précision logicielle est effectivement adéquate pour comparer des hyperviseurs entre eux ou avec des systèmes non virtualisés. Cependant, cette précision n’est pas probante pour comparer une machine virtuelle avec un hyperviseur ou un système non virtualisé. En effet, comme le montre la Figure IV.5 un hyperviseur peut modifier l’hor-loge de la machine virtuelle pour masquer le fait qu’elle est virtualisée.
De plus, afin d’évaluer précisément le temps d’exécution sur machine virtuelle, une commande logicielle telle que « time » n’est pas fiable à cause du comportement de l’hy-perviseur.
Figure IV.5 – Exemple de mesure du temps d’exécution par outil logiciel
Un exemple de mesure utilisant la commande time est donné par la Figure IV.5. Lors de cette expérimentation nous avons utilisé le programme « superpi » qui calcule le chiffre π sur plusieurs décimales. Notre configuration utilise l’hyperviseur Xen avec une machine virtuelle exécutant un système d’exploitation fedora 13. La commande time renvoie trois temps d’exécution :
le temps système est le temps passé par le processus dans l’espace noyau décrit à la Section IV.1.2, le temps utilisateur, qui correspond au temps passé dans l’espace utilisateur et le temps total qui correspond à la somme de ces deux temps.
Or, nous remarquons un comportement aberrant. En effet, le temps que passe le pro-cessus dans l’espace utilisateur est supérieur au temps total. Ce comportement peut s’-expliquer par le fait que l’outil logiciel utilisé n’a pas été spécifiquement développé pour une utilisation sur une machine virtuelle. Par conséquent, la prise en charge des différentes couches de virtualisation mise en jeu peut altérer les mesures.
De plus, de nombreuses horloges sont présentes dans un ordinateur et différents hyperviseurs peuvent utiliser les horloges de leur choix. Afin de connaitre l’horloge utilisée, un accès au code source de l’hyperviseur doit être fait, tous ne sont pas librement accessibles.
Par conséquent, nous avons besoin d’une nouvelle méthode de mesure du temps d’exé-cution qui doit être aussi indépendante que possible de la cible logicielle visée. La suite de cette section présente notre deuxième contribution [Lastera et al. 2011], qui implémente une telle approche.