Utilisateur:Jeanserge monbailly/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

L'architecture d'un hyperviseur englobe l'ensemble des mécanismes implémentés afin de permettre la virtualisation d'un système.

Categories d'hyperviseur[modifier | modifier le code]

Catégorie des hyperviseurs
Catégorie des hyperviseurs

Architecture native[modifier | modifier le code]

Les hyperviseurs natifs (type 1) sont directement intégrés au système d'exploitation de la machine hôte.

Dans cette approche, l'hyperviseur communique directement avec le matériel sur lequel il est executé. Il est également en mesure d'intercepter les entrées/sorties et d'en abstraire l'exécution pour le système d'exploitation invité.[1]

Une architecture native fournie une virtualisation du matériel aux machines virtuelles. En effet, ces dernières interagissent avec des périphériques virtuels via des pilotes fournis par l'hyperviseur.[1]

Architecture invitée[modifier | modifier le code]

Les hyperviseurs invités (type 2) sont exécutés au sein même d'un autre système d'exploitation[1], de ce fait ils n'ont qu'un accès limité aux ressources de la machine hôte, il est donc possible d'exécuter plusieurs hyperviseurs de ce type sur une même machine.

L'hyperviseur fournit une virtualisation du materiel au système invité,[1] Quand le système invité tente d'exécuter une instruction privilégiée, l'hyperviseur a pour mission de vérifier leur cohérence avant de les exécuter à son tour sur le système d’exploitation.[1]

Méthodes de virtualisation[modifier | modifier le code]

Virtualisation Complète[modifier | modifier le code]

Dans le cas d'une virtualisation complète, le système invité ignore se trouver dans un environnement virtualisé. L'hyperviseur fourni une virtualisation de l'architecture et des ressources nécessaire à l’exécution du système invité, impliquant qu'il n'est pas nécessaire de modifier ce dernier. [2]

Dans ce cas, les périphériques d'entrée/sortie utilisés par les machines virtuelles ne sont que des abstractions des périphériques physiques générées par l'hyperviseur. Toute interaction avec ces périphériques virtuels est redirigée directement vers les périphériques physiques[3]. De ce fait, ce type de virtualisation offre la meilleure solution en terme de performances, d'isolation et de sécurité des machines virtuelles. De plus, cette méthode simplifie la portabilité et la migrations de machines virtuelles.[2]

Dans ce modéle, l'hyperviseur est exécuté avec un niveau de privilége 0 (ring 0). A contrario, les machines virtuelles sont exécutées avec un niveau de privilége 1 (ring 1). Ce niveau de droit permet d'assurer lisolation des machines virtuelles en leur empêchant d'exécuter directement des instructions sur le matériel, seules celles interceptées par l'hyperviseur pourront être exécutées. [4]

Virtualisation Partielle[modifier | modifier le code]

Dans un modèle de virtualisation partielle, le système invité doit être modifié afin de pouvoir fonctionner dans l'environnement virtuel. La machine virtuelle a donc conscience de se trouver dans un environnement virtualisé.[2][5]

Même si les machines virtuelles sont éxécutées avec un niveau de privilége 0 (droits d'accès limités), celles-ci sont tout de même gérées par l'hyperviseur qui lui dispose du niveau de privilège root(droits maximum).[6]

Les machines virtuelles n'ont accès qu'à des ressources virtualisées (cartes réseaux, disques durs). Ces ressources sont fournies par l'hyperviseur, qui est chargé d'intercepter les instructions transmises par les systèmes invités, et de les rediriger vers les périphériques physiques correspondant.[3][1] Dans cette situation, on dit que les systèmes invités utilisent des «Hypercalls», des demandes de ressources à l'hyperviseur.[5]

Mécanismes de l'hyperviseur[modifier | modifier le code]

Dans un système de machines virtuelle,s les ressources (mémoire, processeur, périphériques) sont gérées par l'hyperviseur. Chaque ressource de chaque machine virtuelle est géré via des algorithmes d'ordonnancement et de gestion fournis par l'hyperviseur.[2]

Ordonnancement[modifier | modifier le code]

L'hyperviseur est en charge d'allouer les ressources aux machines virtuelles. Pour se faire, il utilise des algorithmes d'ordonnancement visant à accorder un accès équitable aux ressources (notamment au temps CPU) pour les machines virtuelles.[7]

Les algorithmes suivant sont utilisés par des solutions de virtualisation :

  • Temps virtuel partagé (Borrowed Virtual Time) : Algorithme d'ordonnancement équitable basé sur un temps virtuel, fournissant les ressources aux différentes machines virtuelles chacune à leur tour.[8]
  • The Simple Earliest Deadline First : Algorithme en temps réel et préemptif. Chaque processus indique à l'hyperviseur le temps d'utilisation du processeur dont il a besoin sous la forme (avec la taille de chaque tranche de temps de periode ). Ainsi l'hyperviseur fourni au processus une fraction du temps d'utilisation du processeur demandé par chaque machine virtuelle.[9][10] Cela permet une répartition plus équitable du temps processeur accordé à chaque machine puisque les machines qui en ont le plus besoin auront droit à plus de temps de calcul que les autres.
  • The Credit Scheduling algorithm : Algorithme d'ordonnancement et de répartition de charge proposé par Xen[2] : à chaque machine virtuelle se voit assigné un poids et une casquette. Si la casquette est égale à 0, la machine virtuelle peut recevoir du temps CPU supplémentaire. Une valeur non nulle de la casquette (exprimée comme un pourcentage) détermine la limite maximum de temps CPU que peut recevoir une machine virtuelle.[11] [9]

Virtualisation des ressources mémoires[modifier | modifier le code]

Translation d'adresse grâce aux shadow page table
Translation d'adresses grâce aux shadow page table

Dans le cadre de la virtualisation de la mémoire, deux espaces d'adressage sont gérés :

  • Un espace d'adressage utilisé par l'hyperviseur, appelé «page table». Cet espace d'adressage est équivalent à celui présent sur un système d'exploitation standard.[1][5]
  • Un espace d'adressage utilisé par les machines virtuelle, appélé «shadow page table». Ce dernier est fourni par l'hyperviseur, qui se charge de traduire les adresse virtuelles du système invité vers les adresses virtuelles de sa «page table». [5] [1]

Lorsque le système invité effectue une demande d'accès mémoire, ce dernier utilise les adresse virtuelles de la «shadow page table». La TLB virtuelle reçoit cette requete qui la transmet à la MMU virtuelle. S'il existe une correspondance, l'adresse trouvée est transmise à la MMU de l'hyperviseur. Sinon une exception «Page Fault» est declenchée puis celle-ci est redirigée vers la MMU de l'hyperviseur. Sinon c'est l'adresse correspondante qui est redirigée vers la MMU de l'hyperviseur. La MMU de l'hyperviseur se charge de récupérer dans la «page table» l'adresse physique correspondante. Si l'adresse physique existe, la translation est effectuée et l'adresse physique est retourné vers la MMU de l'hyperviseur. Enfin, la machine virtuelle récupère l'adresse physique correspondant à l'adresse virtuelle dans la shadow page.[12][1][5]

Virtualisation des périphériques et des entrées/sortie[modifier | modifier le code]

Il existe de nombreux outils permettant la gestion de périphériques entre plusieurs machines virtuelles. En effet, les interfaces réseaux virtuelles et les commutateurs permettent de créer des réseaux virtuels et d'y associer les machines virtuelles corréspondante.[13]

De plus l'hyperviseur virtualise la couche matérielle et offre à chaque machine virtuelle un ensemble de périphériques virtuels standardisés afin de garantir la portabilité entre les architectures sur lesquelles l'hyperviseur serait exécuté.[13]

Implémentations existantes[modifier | modifier le code]

Xen[modifier | modifier le code]

Logo Xen
Xen

Xen est un hyperviseur natif très complet directement intégré au noyau linux de la machine hôte. Il offre à l'utilisateur le choix entre les 2 types de virtualisation et fournit ses propres mécanismes de gestion des ressources (ordonnanceur, gestionnaire de mémoire).[14][15]

Les machines virtuelles créées sont isolées au sein d'un espace d'entrées/sorties dédié. Afin de gérer les ressources allouées aux machines virtuelles, Xen limite les accès privilégiés au matériel ainsi que les vecteurs d'interruptions. De plus, Xen virtualise la configuration matérielle pour que les machines invitées puissent consulter les ressources disponibles pour lui sans pour autant leur permettre d'accèder au reste des ressources matérielles. [16]

Chaque page de la mémoire est détenue par au plus un domaine à la fois, et grâce à l'hyperviseur, il peut intéragir avec ces pages mémoires.[17][18] De plus, l'ordonnancement des taches sous Xen s'effectue grâce à l'algorithme «The Credit Scheduling algorithm [19]

Il existe plusieurs versions du noyau linux intégrant Xen nativement. Néanmoins, du fait de sa complexité, son intégration à un noyau linux existant peut poser de nombreux problèmes.[20] Dans le cas d'une intégration d'hyperviseur à un noyau existant, il sera conseillé d'opter pour une solution plus simple d'installation.

KVM[modifier | modifier le code]

KVM (Kernel based Virtual Machine) est un hyperviseur natif de virtualisation complète. Il est très léger (environ 10 000 lignes de codes) et est installé sous la forme d'un simple module linux ce qui le rend très simple d'installation et d'utilisation.[14][20]

KVM fait directement appel aux mécanismes de gestion des ressources intégré au noyau linux et considère les machines virtuelles comme de simples processus.[14][20]

Du fait du jeune âge du projet, KVM ne peut pas virtualiser toutes les architectures et il peut être intéressant d'opter pour un hyperviseur plus complet comme Xen.[14]

Références[modifier | modifier le code]

  1. a b c d e f g h et i Meghanathan 2012, p. 734
  2. a b c d et e Li 2010, p. 334
  3. a et b Zhang 2010, p. 117
  4. VMWare 2007, p. 4
  5. a b c d et e Palicherla 2015, p. 426
  6. VMWare 2007, p. 6
  7. Cherkasova2007 2007, p. 2-3
  8. Cherkasova 2007, p. 2
  9. a et b Cherkasova 2007, p. 3
  10. Li 2010, p. 334
  11. Hu 2010, p. 144
  12. Agesen 2010, p. 6-8
  13. a et b VMWare 2007, p. 7
  14. a b c et d Habib 2008, p. 1
  15. Barham 2003, p. 165
  16. Fraser 2004, p. 4
  17. Fraser 2004, p. 6
  18. Barham 2003, p. 166
  19. Ongaro 2008, p. 2
  20. a b et c YamunaDevi 2011, p. 2

Bibliographie[modifier | modifier le code]

  • (en) Yunfa Li, Wanqing Li et Congfeng Jiang, « A Survey of Virtual Machine System: Current Technology and Future Trends », Proceedings of the Third International Symposium on Electronic Commerce and Security (ISECS),‎ , p. 332-336 (DOI 10.1109/ISECS.2010.80, lire en ligne, consulté le )
  • (en) Binbin Zhang, « A Survey on I/O Virtualization and Optimization », ChinaGrid Conference (ChinaGrid), 2010 Fifth Annual,‎ , p. 117 - 123 (DOI 10.1109/ChinaGrid.2010.54)
  • (en) Irfan Habib, « Virtualization with KVM », Linux Journal,‎ (ISSN 1075-3583)
  • (en) L. YamunaDevi, P. Aruna, D.D. Sudha et N. Priya, « Security in Virtual Machine Live Migration for KVM », International Conference on Process Automation,‎ , p. 1-6 (DOI 10.1109, lire en ligne, consulté le )
  • (en) Keir Fraser, Steven H, Rolf Neugebauer et Ian Pratt, « Safe hardware access with the Xen virtual machine monitor », 1st Workshop on Operating System and Architectural Support for the on demand IT InfraStructure (OASIS),‎ (lire en ligne, consulté le )
  • (en) Natarajan Meghanathan, « Virtualization of Virtual Memory Address Space », Proceedings of the Second International Conference on Computational Science, Engineering and Information Technology, ACM, cCSEIT '12,‎ , p. 732–737 (ISBN 978-1-4503-1310-0, DOI 10.1145/2393216.2393338, lire en ligne, consulté le )
  • (en) Ludmila Cherkasova, Diwaker Gupta et Amin Vahdat, « When Virtual is Harder than Real: Resource Allocation Challenges in Virtual Machine Based IT Environments », Hewlett-Packard Development Company, L.P,‎ , p. 1-8 (lire en ligne)
  • (en) VMware, « Understanding Full Virtualization, Paravirtualization, and Hardware Assist », VMware white paper,‎ (lire en ligne)
  • (en) Paul Barham, Boris Dragovic, Keir Fraser et Steven Hand, « Xen and the Art of Virtualization », SIGOPS Proceedings of the nineteenth ACM symposium on Operating systems principles, ACM, sOSP '03,‎ , p. 164–177 (ISBN 1-58113-757-5, DOI 10.1145/945445.945462, lire en ligne, consulté le )
  • (en) Abhinand Palicherla, Tao Zhang et Donald E. Porter, « Teaching Virtualization by Building a Hypervisor », Proceedings of the 46th ACM Technical Symposium on Computer Science Education, ACM, sIGCSE '15,‎ , p. 424–429 (ISBN 978-1-4503-2966-8, DOI 10.1145/2676723.2677254, lire en ligne, consulté le )
  • (en) Yanyan Hu, Xiang Long, Jiong Zhang et Jun He, « I/O Scheduling Model of Virtual Machine Based on Multi-core Dynamic Partitioning », Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing, ACM, hPDC '10,‎ , p. 142–154 (ISBN 978-1-60558-942-8, DOI 10.1145/1851476.1851494, lire en ligne, consulté le )
  • (en) Ole Agesen, Alex Garthwaite, Jeffrey Sheldon et Pratap Subrahmanyam, « The Evolution of an x86 Virtual Machine Monitor », SIGOPS Oper. Syst. Rev., vol. 44,‎ , p. 3–18 (ISSN 0163-5980, DOI 10.1145/1899928.1899930, lire en ligne, consulté le )
  • (en) Diego Ongaro, Alan L. Cox et Scott Rixner, « Scheduling I/O in Virtual Machine Monitors », Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, ACM, vEE '08,‎ , p. 1–10 (ISBN 978-1-59593-796-4, DOI 10.1145/1346256.1346258, lire en ligne, consulté le )

Liens externes[modifier | modifier le code]

Site officiel de Xen

Site officiel de KVM