A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

Vous avez surement dû voir sur divers sites web l’appellation hyperviseur type 1 et hyperviseur type 2. Je ne connais pas l’origine des ces termes. Je soupçonne cependant fortement que ces deux termes soit d’origine marketing.

Note : Cet article a été publié sur le blog Orange Business Service Virtualisation le 3 Novembre 2009.

Qu’est ce qu’un hyperviseur ?

Tout d’abord, je vais m’attacher à exposer les différentes définitions de la notion d’hyperviseur. Wikipedia France nous donne la définition suivante.

En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une machine physique en même temps.

Cette définition semble particulièrement large. Elle implique l’équivalence entre hyperviseur et application de virtualisation. Je définirais un « composant de virtualisation » en tant que n’importe quel composant applicatif permettant d’exécuter plusieurs systèmes d’exploitation sur une même machine physique. Il y a donc bien équivalence entre les deux définitions.

Qu’est ce qui définit techniquement un hyperviseur ?

Comme vous le savez, il existe de nombreuses techniques de virtualisation. Toutes ces techniques de virtualisation proposent une diversité assez large. Il me semble donc assez réducteur des les regrouper toutes sous le nom d’hyperviseur d’autant plus que l’appellation « composant de virtualisation » existe déjà.

La définition technique d’un hyperviseur est mieux illustrée à travers le fonctionnement de la paravirtualisation. Dans le cas de la paravirtualisation, l’hyperviseur est l’interface primaire et exclusive des ressources physiques principales. La notion d’hyperviseur se justifie par le fait que le noyau est historiquement le « superviseur ». Cette notion de « superviseur » est issue du mode « superviseur » des processeurs x86 car il s’agit du noyau qui va gérer les interruptions en mode superviseur. En toute logique, nous avons donc l’hyperviseur qui gère les superviseurs.

Dans le cas de la virtualisation de systèmes d’exploitation non modifiées, le « composant de virtualisation » se situe au dessus d’un système d’exploitation et donc d’un noyau. Nous avons donc une contradiction au niveau des appellations vu que l’hyperviseur va être géré par le « superviseur », à savoir, le noyau. Il y a donc une incohérence. Je vous remets, pour rappel, le schéma comparant paravirtualisation et virtualisation totale.

Quid des types d’hyperviseur

Afin de palier à cette contradiction, une différenciation a été faite et l’appellation « hyperviseur type 1 » et « hyperviseur type 2 » a vu le jour. Cette appellation ne répond cependant pas à la contradiction soulevée précédemment.

Pour rappel, un hyperviseur de « type 1 » est un hyperviseur s’exécutant directement sur la plateforme matérielle, comme dans le cas de la paravirtualisation. Un hyperviseur de « type 2 » est un hyperviseur s’exécutant par dessus un système d’exploitation invité.

Pour résumer cet article, je pense que l’appellation d’hyperviseur n’est pas adaptée aux solutions de virtualisation s’exécutant au dessus d’un système d’exploitation invité. Je pense que l’appellation « application de virtualisation » serait plus adaptée et correspondrait plus à la réalité. Je tiens également à soulever la question essentielle de cet article, peux-t’on considérer un couple système d’exploitation et application de virtualisation en tant qu’hyperviseur ? A partir de quel seuil un couple OS/application de virtualisation peut-il être considéré en tant qu’hyperviseur ?

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

Les trois modes de configuration réseau dans Xen sont : bridge, route et NAT. En Français, nous aurons donc pont, routage et NAT. Ces trois modes répondent à différents besoins en terme de configuration réseau. Le premier critère de choix du mode réseau est la topologie logique du réseau existant. Les éléments de topologie vont inclure les VLAN ainsi que les différents réseaux IP.

Le mode pont

Le schéma ci-dessus explique le fonctionnement du mode pont. Il s’agit du mode le plus simple agissant au niveau le plus bas. Les domU sont connectés au dom0 via des interfaces réseau virtuels. Le dom0 ne fait qu’une simple commutation en redirigeant les trames soit vers le bon domaine soit vers le reste du réseau.

L’avantage de ce mode est l’extrême simplicité de la configuration qui permet une transparence par rapport au reste de l’architecture. La configuration des domU est également simple et ne nécessite aucune particularité. Il est possible de superposer n’importe quelle configuration IP en utilisant ce mode. Vous remarquerez que ce mode ne prend pas en compte les VLAN nativement. Nous verrons ultérieurement une possibilité de fonctionnement de ce mode avec la prise en compte des VLAN via 802.1Q.

Le mode routage

Le schéma ci-dessus explique le fonctionnement du mode routage. Il s’agit d’un mode assez peu utilisé. La raison de la faible utilisation de ce mode est lié au fort lien entre topologie physique et topologique logique. Je m’explique. Avec cette configuration, il est pratiquement impossible de migrer des machines virtuelles entre des machines physiques sans modification de routage.

Ce mode est cependant très utile dans le cadre d’un serveur OVH doté d’IP supplémentaires. Ceci est du au fait qu’une bonne partie des serveurs OVH ne supportent pas le mode pont pour un raison inconnue.

Le mode NAT

Le mode NAT est une évolution du mode routage. Vous avez toujours deux plages d’IP différentes de part et d’autre du dom0 mais les IP des domU ne seront pas visibles sur le réseau public.

Par défaut, ce mode permet un accès au réseau public par les domU mais pas d’accès dans le sens inverse. Vous pourrez mettre en place des accès dans le sens inverse en utilisant iptables.

L’idée de base des précédents types de virtualisation était de faire croire au système d’exploitation qu’il s’exécutait sur une machine physique alors que ce n’était pas le cas. Cette technique est la technique la plus évidente lorsqu’on essaye de virtualiser des systèmes d’exploitation principalement propriétaires ce qui est le cas de VMWare par exemple. Il s’agit d’une méthode qui permet de centraliser toutes les fonctionnalités de virtualisation dans un seul endroit, à savoir la couche de virtualisation. L’inconvénient de cette méthode est que la couche de virtualisation devient rapidement très lourde avec la quantité croissante du nombre de fonctionnalités à implémenter.

La paravirtualisation adopte une vision radicalement différente. Au lieu de chercher à faire croire aux systèmes d’exploitation qu’ils s’exécutent sur une machine physique, il est possible d’adapter le système d’exploitation à la couche de virtualisation. Ceci n’aurait bien évidemment pas été possible sans la présence de logiciels libres…

La paravirtualisation vise donc à modifier les systèmes d’exploitation pour communiquer avec un hyperviseur au lieu de communiquer avec une machine physique. Sur ce blog, je parlerais d’hyperviseur au sens de Xen ou d’Hyper-V. VMWare parle d’hyperviseur à tord et à travers mais il ne s’agit pas, selon moi, d’un vrai hyperviseur. En réalité, il s’agit d’un système d’exploitation hôte déguisé.

L’hyperviseur au sens de la paravirtualisation est en contact direct avec le matériel physique. Il est l’intermédiaire exclusif entre le matériel et les systèmes d’exploitation. Lorsqu’on se trouve donc dans un système de paravirtualisation, il n’y a plus de notion de système d’exploitation invité et de système d’exploitation hôte. Tous les systèmes d’exploitation sont virtualisés dans le sens où ils disposent d’un noyau adaptés à la couche de virtualisation. Tous les systèmes d’exploitation ne seront pas égaux pour autant, il est possible de donner des accès spécifiques à différents systèmes d’exploitation.

Les systèmes d’exploitation communiquent avec l’hyperviseur via des API de communication. Ces API de communication remplacent les traditionnels appels systèmes. Chaque couche de virtualisation dispose donc de sa propre API. Pour adapter un système d’exploitation à un hyperviseur, il faut donc intégrer son API au noyau. Cela explique en partie le passage en GPL des pilotes Hyper-V de Microsoft.

Au final, la paravirtualisation est une technique particulièrement innovante qui présente une approche plus efficace de la virtualisation. Les avantages de cette technique sont une perte de performance largement réduite par rapport à une virtualisation totale. L’inconvénient majeur est qu’il est nécessaire d’adapter les systèmes d’exploitation pour chaque couche de virtualisation. Afin de résoudre ce problème, il est possible de coupler paravirtualisation et virtualisation matérielle assistée comme dans Xen.

Tout d’abord, le terme de virtualisation matériel assistée semble assez explicite. On comprend bien qu’il s’agit de virtualisation qui va être assistée par une fonctionnalité spécifique du matériel. Les détails du fonctionnement de cette technologie le sont cependant bien moins. Ce terme est une traduction de l’anglais « Hardware Assisted Virtualization ». On peut aussi trouver comme autre traduction « virtualisation assistée par matériel ». Tous ces termes sont cependant équivalents. Cependant, la virtualisation partielle n’a aucun rapport.

Comme vous pouvez le voir, le schéma d’architecture ne change que très peu par rapport à la virtualisation totale. Avec la virtualisation totale, nous parlions de couche logicielle de virtualisation alors que parlerons plutôt de « Virtual Machine Monitor » ou VMM dans le cas de la virtualisation matériel assistée.

Une extension du jeu d’instructions du processeur

Ensuite, il est important de préciser que la virtualisation matériel assistée n’est pas une technique à part entière. Il s’agit en réalité d’une extension du principe de virtualisation totale. La principale modification qui est apportée est l’ajout d’extensions processeur de virtualisation. Vous en avez surement entendu parlé, je parle bien d’Intel VT et d’AMD-V. Ces instructions ont été implémentées dans les processeurs afin de pouvoir améliorer la virtualisation totale. Ces instructions sont une extension du jeu d’instructions exécutables par le processeur similairement à SSE ou MMX.

Ces instructions apportent plusieurs améliorations. Tout d’abord, elles créent un anneau -1 qui sera l’endroit privilégié de l’exécution d’un hyperviseur. Ceci permet de garder la localisation traditionnelle des anneaux avec le système d’exploitation présent dans l’anneau 0 et les applications dans l’anneau 3. Les autres ne sont jamais utilisé à l’exception de quelques rares cas. J’aurais l’occasion de revenir plus tard sur la notion d’anneau. Le placement du système d’exploitation dans son anneau traditionnel permet de simplifier l’accès à certains instructions et donc de supprimer une partie du travail de la couche de virtualisation.

De plus, elles permettent aux machines virtuelles de gérer leurs propres interruptions et donc changements de contexte. Ceci évite à la couche logicielle de virtualisation de devoir les gérer. Egalement, elles permettent au matériel de gérer directement  les zones de mémoire vive (non forcément linéaires) disponibles au machines virtuelles. Sans les extensions, il était nécessaire que la couche de virtualisation émule et gère des zones.

Si vous souhaitez plus d’informations sur ces instructions, je vous invite à consulter la documentation d’Intel disponible ici ou ici.

Au final, les extensions processeur de virtualisation permettent d’améliorer la technique de la virtualisation totale. Ceci se fait par l’ajout d’un degré d’intelligence au niveau du matériel qui sera conscient de l’utilisation d’une couche de virtualisation. La virtualisation matériel assistée est donc une évolution du principe de virtualisation totale.

La virtualisation totale consiste à émuler l’intégrité d’une machine physique. Pour rappel, l’émulation est le principe qui consiste à remplacer un composant matériel par une application dont le comportement est similaire voire identique. Le cas le plus classique d’émulation est l’émulation de vieilles consoles de jeux telles que la Super Nintendo ou la Game Boy. L’objectif de la virtualisation totale est donc de faire croire au système d’exploitation invité qu’il est présent sur du matériel physique et non au dessus d’une couche applicative.

Il s’agit de l’approche la plus basique en terme de virtualisation : « On ne peut pas avoir du matériel physique du coup on va le remplacer par une application ». Il s’agit de la première approche qui a été adoptée par VMWare en 1999 lors de sa création.

Comme présenté dans le schéma, la base installée sur le matériel est un système d’exploitation classique. Tous les systèmes d’exploitation, à ma connaissance, sont capables d’exécuter une application de virtualisation totale. Ceci est lié à la simplicité de son fonctionnement. La « Couche Logicielle » évoquée dans le schéma est une application telle que VMWare ou VirtualBox qui s’exécute comme toute autre application. Cette couche logicielle va ensuite émuler autant de matériel qu’il y a de machines virtuelles.

Certains vendeurs telles que VMWare vendent des solutions de virtualisation nommées « Bare Metal Hypervisor ». Cependant ce que VMWare appelle hyperviseur n’est absolument pas un hyperviseur au sens de Xen. Il s’agit en réalité d’un Linux Red Hat customisé.

L’inconvénient de la virtualisation totale est la performance. Il est nécessaire d’émuler de nombreux composants physiques et de capter toutes les instructions émanants des machines virtuelles ce qui consomme beaucoup de ressources. Des tests montrent de pertes de performance de l’ordre de 20% à 80%. Il est possible d’améliorer significativement les performances en ajoutant des pilotes de paravirtualisation qui permettent un meilleur interfacage avec la couche logicielle sous-jacente.

Vous avez surement entendu parler de très nombreux types de virtualisation avec un panel de noms au moins aussi nombreux. Au début, on a tendance à rapidement s’y perdre. Je vais donc essayer dans cet article proposer une classification de la virtualisation qui est celle que nous avons proposé lors de l’AC.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Qu’est ce qu’on virtualise ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite. La virtualisation de routeurs et de switchs se fait notamment par les VRF dans les IOS Cisco ou bien des applications telles que Nexus de Cisco (switchs virtuels pour VMWare).

La virtualisation d’application est également un secteur important du marché même si il est peu connu car il n’existe pas, à ma connaissance, d’application libre sur ce secteur. Pour vous illustrer le principe, avec la virtualisation d’application vous pouvez vous connecter sur un portail, cliquer sur l’application de votre choix et elle s’exécute en quelques secondes sans être installé sur votre poste. Je ne sais pas comment ca fonctionne mais c’est assez impressionnant à voir. Un exemple d’implémentation de cette technologie est Citrix XenApp (pas grand chose à voir avec Xen a priori).

Ce dont je vais essentiellement parler, c’est la virtualisation de système d’exploitation. C’est le type de virtualisation généralement le plus connu. Le but de ce type de virtualisation est d’exécuter simultanément plusieurs systèmes d’exploitation sur une même machine physique. Les exemples d’implémentation ne manquent pas : Xen, VMWare, KVM, Hyper-V, …

On virtualise comment ?

Nous allons nous intéresser plus particulièrement à la virtualisation de systèmes d’exploitation. Je vous propose tout d’abord un arbre qui résume bien les différents types de virtualisation. Une fois de plus, il s’agit d’une proposition de classification, il en existe surement plein d’autres.

Comme on le voit dans le schéma, la première distinction qui est faite est la distinction entre virtualisation de systèmes d’exploitation et virtualisation de processus. Il y a une différence fondamentale entre exécuter un système d’exploitation complet et effectuer un cloisonnement de processus. Des exemples de virtualisation de processus sont OpenVZ, les jails BSD ou encore les zones Solaris.

Dans la virtualisation de systèmes, nous avons distingué à nouveau deux catégories : les systèmes modifiés et les systèmes non modifiées. Cette distinction est également essentielle car elle va régir tout le fonctionnement de la virtualisation. Dans le cas de systèmes modifiées, le système d’exploitation va avoir « conscience » d’être présent au dessus d’une couche de virtualisation et va travailler efficacement avec cette dernière. Dans le cas de systèmes non modifiés, la couche de virtualisation va faire tout son possible pour faire croire au système d’exploitation qu’il est présent sur du matériel physique.

Dans la catégorie des systèmes modifiés, on va retrouver la paravirtualisation. La paravirtualisation est le type de virtualisation inventé par le projet Xen. Ce type de virtualisation a été rendu possible grâce aux logiciels libres car il a été possible de modifier et d’adapter le noyau Linux ou BSD ou Solaris. Microsoft a mis en pratique cette méthode avec son produit Hyper-V intégré à Windows Server 2008.

Dans la catégorie des systèmes non modifiées, on va retrouver la virtualisation totale et la virtualisation matérielle assistée. Cette dernière n’est qu’une amélioration de la virtualisation totale grâce aux extensions processeurs AMD-V et Intel VT.  Ce type de virtualisation est le type de virtualisation le plus utilisé grâce à la simplicité de fonctionnement des applications et à la puissance des outils d’administration existants. On retrouve dans cette catégorie VMWare, VirtualBox et Virtual PC entre autres.

Pour conclure et mettre une nuance à cette classification, il est possible de mélanger les types de virtualisation, je m’explique. Il est possible, par exemple, dans un système d’exploitation fonctionnant en virtualisation matérielle assistée de rajouter des pilotes de paravirtualisation afin d’améliorer les performances ou d’ajouter une fonctionnalité.