Accueil
Rechercher:
sur developpez.com sur les forums
Forums | Tutoriels | F.A.Q's | Participez | Hébergement | Contacts
Accueil Conception Java DotNET Visual Basic  C  C++ Delphi Eclipse MS-Office SQL & SGBD Oracle  4D  Business Intelligence
Club Emploi Blogs   TV   Dév. Web PHP XML Python Autres 2D-3D-Jeux Sécurité Windows Linux PC Mac
Ada Algo Assembleur Basic Cobol Fortran LaTeX MATLAB Pascal Perl Prolog Purebasic Réseau Ruby Systèmes XMLRAD

État de l'art des solutions libres de virtualisation pour une petite entreprise

Date de publication : 12/02/2008

Par Lucas Bonnet (Bearstech)
 

Vous trouverez la dernière version de ce document au format pdf ici

            

I. Introduction
I-A. La virtualisation
I-B. Intérêt de la virtualisation
I-C. Enjeux de la virtualisation
II. État du marché de la virtualisation
II-A. Le logiciel libre
II-B. La virtualisation - définitions
II-B-1. Fonctionnement d'un système d'exploitation
II-B-2. La virtualisation complète
II-B-3. La paravirtualisation
II-B-4. Les systèmes à hyperviseur
II-B-5. Les techniques de cloisonnement
II-C. Historique
II-C-1. Premiers pas
II-C-2. Machines virtuelles
II-C-3. Amélioration des technologies
II-C-4. Intérêt du grand public
II-D. Acteurs majeurs
II-E. Évolutions récentes
III. Analyse de solutions majeures de virtualisation
III-A. Expression des besoins et contraintes
III-A-1. Contraintes
III-A-2. Besoins
III-B. Autres solutions
III-B-1. Bochs
III-B-2. VMware Server
III-C. QEMU
III-C-1. Présentation
III-C-2. Technologies
III-C-3. Fonctionnalités
III-C-4. Communauté
III-C-5. Réutilisation du projet
III-C-6. Licence
III-C-7. Inconvénients
III-C-8. Bilan
III-D. KVM
III-D-1. Présentation
III-D-2. Technologies
III-D-3. Fonctionnalités
III-D-4. Communauté
III-D-5. Licence
III-D-6. Inconvénients
III-D-7. Bilan
III-E. Linux-VServer
III-E-1. Présentation
III-E-2. Technologies
III-E-3. Fonctionnalités
III-E-4. Communauté
III-E-5. Licence
III-E-6. Inconvénients
III-E-7. Bilan
III-F. OpenVZ
III-F-1. Présentation
III-F-2. Technologies
III-F-3. Fonctionnalités
III-F-4. Communauté
III-F-5. Licence
III-F-6. Inconvénients
III-F-7. Bilan
III-G. Xen
III-G-1. Présentation
III-G-2. Technologies
III-G-3. Fonctionnalités
III-G-4. Communauté
III-G-5. Licence
III-G-6. Inconvénients
III-G-7. Bilan
III-G-8. Récapitulatif
IV. Étude comparative de Xen et KVM
IV-A. Étude approfondie de Xen
IV-A-1. Historique du projet
IV-A-2. Analyse détaillée
IV-A-3. Cas d'utilisation
IV-B. Étude approfondie de KVM
IV-B-1. Historique du projet
IV-B-2. Analyse détaillée
IV-B-3. Cas d'utilisation
IV-C. Bilan
IV-C-1. Xen
IV-C-2. KVM
V. Conclusion
VI. Glossaire
VII. Références


I. Introduction

Depuis quelques années, la virtualisation est au coeur des préoccupations des entreprises du secteur informatique. En effet, on assiste à une montée en puissance des acteurs du marché, que ce soit dans le domaine propriétaire avec Microsoft et VMware, ou dans le domaine des logiciels libres, avec l'émergence de nombreux projets autour de la virtualisation. Il suffit de voir le nombre de conférences liées aux technologies de virtualisation pour l'entreprise et le nombre d'articles de presse (en ligne ou papier) traitant de la virtualisation. Cette montée en puissance n'est pas due au hasard : elle suit de très près la demande du marché, qui se tourne de plus en plus vers les technologies de virtualisation.


I-A. La virtualisation

L'encyclopédie francophone en ligne Wikipédia définit la virtualisation comme « l'ensemble des techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur une seule machine plusieurs systèmes d'exploitation et/ou plusieurs applications, séparément les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes » [WFv]. Il s'agit donc d'utiliser une seule machine physique en remplacement de plusieurs et d'utiliser les possibilités offertes par la virtualisation pour démultiplier le nombre de machines virtuelles.

Prenons l'exemple d'une solution de virtualisation faite pour le grand public, de type VMware ou QEMU : l'utilisateur possède un seul ordinateur, sur lequel est installé un système d'exploitation (Microsoft Windows, GNU/Linux, Mac OS X, etc.) ainsi qu'une application qui fait office de machine virtuelle : le logiciel installé par VMware ou QEMU. L'utilisateur peut à partir de là se servir de ce programme pour démarrer un nouveau système d'exploitation (qui peut être totalement différent de celui installé sur la machine physique). Le système d'exploitation virtualisé - aussi appelé système invité (guest system) - est alors exécuté par la machine virtuelle et est complètement détaché de tout le matériel de l'ordinateur. La machine virtuelle se charge d'émuler* pour le système invité tout le matériel « standard » d'un ordinateur (disque dur, écran, clavier, souris, ...). L'utilisateur peut alors utiliser le système invité comme un système normal : installer des applications, naviguer sur Internet, exécuter un programme, etc. Le système hôte - installé sur la machine physique - et le système invité sont totalement indépendants : le système invité est vu par l'hôte comme un simple programme, il n'a pas d'accès direct au matériel contrairement à l'hôte.

Toutefois, la virtualisation ne se limite pas uniquement à une utilisation grand public : elle recouvre plusieurs champs d'application, via plusieurs technologies et pour plusieurs objectifs. La définition reste vague, car sous une appellation unique se cachent énormément de notions à prendre en compte. Les buts et les usages de la virtualisation varient également beaucoup selon les besoins et les catégories d'utilisateurs. Les paragraphes suivants seront donc consacrés à une brève présentation de quelques cas d'utilisation - sans détailler quelles solutions techniques sont adaptées à chaque usage -, ce qui permettra de cerner tout ce qu'apporte la virtualisation pour toutes les catégories d'utilisateurs.


I-B. Intérêt de la virtualisation

Pour le particulier, la virtualisation permet d'avoir accès à des applications ne fonctionnant pas sur le système d'exploitation principal de l'utilisateur. On peut notamment citer les applications trop vieilles pour s'exécuter sur la dernière génération du système d'exploitation (les anglophones parlent de legacy applications*). Un autre domaine couvert par la virtualisation est l'utilisation de programmes non portés sur la plate-forme cible (architecture PC vs architecture Mac 1, par exemple). On peut aussi citer, même si c'est plus rare, l'utilisation de virtualisation pour les jeux : faire fonctionner un jeu fait pour Microsoft Windows dans une machine virtuelle s'exécutant sur un système GNU/Linux. La société VMware propose notamment l'accès à l'accélération 3D depuis une machine virtuelle pour son produit grand public, permettant d'atteindre des perfor- mances proches de l'original.

Pour les professionnels et les chercheurs en sécurité, un système d'exploitation virtualisé permet d'observer le comportement d'un logiciel malveillant (malware*) - virus, ver, spyware, etc. - dans un système sain sans avoir à infecter une machine physique. De plus, le processus d'infection est reproductible, car il suffit de sauvegarder l'état de la machine virtuelle avant l'infection pour pouvoir répéter l'opération plusieurs fois, dans des conditions contrôlées. Il est alors possible d'analyser l'état de la machine virtuelle après infection, et de tirer des conclusions sur l'action du logiciel.

Pour une entreprise, les technologies de virtualisation permettent de séparer des applications et des systèmes de manière logique, quand les prérequis des applications sont mutuellement exclusifs. Par exemple, une application critique mais incompatible avec une version donnée d'un logiciel ne peut pas cohabiter sur la même machine avec une autre application dépendant d'une autre version du même logiciel. Certains cas d'incompatibilités peuvent se résoudre en laissant installés les deux logiciels dans deux versions différentes, mais le surcoût de maintenance est non négligeable.

En plus de la simple incompatibilité de versions, deux applications peuvent aussi avoir le même rôle, mais dans des contextes différents. Par exemple une version de développement et une version finale d'un site web ne peuvent pas cohabiter de manière simple, à moins d'y consacrer un effort de maintenance là aussi conséquent. Pour le développement d'une application web, le test du site sous plusieurs navigateurs est primordial. La virtualisation de plusieurs systèmes d'exploitation permettra aux développeurs de tester le rendu de plusieurs navigateurs sur plusieurs plates-formes sans avoir à changer de machine - et donc d'environnement de travail - en permanence.

Au delà de la possibilité de faire fonctionner des applications qui ne peuvent normalement pas s'exécuter sur une machine donnée, la virtualisation permet aussi de les rassembler sur une même machine physique, sans avoir à maintenir un serveur distinct par application. Traditionnellement, l'usage était de consacrer une machine physique à un service (messagerie, stockage, hébergement d'intranet, etc.), tant pour des raisons pratiques (associer une machine à un rôle unique) que pour la sécurité (séparation des services).

Toutefois, cette dispersion a un coût qui n'est pas nul pour l'entreprise, que ce soit en es pace occupé (location au mètre carré dans les datacenters*), en énergie (consommation électrique) ou en maintenance (plus de machines physiques implique plus de risques de pannes matérielles). De plus, la plupart des services fournis sur un réseau local (DHCP, DNS, Intranet, ...) ne consomment qu'une très faible partie des ressources offertes par une machine récente. Tous ces facteurs font qu'il n'est plus pertinent aujourd'hui d'utiliser des machines séparées pour héberger des services ne nécessitant qu'une fraction de la puissance d'une machine.

Aussi, à l'heure actuelle, la tendance est plutôt au rassemblement de plusieurs services, autrefois distincts, sur une seule machine, par le biais de l'utilisation de technologies de virtualisation pour maintenir une séparation entre les services. On parle de consolidation de serveurs.

Enfin, l'utilisation d'applications « anciennes » (au sens informatique du terme) est au moins aussi importante chez les entreprises que chez les particuliers. L'importance parfois critique de ces applications pour le fonctionnement de l'entreprise fait qu'il est souvent plus facile de continuer à maintenir un système et une machine obsolètes (et donc avec un risque de panne matérielle plus important) que d'entamer une migration vers une nouvelle plate-forme. La virtualisation permet dans ce cas d'exécuter l'application comme dans son environnement d'origine, mais sur du matériel récent. On peut citer, sans ordre particulier : une application de comptabilité (ou un progiciel quelconque) utilisée depuis des années mais non portée sur la nouvelle version d'un système d'exploitation ou encore un logiciel de pilotage de machine industrielle. Ce sont deux exemples classiques d'application de la virtualisation pour autre chose que de l'hébergement de services.

En plus des possibilités techniques citées ci-dessus, la virtualisation est également une technologie clef pour l'avenir de l'entreprise. En effet, elle ne permet pas seulement de contourner les limitations matérielles des ordinateurs, mais elle peut aussi fournir un avantage décisif sur la concurrence dans le milieu très disputé qu'est l'informatique de services.


I-C. Enjeux de la virtualisation

Pour une petite entreprise de services informatiques, la virtualisation peut apporter beaucoup en terme de réactivité et de flexibilité. En effet, une forte réactivité est un avantage certain pour l'entreprise et permet d'attirer et de conserver plus de clients. La flexibilité permet quant à elle d'adapter le processus de travail en fonction des besoins de la société.

Pouvoir tester très rapidement comment se comporte une application dans une configuration logicielle donnée est un avantage à ne pas négliger si l'on veut rester compétitif. Avec la virtualisation, on peut déployer très rapidement une nouvelle configuration logicielle (système d'exploitation, applications installées et configurées, environnement de développement, etc.) et l'installer aussitôt en production. Le gain de temps ainsi occasionné se mesure en heures dans une journée de travail.

De même, le déploiement d'un système ou d'une application peut très simplement se faire à distance, alors que l'installation du système d'exploitation d'une machine requiert la plupart du temps quelqu'un sur place, au moins pour les premières étapes. Si la société dispose de peu de personnel, l'économie d'un déplacement dans un datacenter peut être très intéressante.

En outre, la virtualisation permet de réduire le nombre de machines physiques à acheter, administrer et maintenir. Il y a donc une économie financière à la clef, qui peut être substantielle si l'entreprise a besoin de beaucoup de serveurs pour son activité. En plus du simple gain en nombre de machines, les économies réalisées en consommation d'électricité, location d'espace dans un datacenter et location de bande passante sont aussi à prendre en compte.

Les technologies de virtualisation sont donc très intéressantes car elles permettent de réduire le temps passé à administrer les machines et les systèmes en automatisant et centralisant la plupart des activités traditionnelles.

Toutefois, une solution de virtualisation complète requiert des compétences que n'a pas forcément la société. En effet, l'administration d'un système virtualisé diffère de l'administration d'une machine physique traditionnelle sur plusieurs points, notamment l'accès au matériel. L'enjeu est donc de savoir si le temps consacré à la formation et à l'apprentissage vaut le temps gagné à l'utilisation, une fois la solution de virtualisation maîtrisée.

En plus de l'alternative « virtualisation ou non » il y a aussi le choix de la solution à mettre en place. En effet, il y a plusieurs projets et produits proposant de la virtualisation pour l'entreprise, tous ayant leurs points forts et leur discours commercial. Il est donc important de ne pas effectuer le mauvais choix, tant dans l'absolu (produit ou projet à l'abandon) que dans le contexte d'utilisation (inadéquation aux besoins de l'entreprise).

L'étendue du domaine couvert par l'ensemble des technologies de virtualisation est relativement important. Cela va de la virtualisation dédiée aux particuliers à la virtualisation de serveurs d'entreprise, avec à chaque fois des choix technologiques différents. L'étude menée dans le cadre de ce livre blanc sera donc consacrée à un domaine et à un type de projet précis.

Le domaine étudié sera celui de la virtualisation de serveurs pour une petite entreprise, les projets sélectionnés seront des projets ayant une licence libre.

La première partie de ce livre blanc sera tout d'abord consacrée à la définition des principes du logiciel libre, suivie d'une définition de la virtualisation, des différentes technologies utilisées ainsi qu'un historique. Les acteurs majeurs du marché de la virtualisation, tant du côté propriétaire que du côté des logiciels libres, seront ensuite traités.

La seconde partie du livre blanc portera sur la définition des besoins d'une PME en matière de virtualisation, puis sur l'étude détaillée de quelques projets phares, en explicitant notamment leurs choix techniques.

La troisième et dernière partie sera une étude comparative des solutions majeures retenues, en mettant en avant les besoins d'une PME avec une analyse de leurs forces et faiblesses.


II. État du marché de la virtualisation


II-A. Le logiciel libre

Les notions de logiciel libre et licence libre ont été mentionnées dans l'introduction, sans les définir. Il est important pour bien saisir les enjeux du logiciel libre de bien définir ces termes, car ce sont des éléments clés dans les choix des produits étudiés dans ce livre blanc. L'encyclopédie Wikipédia possède une définition concise du logiciel libre : « Un logiciel libre se dit d'un logiciel qui donne à toute personne qui en possède une copie, le droit de l'utiliser, de l'étudier, de le modifier et de le redistribuer » [WFl]. Le mouvement du logiciel libre trouve son origine au début des années quatre-vingt, quand Richard Matthew STALLMAN fonde la Free Software Foundation (FSF). Cette association a pour but de promouvoir et soutenir les logiciel libres, en établissant notamment les quatre libertés fondamentales :

  1. La liberté d'exécuter le programme ;
  2. La liberté d'étudier le fonctionnement du programme ;
  3. La liberté de redistribuer des copies ;
  4. La liberté d'améliorer le programme et de publier ses améliorations.
Ces libertés doivent être irrévocables, d'après la FSF : une personne (ou une entreprise) modifiant un logiciel libre n'a pas le droit de redistribuer ce logiciel en interdisant la modification, l'étude ou l'amélioration de ce dernier. Ainsi, les logiciels vont en s'améliorant, les altérations apportées étant reversées à la communauté. Le mouvement du logiciel libre se fonde donc sur le partage de la connaissance. Les licences de ces logiciels sont appelées des licences libres et il en existe plusieurs sortes, pas toujours compatibles entre elles, en fonction des buts recherchés. En effet, certaines licences s'opposent par exemple à la commercialisation du logiciel alors que d'autres autorisent les modifications non reversées à la communauté. Cette grande diversité des licences - et les débats parfois houleux de leurs partisans respectifs - fait qu'il est souvent difficile pour un néophyte de bien saisir tous les enjeux du choix de licence d'un projet donné.

Pour résumer, il y a deux grands courants de pensée au sein du mouvement du logiciel libre, concernant les licences. Premièrement, les licences de type GNU GPL (GNU General Public License), qui garantissent les quatre libertés précédentes et sont « compatibles » avec la licence GPL. D'autre part, on retrouve les licences de type BSD (Berkeley Software Distribution) qui autorisent les sources à ne pas être redistribuées avec les programmes modifiés. Une licence de type BSD permet donc à un logiciel de devenir moins libre, alors qu'une licence de type GPL garantit exactement l'inverse, à savoir qu'un logiciel sous GPL restera tout le temps sous GPL2. Le lecteur intéressé pourra notamment se référer aux Fiches Libres de l'ALDIL, disponibles sur [AFL].

De même, on a souvent tendance à associer logiciel libre à gratuité, alors qu'un logiciel libre peut tout à fait être payant. Par exemple, Richard STALLMAN facturait 150 dollars la diffusion de son éditeur de texte Emacs. Rien ne s'oppose donc à ce qu'une société fasse payer le fruit de ses efforts de développement à un client, même dans le cas d'un logiciel libre. D'ailleurs, de nombreuses sociétés basent leur modèle commercial autour du logiciel libre, en mettant l'accent sur les services apportés : expérience, adaptation du logiciel aux besoins des clients, support, etc. On peut notamment citer Red Hat et Mandriva, qui éditent une distribution Linux libre et facturent le service associé.

En plus des sociétés qui basent leur business model sur le libre, on trouve aussi des entreprises qui soutiennent le développement de logiciels libres, par exemple IBM et Google paient des développeurs pour travailler sur des projets libres.

Des exemples de logiciels libres connus et réputés sont :

  • le navigateur Internet Mozilla Firefox ;
  • le système d'exploitation GNU/Linux (c'est à dire le noyau Linux et tous les programmes venant avec, issus du projet GNU) ;
  • le logiciel de messagerie Mozilla Thunderbird ;
  • le serveur web du projet Apache (qui représente plus de 60 % des serveurs web sur Internet)...
Par opposition, on appelle un logiciel propriétaire un logiciel qui ne fournit pas toutes ces libertés à l'utilisateur, la licence n'étant souvent qu'un simple droit d'utilisation concédé. On peut citer comme exemple de logiciel propriétaire le système d'exploitation Microsoft Windows (toutes versions confondues) ou encore la suite bureautique Microsoft Office.

Les logiciels libres ont su conquérir une grande communauté d'utilisateurs de par le monde, amenant toujours plus de contributeurs aux projets, améliorant ainsi la qualité des logiciels. Les avantages des logiciels libres sur les logiciels propriétaires sont nombreux, tant sur le plan technique (disponibilité du code source, modifications possibles) que sur le plan idéologique (ouverture à la communauté, partage des connaissances, non-enfermement des utilisateurs), c'est pourquoi ce livre blanc se concentre uniquement sur les solutions de virtualisation libres. Néanmoins, dans un souci d'exhaustivité, les solutions propriétaires majeures seront mentionnées.


II-B. La virtualisation - définitions

La virtualisation a été brièvement définie dans l'introduction comme le moyen de faire fonctionner sur une seule machine physique plusieurs systèmes d'exploitation ou plusieurs applications [WFv; WAv]. Cet objectif est atteint grâce à plusieurs technologies ayant des buts différents. Il est important de bien définir toutes ces technologies avant d'étudier les projets retenus.

Tout d'abord, il existe plusieurs catégories de virtualisation, utilisant chacune des technologies différentes. Les technologies les plus répandues sont :

  • la virtualisation complète ;
  • la paravirtualisation ;
  • la virtualisation assistée par le matériel ;
  • le cloisonnement.
Chacune de ces technologies est une technologie de virtualisation, mais elles ne fonctionnent pas de la même façon. Les principes et particularités de chaque technologie seront détaillés dans les pages suivantes.

Toutefois, avant de définir ces technologies, il est crucial de bien saisir le fonctionnement et le rôle d'un système d'exploitation. En effet, comme l'objectif de la plupart des technologies de virtualisation est de faire cohabiter plusieurs systèmes d'exploitation sur la même machine physique, il faut auparavant expliquer pourquoi il est nécessaire d'utiliser une solution de virtualisation pour ce faire. C'est pourquoi comprendre comment fonctionne un système d'exploitation et pourquoi il est nécessaire, même superficiellement, permettra de bien saisir les choix techniques et les problèmes rencontrés par la virtualisation. La section suivante sera donc consacrée à expliquer - de manière très succincte-le rôle d'un système d'exploitation et du matériel courant d'un ordinateur.


II-B-1. Fonctionnement d'un système d'exploitation

Le système d'exploitation (operating system) est un ensemble complexe faisant office de couche d'abstraction entre le matériel (hardware, niveau physique) et le logiciel (software, niveau logique). Il est composé d'une multitude de composants, chacun assigné à un rôle spécifique. Parmi les tâches dévolues au système d'exploitation, on retrouve notamment la gestion de la mémoire vive (RAM) et des périphériques (stockage, carte réseau, imprimante, écran, clavier, etc.). La gestion de la RAM est l'une des tâches les plus complexes du système d'exploitation. En effet, tous les programmes (que ce soit au niveau de l'utilisateur ou du système d'exploitation) ont besoin de mémoire pour fonctionner. C'est dans la RAM que seront stockés :

  • le code des programmes en cours d'exécution ;
  • les données des programmes en cours d'exécution ;
  • le code du système d'exploitation ;
  • les données du système d'exploitation.
Un composant du système d'exploitation est entièrement dédié à la gestion de la mémoire, notamment la réservation et la libération pour les applications et le système d'exploitation. Quand la RAM vient à manquer, le système peut utiliser une partie du disque dur comme extension de mémoire. Le disque dur est toutefois de plusieurs ordres de grandeur plus lent que la RAM, aussi le gestionnaire de mémoire fait tout son possible pour en limiter l'usage.

Toutefois, le système d'exploitation n'a pas le contrôle direct sur la gestion de la mémoire au niveau physique. Ce rôle est dévolu au processeur. C'est donc par le jeu d'une interaction complexe entre le système d'exploitation (qui gère la RAM au niveau logique) et le processeur (qui gère la RAM au niveau physique) que se déroule l'exécution d'un programme.

Le programme est interprété par le processeur, et est composé d'une suite d'opérations élémentaires nommées instructions. Ces instructions consistent principalement en des demandes d'accès à la RAM, des opérations mathématiques et des appels spécifiques au matériel (carte graphique, carte réseau, clavier, écran, disque dur, etc.). Cette suite d'instructions élémentaires exécutées dans l'ordre donne au final le programme, qui peut être un programme du système d'exploitation ou un programme utilisateur.

Le système d'exploitation a aussi pour rôle de faire abstraction du matériel pour les programmes utilisateurs. Ainsi, un programme doit se comporter de la même manière quel que soit le modèle de carte réseau utilisé pour communiquer ou la marque et le type de disque dur contenant les fichiers. Cette abstraction est réalisée par les pilotes de périphériques. Ces pilotes sont en général destinés à un type de matériel particulier et offrent au système d'exploitation un ensemble cohérent d'opérations. Par exemple, tous les pilotes de disque dur permettent de lire le contenu du disque à un endroit donné et tous les pilotes de carte réseau permettent d'envoyer et de recevoir des données. Le détail est caché au système d'exploitation - et donc à l'utilisateur - car seul compte l'ensemble cohérent d'opérations. Le système d'exploitation se repose sur les pilotes de périphérique pour apporter des couches d'abstraction supplémentaires, accessibles aux programmes utilisateurs, par exemple pour la gestion des fichiers, des protocoles réseau... Les programmes utilisateurs ne peuvent accéder au matériel qu'à travers les couches d'abstraction, assurant ainsi la cohérence du système.

Le système d'exploitation doit, pour assurer cette abstraction, avoir un accès exclusif au matériel afin de le contrôler. De fait, presque tous les systèmes d'exploitation sont conçus comme s'ils étaient les seuls à accéder au matériel. Cette notion d'exclusivité est importante pour les solutions de virtualisation : le système virtualisé ne pourra pas accéder au matériel directement, comme s'il était le seul, car c'est le système hôte qui a ce rôle. Il y a donc des solutions de contournement mises en place, qui varient selon les produits et les technologies utilisées.

La séparation en couches du système d'exploitation fait qu'une grande partie du code est indépendante du matériel. Par exemple, le système Linux est porté sur une vingtaine d'architectures et sous-architectures, mais seule une faible partie des millions de lignes de code le composant est spécifique à une architecture. Cette indépendance des différents composants et couches du système d'exploitation facilitent la tâche des solutions de virtualisation. En effet, quelle que soit la technologie utilisée, elle n'entrera en contact qu'avec une faible partie du système d'exploitation, ce qui permet de concentrer les efforts de développement sur ces portions spécifiques.


II-B-2. La virtualisation complète

La virtualisation complète (full virtualization), dénommée ainsi par opposition à la paravirtualisation définie page 16, consiste à émuler l'intégralité d'une machine physique pour le système invité. Le système invité « croit » s'exécuter sur une véritable machine physique. Le logiciel chargé d'émuler cette machine s'appelle une machine virtuelle, son rôle est de transformer les instructions du système invité en instructions pour le système hôte. En effet, comme le montre la figure 1.1 page suivante, la machine virtuelle est un programme comme un autre du point de vue du système hôte, au même titre qu'un navigateur Internet ou un traitement de texte. Or, comme expliqué précédemment, un système d'exploitation doit normalement manipuler le matériel à un niveau très bas. Les programmes utilisateurs n'ont pas d'accès direct au matériel, mais uniquement aux couches d'abstraction. La machine virtuelle émule donc de manière logique (c'est à dire avec du code) tout le matériel habituel de l'architecture de l'ordinateur cible. Sur la figure 1.1 page suivante, le rectangle en fond vert est le système d'exploitation, seule partie à avoir un accès direct au matériel, ici représenté avec un fond bleu. Le rectangle en fond blanc est une application utilisateur, qui ne peut utiliser que la couche d'abstraction du système d'exploitation pour accéder indirectement au matériel.

En pratique, le disque dur de la machine virtuelle est la plupart du temps géré comme un (volumineux) fichier pour le système hôte, alors que la mémoire vive dont le système invité dispose est réservée par le programme de la machine virtuelle. Le reste de l'architecture de l'ordinateur peut varier grandement selon les implémentations, mais on retrouve généralement au moins une carte réseau bas de gamme, un clavier 105 touches « standard » et une carte graphique bas de gamme.

Virtualisation complète
L'utilisation de périphériques bas de gamme s'explique par le fait qu'il y a toujours un nombre minimal d'opérations supportées par toute catégorie de matériel sur un ordinateur : la vitesse de transfert la plus lente pour un disque dur, la résolution d'affichage la plus faible pour une carte graphique, etc. Or comme le comportement de ces périphériques est entièrement implémenté de manière logicielle par la machine virtuelle, émuler un périphérique avec le minimum de fonctionnalités permet de limiter la quantité de code à développer pour en couvrir le comportement. C'est la raison pour laquelle les cartes graphiques et les cartes réseaux sont la plupart du temps aux standards en vigueur dans les années quatre-vingt.

Ce n'est toutefois pas la seule raison de l'émulation de périphériques bas de gamme. En effet, la plupart des évolutions ultérieures du matériel visent à améliorer les performances des périphériques, par exemple en augmentant le débit du disque dur ou la résolution supportée par la carte graphique. Cependant, les optimisations de performances sont dans ce cas sans objet, car elles ne se répercutent de toute manière pas sur un matériel physique en mesure de les supporter. La rapidité du disque dur virtuel est par exemple limitée par la vitesse d'accès au fichier le représentant sur le système hôte.

Le système s'exécutant dans la machine virtuelle est un système d'exploitation à part entière, tel qu'on pourrait en installer sur une machine physique : Microsoft Windows, GNU/Linux, Mac OS X, etc. Cette particularité est la caractéristique principale de la virtualisation complète : les systèmes invités n'ont pas à être modifiés pour être utilisés dans une machine virtuelle utilisant une technologie de virtualisation. Dans la pratique, c'est le cas pour les systèmes d'exploitation et les machines virtuelles les plus répandus.

Le système invité peut à son tour exécuter n'importe quel programme prévu pour ce système, dans la mesure où il ne nécessite pas de matériel non fourni par la machine virtuelle (i.e. pas de carte graphique dernière génération ou de périphérique peu courant). Cette possibilité est due au fait que le système d'exploitation sert (entre autres) de couche d'abstraction entre le matériel et les applications, donc à partir du moment où le système fonctionne correctement, les applications s'exécutant par dessus fonctionneront aussi.

La traduction au vol des instructions du système invité est néanmoins une opération complexe et coûteuse en temps. En effet, la machine virtuelle ne peut pas, dans la plupart des cas, exécuter directement les instructions du système invité sur le système hôte. Les instructions de manipulation de la RAM, par exemple, doivent être interprétées par la machine virtuelle pour aboutir au résultat attendu, car c'est le processeur de la machine virtuelle qui est censé s'occuper de la gestion physique de la mémoire, et non le processeur de la machine hôte.

La machine virtuelle doit donc implémenter en logiciel une gestion complète de la mémoire de l'invité, en utilisant les couches d'abstraction de l'hôte pour accéder à la RAM. Cette empilement de couches réduit significativement les performances, surtout en cas de forte pression sur la mémoire (i.e. quand la mémoire est utilisée de manière intensive : lecture, écriture, déplacement de données, etc.). La figure 1.2 page suivante détaille les couches d'abstraction entrant en jeu pour la gestion de la mémoire.

Dans cette figure, le cadre en bleu foncé représente la couche matérielle ; le cadre vert est le système d'exploitation, qui a un accès privilégié au matériel. Le cadre en fond blanc est une application utilisateur, qui doit utiliser les couches d'abstraction du système d'exploitation - représentées en vert foncé - pour accéder au matériel. Le cadre bleu ciel représente le matériel émulé par la machine virtuelle, qui doit se comporter comme le matériel réel d'un ordinateur pour le système invité.

Couches d'abstraction pour la gestion mémoire
Cet empilage de couches est sensiblement identique pour tous les périphériques émulés par la machine virtuelle. On retrouve, du plus bas niveau au plus haut niveau :

  1. Le matériel ;
  2. Le pilote du matériel pour le système hôte ;
  3. La couche d'abstraction du système hôte ;
  4. Le matériel émulé par la machine virtuelle ;
  5. Le pilote du matériel pour le système invité ;
  6. La couche d'abstraction du système invité.
Les performances de la machine virtuelle sont donc limitées par les performances de la couche d'abstraction du système hôte et par la qualité de l'émulation du matériel implémenté.

La séparation nette entre la machine virtuelle et le système hôte est un avantage certain pour la sécurité et la stabilité de la machine. En effet, comme la machine virtuelle est un simple programme, on peut très facilement limiter la quantité de mémoire qu'elle peut allouer, le temps processeur consommé, sa priorité par rapport aux autres programmes, etc. Toutes les possibilités d'administration et de configuration des applications offertes par le système hôte s'appliquent à la machine virtuelle. Cela permet par exemple d'attribuer une faible priorité à une machine virtuelle mais de lui permettre de réserver plus de mémoire, alors qu'une autre machine virtuelle aura plus de temps processeur à disposition, mais moins de RAM. Bien évidemment, comme les machines virtuelles sont de simples programmes utilisateurs, on peut en exécuter plusieurs à la fois sur le même système hôte, tant que les ressources sont disponibles. Ainsi, une machine multiprocesseur et disposant de suffisamment de mémoire vive et d'espace de stockage peut aisément accueillir plusieurs machines virtuelles, le système hôte répartissant au mieux la charge entre les différents processeurs.

Cependant, du fait de l'empilement de couches d'abstraction et de l'impossibilité pour la machine virtuelle d'accéder directement au matériel, les performances du système invité sont assez éloignées de celles d'un système « natif ». Selon les implémentations, diverses solutions sont utilisées pour accélérer les machines virtuelles, par exemple en passant la plupart des instructions destinées au processeur virtuel directement au processeur physique. Cela accélère la vitesse de calcul du système invité. Il reste cependant le problème des Entrées/Sorties (E/S), c'est à dire les accès au disque, à la RAM, à la carte graphique, à la carte réseau, etc. D'une manière générale, on appelle Entrées/Sorties (I/O ou Input/Output) tout ce qui consiste à transférer des informations ou des données entre un périphérique et le système d'exploitation. Les E/S sont beaucoup plus dures à optimiser, car chaque système d'exploitation a une façon propre de gérer cela. Il faut donc cohabiter étroitement à la fois avec le système hôte pour l'accès réel au matériel et avec le système invité pour que ses accès au matériel soient le plus rapide possible. Cela amène une plus grande complexité de code, et une séparation en couches moins marquée que dans le modèle vu sur la figure 1.1 page 13. Cette « rupture » dans le modèle en couches est exploitée par une autre technologie de virtualisation : la paravirtualisation.


II-B-3. La paravirtualisation

La paravirtualisation (paravirtualization ou encore para-virtualization) est très proche du concept de la virtualisation complète, dans le sens où c'est toujours un système d'exploitation complet qui s'exécute sur le matériel émulé par une machine virtuelle, cette dernière s'exécutant au dessus d'un système hôte. Toutefois, dans une solution de paravirtualisation, le système invité est modifié pour être exécuté par la machine virtuelle. Les modifications effectuées visent à rendre le système émulé « au courant » du fait qu'il s'exécute dans une machine virtuelle. De ce fait, il pourra collaborer plus étroitement avec le système hôte, en utilisant une interface spécifique, au lieu d'accéder au matériel virtuel via les couches d'abstraction. Au final, l'architecture obtenue est plus performante que l'empilement de couches d'abstraction de la figure 1.2.

Le terme para-virtualization a été mentionné pour la première fois dans [WSG02], où les auteurs définissent la paravirtualisation comme la modification sélective de certaines parties de l'architecture virtuelle pour améliorer les performances, la réactivité sous forte charge et la simplicité de conception. L'idée de la paravirtualisation est toutefois plus ancienne que cela. Les premiers gros systèmes utilisant une architecture de virtualisation avaient déjà une technologie similaire, dès les années soixante-dix, même si elle n'avait pas de nom.

En pratique, un système paravirtualisé possède quelques pilotes de périphériques et sous-systèmes modifiés, qui lui permettent de communiquer directement avec la machine virtuelle, sans avoir passer par une couche d'abstraction pour parler au matériel virtuel. Les pilotes paravirtualisés échangent directement des données avec la machine virtuelle, sans avoir à passer par une émulation du comportement du matériel. Les parties du système hôte généralement modifiées pour tirer profit de la paravirtualisation sont la gestion de la mémoire et la gestion des E/S. En effet, ce sont véritablement les deux goulets d'étranglement d'un système virtualisé, du fait du nombre de couches d'abstraction à traverser. Il est donc logique que les optimisations se portent là dessus.

La figure 1.3 page suivante montre la structure d'une machine virtuelle et d'un système hôte supportant la paravirtualisation. Les pilotes non modifiés interagissent toujours avec le matériel émulé par la machine virtuelle (rectangle bleu ciel), alors que les pilotes modifiés communiquent directement les fonctions de la machine virtuelle (rectangle jaune). La simplification qui en résulte permet au système invité de collaborer plus efficacement avec l'hôte : les parties critiques du système communiquent presque directement avec le système hôte, en contournant les couches d'abstraction virtuelles (i.e. le matériel émulé). Le reste de l'architecture est inchangé, la machine virtuelle est toujours une application utilisateur (rectangle blanc) et le système d'exploitation (rectangle vert) est toujours le seul à avoir un accès privilégié au matériel (rectangle bleu).

Paravirtualisation
Les détails sur comment sont réalisées ces optimisations varient selon les implémentations, mais il s'agit en général pour le système invité d'utiliser des appels systèmes ou des instructions spécifiques pour renseigner la machine virtuelle sur les actions à entreprendre. Cette dernière réalise alors ces actions, et communique le résultat au système invité. Le type d'actions à effectuer varie également selon les implémentations, mais on retrouve en général tout ce qui est déplacement de données entre l'hôte et l'invité (accès disque, transfert réseau, etc.) et gestion de la mémoire.

La paravirtualisation apporte un gain de performances avéré, du fait du contournement des couches d'abstraction. En effet, comme le système invité collabore activement avec la machine virtuelle, il ne se comporte plus comme un système d'exploitation à part entière s'exécutant directement sur du matériel. Au contraire, il adapte son comportement pour que les accès au matériel - souvent difficiles à interpréter de manière efficace par la machine virtuelle-soient transformés en des appels directs à cette dernière. De plus, étant donné que seules les couches de bas niveau du système invité ont été modifiées, toutes les applications qui pouvaient fonctionner dans une architecture de virtualisation complète peuvent aussi être utilisées dans une architecture paravirtualisée.

Toutefois, cette augmentation des performances est restreinte à certains systèmes. En effet, comme le système invité doit être modifié3 pour être paravirtualisé, il faut bien évidemment que l'on ait la possibilité de réaliser cette opération de portage. Or, cela nécessite à la fois l'accès au code source du système d'exploitation et la permission du détenteur des droits de le modifier. Si cela ne pose aucun problème pour un système libre (notamment GNU/Linux et les systèmes BSD), il n'en va pas de même pour les systèmes propriétaires, tels que Microsoft Windows et Mac OS. L'usage de la paravirtualisation est donc généralement limité aux systèmes libres, sauf à utiliser une solution de virtualisation propriétaire compatible avec un seul système d'exploitation invité, comme les produits que Microsoft propose pour ses systèmes d'exploitation.

Tout comme la virtualisation complète, la paravirtualisation garde une séparation nette entre le système invité et le système hôte (cf. figures 1.1 et 1.3). De ce fait, seul le système hôte a un accès direct et exclusif au matériel. Le système invité doit donc toujours passer par la machine virtuelle pour accéder au matériel, qui passe à son tour par la couche d'abstraction. On peut donc améliorer davantage le processus en laissant au système invité un accès direct - mais contrôlé - au matériel. C'est le but des systèmes à hyperviseur.


II-B-4. Les systèmes à hyperviseur

L'utilisation d'un hyperviseur (hypervisor) est en quelque sorte l'évolution logique de la paravirtualisation, si l'on recherche encore une amélioration des performances. Dans les technologies précédentes, le système hôte était le seul à avoir un accès direct au matériel ; avec un hyperviseur, le système hôte partage cet accès avec les systèmes invités. Au démarrage de l'ordinateur, c'est normalement le système d'exploitation qui prend la main et contrôle le matériel. Dans le cas de l'utilisation d'un hyperviseur, c'est un système minimaliste - l'hyperviseur - qui prend le contrôle du matériel. Ensuite, il fait appel à un système d'exploitation complet, qui sera donc exécuté par dessus l'hyperviseur. Ainsi, le système d'exploitation doit passer par l'hyperviseur pour tout accès au matériel. On peut donc très facilement instancier un deuxième système d'exploitation, qui passera lui aussi par l'hyperviseur pour l'accès au matériel. Comme les systèmes d'exploitation doivent obligatoirement passer par ce dernier pour tout accès au ma- tériel, l'hyperviseur peut s'assurer qu'ils n'accèdent qu'aux ressources autorisées, sans perturber le fonctionnement des autres systèmes.

Hyperviseur
La figure 1.4 détaille le principe de fonctionnement de l'hyperviseur. À la différence des technologies exposées précédemment, il n'y a cette fois pas d'accès direct au matériel (rectangle bleu) pour le système d'exploitation, uniquement une couche d'abstraction minimale fournie par l'hyperviseur (rectangle vert). L'hyperviseur est le seul à avoir un accès privilégié au matériel. Dans cette représentation, les systèmes cohabitent au même niveau de privilège, uniquement régulés par l'hyperviseur. Toutefois, selon les implémentations, il y a souvent un système privilégié, qui est en général le premier système démarré par l'hyperviseur. Ce système est alors autorisé à modifier les paramètres de l'hyperviseur ou à instancier de nouveaux systèmes invités. À l'opposé, sur d'autres implémentations, la différence entre hôte et invité est inexistante, tous les systèmes ont les mêmes privilèges et l'hyperviseur est alors contrôlé d'une autre manière.

Si les deux technologies vues précédemment (virtualisation complète et paravirtualisation) utilisaient une machine virtuelle pour émuler le matériel, il n'en va pas de même avec un hyperviseur. Chaque système d'exploitation a un accès presque direct au matériel, par l'intermédiaire de l'hyperviseur. Il n'y a donc plus de couche d'abstraction logicielle, le matériel accessible est celui de la machine physique, avec toutes les fonctionnalités qu'il peut offrir. Le gain de performances est parfois significatif, notamment dans le cas des E/S, où le système peut utiliser toutes les extensions des périphériques pour accélérer les transferts.

Ce n'est toutefois pas la seule différence avec les autres technologies de virtualisation : avec un hyperviseur, le contrôle de l'accès au matériel et de l'utilisation des ressources est bien plus fin. En effet, dans les solutions à base de machine virtuelle, le système invité est vu comme un processus par le système hôte, le niveau de contrôle et de suivi est donc celui offert par le système hôte. Ici, c'est l'hyperviseur qui est chargé d'appliquer la politique d'accès aux ressources matérielles. Cela implique un contrôle directement au niveau de l'accès aux ressources. Il peut par exemple limiter la consommation de temps processeur d'un système, ou la quantité de RAM attribuée. La granularité de la configuration n'est pas la même qu'avec une architecture à base de machines virtuelles : au niveau de l'hyperviseur, on contrôlera donc qu'un système ne dérange pas les autres en consommant trop de ressources, alors que dans un système d'exploitation, on s'assurera qu'un programme utilisateur ne dérange pas les autres programmes du système.

Au final, le contrôle des priorités est plus précis, et permet de garantir qu'un système invité isolé n'influera jamais sur l'accès aux ressources d'un autre système. Avec une architecture à base de virtualisation complète, si le système hôte est monopolisé par un processus utilisateur (par exemple un programme consommant énormément de mémoire), les systèmes invités peuvent se voir fortement ralentis dans leur activité.

Tous les systèmes destinés à s'exécuter au dessus d'un hyperviseur doivent être portés, comme les systèmes invités pour la paravirtualisation. Cette opération vise à adapter les couches bas niveau du système d'exploitation pour qu'elles communiquent avec l'hyperviseur plutôt qu'avec le matériel. Les inconvénients sont donc les mêmes que pour la paravirtualisation : il est nécessaire d'avoir accès au code source de tous les systèmes ainsi que l'autorisation du détenteur des droits. En outre, le portage est beaucoup plus lourd à réaliser pour fonctionner sur un hyperviseur. En effet, pour la paravirtualisation, seuls quelques pilotes et sous-systèmes avaient besoin d'être réécrits pour tirer parti de l'accélération. Au contraire, un hyperviseur nécessite la modification de toutes les couches d'accès au matériel ; la complexité du code s'en trouve grandement augmentée, augmentant par là même la difficulté de maintenir le code. Le portage sur un hyperviseur revient quasiment à porter le système d'exploitation sur une nouvelle architecture matérielle.

Les techniques vues jusqu'à présent étaient de complexité croissante, c'est à dire que chaque technologie était un peu plus complexe à mettre en oeuvre et à que la précédente. Avec les technologies ayant trait au cloisonnement, c'est différent. En effet, le cloisonnement était au départ utilisé pour sécuriser et isoler des applications, sans rapport avec le fait d'isoler des systèmes d'exploitation, c'est seulement récemment que l'idée d'utiliser ces techniques pour la virtualisation a vu le jour.


II-B-5. Les techniques de cloisonnement

Une autre pratique répandue dans le domaine de la virtualisation est le cloisonnement. Derrière ce nom se cachent plusieurs technologies visant à séparer fortement les processus s'exécutant sur un même système d'exploitation. Le cloisonnement vise à isoler chaque processus dans un conteneur dont il est théoriquement impossible de sortir. Un processus isolé de la sorte ne saura pas quels autres processus s'exécutent sur le même système, et n'aura qu'une vision limitée de son environnement. Le but principal de cette technologie est d'améliorer la sécurité du système d'exploitation et des applications.

Selon les implémentations, cela peut aller du simple « emprisonnement » dans un environnement volontairement minimal à une image complète du système accessible uniquement au processus isolé. La plupart des systèmes d'exploitation basés sur UNIX proposent un moyen d'isoler les processus. Le plus répandu (et le plus ancien) est la commande chroot, qui permet de créer un environnement minimal contenant uniquement ce qui est strictement nécessaire pour exécuter le programme isolé. Les systèmes basés sur BSD proposent aussi jail (prison), qui est une évolution de chroot, plus sûre, plus complète et plus souple dans son utilisation. L'UNIX de Sun Microsystems, Solaris, propose un système de zones très évolué, plus proche d'une machine virtuelle que d'une simple isolation des processus. Toutes ces technologies ont en commun le fait de conserver exactement la même instance du système d'exploitation accessible aux processus isolés. Ainsi, on ne pourra pas avec le cloisonnement proposer un système d'exploitation différent pour un processus isolé. Par exemple, si le système hôte est Solaris, alors tous les processus s'exécutant à l'intérieur d'une zone auront accès à la même version de ce Solaris.

Les technologies de cloisonnement sont aussi utilisées dans d'autres domaines que les systèmes d'exploitation. Par exemple, le langage Java (de Sun Microsystems) propose une machine virtuelle (qui n'a rien à voir avec les machines virtuelles étudiées ici) qui est un interpréteur pour le langage Java. Cet interpréteur exécute tous les programmes Java dans un conteneur isolé, dont ils ne peuvent pas sortir. Le terme utilisé pour décrire cette technologie est sandbox (bac à sable). Le sandboxing est aussi une technologie de cloisonnement, mais au niveau d'un processus, sans que le système intervienne.

Même si l'engouement pour la virtualisation est assez récent, les technologies de virtualisation et l'idée même de la virtualisation sont presque aussi anciennes que l'informatique. La section suivante fera un bref historique de la virtualisation.


II-C. Historique

Les premiers ordinateurs, qui occupaient plusieurs pièces d'un bâtiment, n'étaient pas faits pour exécuter plusieurs programmes à la fois. On concevait un programme (qui était à l'époque une simple succession de calculs), on le mettait dans la file d'attente des programmes, et quand le système d'exploitation avait fini de traiter un programme, on lui donnait le suivant dans la liste.


II-C-1. Premiers pas

Très vite, dès la fin des années cinquante, l'idée de pouvoir exécuter plusieurs programmes en parallèle voit le jour. On parle de temps partagé (time sharing), de multiprogrammation, etc. L'idée était de pouvoir faire cohabiter plusieurs programmes au même moment, ayant tous accès au même matériel, sans qu'ils ne se gênent mutuellement. La virtualisation est très proche de concept.


II-C-2. Machines virtuelles

Au milieu des années soixante, IBM effectue des recherches sur les systèmes virtualisés avec le projet M44/44X. L'architecture du système se basait sur des systèmes d'exploitation virtualisés (nommés 44X) s'exécutant au dessus du matériel (une machine M44). Les systèmes invités étaient gérés par une simple multiprogrammation. En 1967 est lancé, toujours par IBM, le système CP-40, le premier système offrant une virtualisation complète. Le CP-40 sera suivi par plusieurs évolutions, amenant chacune de nouvelles fonctionnalités pour les utilisateurs. On peut notamment citer le système VM/370, qui a connu un très fort succès dans les entreprises, et est parfois encore en usage dans certaines entreprises aujourd'hui.


II-C-3. Amélioration des technologies

Après le succès des machines virtuelles introduites par IBM, les technologies ont assez peu évolué. Le système hôte a vite été réduit à l'état de simple arbitre entre les systèmes invités, amenant la notion d'hyperviseur.

Toutefois, toutes ces technologies de virtualisation étaient réservées au monde professionnel, destinées à être utilisées sur des mainframes* coûtant plusieurs millions de dollars.

Parallèlement à cela, le monde de la recherche (souvent financé par ces mêmes entreprises) a continué à étudier différentes possibilités pour améliorer les performances et à essayer de nouvelles technologies. La plupart de ces travaux de recherche sont toutefois restés assez confidentiels et n'ont que rarement été transposés sur un produit.


II-C-4. Intérêt du grand public

L'orientation « grand public » des technologies de virtualisation est beaucoup plus récente. Dans les années quatre-vingt-dix, l'intérêt pour les émulateurs de consoles de jeu ainsi que l'explosion du marché de l'informatique personnelle (les ordinateurs de type PC) ont fait prendre conscience aux entreprises qu'il y avait un marché pour la virtualisation sur PC. Des sociétés ont alors commencé à créer des produits de virtualisation basés sur des machines virtuelles pour les « petites » entreprises - c'est à dire celles ne pouvant s'offrir des serveurs à plusieurs millions de dollars - et pour les particuliers.

À partir de ce moment là, les technologies ont vraiment progressé, avec l'arrivée de nouveaux acteurs toujours prêts à innover pour se démarquer des concurrents.


II-D. Acteurs majeurs

Comme vu précédemment, les acteurs principaux dans le domaine de la virtualisation sont partagés entre les très grandes entreprises fournissant des solutions pour leurs ordinateurs d'un côté et les entreprises fournissant des solutions orientées PC de l'autre. Les deux types d'activité ne sont que très rarement en concurrence, car les buts visés ne sont pas les mêmes.

Les grandes entreprises sont celles qui fournissent des machines pour les centres de calcul et les mainframes. Les acteurs les plus connus sont IBM - qui a un fort historique de virtualisation -, HP, Sun, Bull, etc. Toutes ces sociétés fournissent des systèmes de virtualisation fonctionnant exclusivement avec leur propre architecture matérielle. Les technologies utilisées diffèrent selon les systèmes, mais en général ce sont des technologies à base de virtualisation complète ou d'hyperviseur.

Sur les architectures de type PC, il y a plus de sociétés proposant des produits et donc plus d'offres de virtualisation. On peut notamment citer Microsoft, qui a racheté la solution de virtualisation de Connectix en février 2003. Ce rachat a ensuite donné lieu à la diffusion de Virtual PC et Virtual Server, produits permettant de virtualiser des systèmes à base de Windows, respectivement pour un ordinateur personnel et pour un serveur. La version pour serveurs offre également la possibilité de virtualiser GNU/Linux.

La société VMware édite plusieurs produits à destination des entreprises souhaitant virtualiser leurs serveurs, qui couvrent sensiblement les mêmes applications que les solutions de Microsoft, mais avec en plus la possibilité de faire fonctionner leurs produits avec le système GNU/Linux en tant que système hôte.

Ces deux sociétés fournissent des solutions propriétaires destinées aux particuliers et aux entreprises. Les technologies utilisées sont soit de la virtualisation complète soit de la paravirtualisation, en fonction des produits et systèmes.

Du côté de la communauté du logiciel libre, il y a énormément de projets de virtualisation, ayant des buts variables. Certains d'entre eux sont soutenus par une société, qui fournit un service payant pour les clients le souhaitant. Les plus connus sont :

Bochs (prononcer « box ») Bochs est un émulateur très complet de l'architecture PC traditionnelle (processeur Intel) ;

KVM soutenu par la société Qumranet, KVM se veut une solution de virtualisation performante et facile à administrer ;

Linux-VServer projet de virtualisation destiné à fonctionner sur le système d'exploitation GNU/Linux ;

OpenVZ soutenu par la société Virtuozzo, OpenVZ est une solution de virtualisation visant à obtenir les meilleures performances possibles ;

QEMU créé et développé par Fabrice BELLARD, QEMU est un projet visant à offrir une machine virtuelle complète pour plusieurs architectures matérielles, y compris l'architecture PC ;

Xen soutenu par la société XenSource, Xen vise à proposer un solution performante pour la virtualisation de serveurs ;

Ces projets sont tous à des états d'avancement différents, certains sont d'ores et déjà utilisables en production alors que d'autres sont encore en phase de développement. Avec l'attrait récent des entreprises et du grand public pour la virtualisation, il n'est guère étonnant de constater qu'il y a eu plusieurs avancées récentes dans les technologies utilisées.


II-E. Évolutions récentes

Que ce soit dans la communauté du logiciel libre ou dans le domaine du logiciel propriétaire, toutes les solutions de virtualisation sur le marché ont fait des progrès considérables ces dernières années.

Du côté du logiciel propriétaire, l'arrivée du géant Microsoft comme éditeur de solutions de virtualisation a relancé la course au développement de technologies performantes. En effet, la plupart des concurrents de la société Microsoft ont peur qu'il ne réitère ce qu'elle avait fait pour Netscape Navigator, alors en concurrence avec son logiciel Internet Explorer : diffuser en masse, avec son système d'exploitation, un produit techniquement inférieur dans l'espoir d'affaiblir, voire d'éliminer, leurs concurrents. Cette stratégie lui avait plutôt réussi par le passé, aussi les craintes des éditeurs de produits de virtualisation pour la plate-forme Windows sont légitimes. Microsoft a également annoncé que la prochaine version de son système d'exploitation pour serveur, pour l'instant encore dénommée Longhorn, pourra fonctionner avec un hyperviseur, développé en collaboration avec la société XenSource.

En parallèle, la communauté du logiciel libre continue elle aussi à faire évoluer les différents projets. Récemment, une architecture visant à faciliter la paravirtualisation, nommée paravirt_ops, a été intégrée au noyau Linux. Elle permet à toutes les solutions de virtualisation de faire fonctionner un système GNU/Linux avec paravirtualisation sans avoir à modifier le code du noyau, mais simplement en utilisant paravirt_ops pour exploiter les appels paravirtualisés. Il est à noter que les développeurs de Xen et de VMware ont collaboré étroitement avec les développeurs de Linux pour l'élaboration de cette fonctionnalité.

De même, une interface pour la virtualisation des Entrées/Sorties, nommée virtio, est actuellement en cours de conception par les développeurs du noyau Linux. Cette interface permettra d'offrir une base commune pour les E/S, pour toutes les solutions de virtualisation, y compris pour la paravirtualisation et les hyperviseurs.

Toujours dans la communauté des développeurs du noyau Linux, Rusty Russell, développeur et mainteneur du pare-feu (firewall) de Linux, a récemment diffusé Lguest. Lguest est un projet de paravirtualisation centré sur GNU/Linux, qui vise à servir de base pour tester toutes les fonctionnalités en développement. C'est par exemple ici que la couche paravirt_ops a été testée et améliorée avant d'être intégrée au noyau. Lguest doit être vu comme une plate-forme de tests, et non comme un projet de paravirtualisation ayant pour but d'être utilisé en production. Le projet Lguest sera intégré dans la version 2.6.23 du noyau (prévue pour la fin de cet été), lui assurant une diffusion encore plus importante et potentiellement l'augmentation du nombre de développeurs intéressés par la virtualisation sous GNU/Linux.

Les fondeurs de processeurs de la famille PC-c'est à dire Intel et AMD-ont eux aussi compris l'intérêt qu'il y avait à développer les possibilités de virtualisation. En effet, les processeurs utilisés sur les architectures PC 4 sont notoirement difficiles à émuler de manière performante, du fait du nombre d'instructions nécessitant un niveau de privilège élevé (donc hors d'atteinte d'une machine virtuelle s'exécutant comme un processus utilisateur), ainsi que de la façon dont la mémoire est gérée. Intel et AMD ont donc décidé d'intégrer à leurs nouvelles générations de processeurs des instructions supplémentaires visant à améliorer les performances des solutions de virtualisation.

Ces nouvelles instructions, appelées VT (Virtualization Technology) chez Intel et SVM (Secure Virtual Machine) chez AMD, sont expliquées en détail dans l'article [NSL+06] et dans la documentation technique des nouveaux processeurs AMD, [AMD06]. Une machine virtuelle tirant parti de ces nouvelles instructions s'exécute à un niveau de privilège intermédiaire, plus élevé que celui d'une application utilisateur normale mais moins que celui du système d'exploitation. Dans ce niveau de privilège, la plupart des instructions du système invité sont exécutables directement, sans intervention de la machine virtuelle, le processeur s'occupant de tout. Seul un faible nombre d'instructions obligent encore le processeur à repasser la main à la machine virtuelle, qui émule alors le comportement attendu de manière logicielle. En utilisant les instructions de virtualisation les gains sont significatifs, car la machine virtuelle est déchargée d'une partie conséquente de son travail d'émulation par le processeur, qui est évidemment beaucoup plus rapide.

Toutefois, Intel et AMD vont encore plus loin, car récemment, ils ont tous les deux mis au point des technologies pour décharger encore plus la machine virtuelle, avec l'introduction de la virtualisation pour les E/S. Cette technologie, décrite dans [AMD07] et [AJM+06], permet au processeur d'effectuer tout le travail de traduction des adresses lors d'un processus d'E/S. Les traductions d'adresses effectuées par la machine virtuelle étaient le goulet d'étranglement des E/S. Avec une machine virtuelle tirant parti de ces fonctionnalités, le gain de performances est encore plus important. L'interface virtio devrait pouvoir tirer parti de ces nouvelles fonctionnalités.

On peut cependant regretter que les instructions de virtualisation d'Intel et d'AMD, même si elles ont le même usage et visent les mêmes buts, sont incompatibles et ne suivent pas de standard défini. C'est donc aux projets souhaitant bénéficier de ces instructions d'implémenter une couche d'abstraction supplémentaire pour tirer parti des deux types d'instructions de manière transparente pour l'utilisateur.

Intel vient également d'investir un peu plus de 200 millions de dollars en actions chez VMware au début du mois de juillet, lui assurant ainsi 2,5 % des parts de la société ainsi que la nomination d'un représentant d'Intel au conseil d'administration de VMware.

Parallèlement, la société VMware a effectué son introduction en bourse au mois d'août 2007, mettant environ 950 millions de dollars d'actions sur le marché, soit 10 % des parts de l'entreprise.

Ces deux substantielles rentrées d'argent permettront à la société VMware d'investir dans la recherche sur de nouvelles technologies, en collaboration avec Intel.

Toujours pendant le mois d'août 2007, la société XenSource, éditrice de la solution de virtualisation Xen, s'est faite racheter par Citrix, un des leaders dans le domaine de la fédération d'applications, c'est à dire la concentration des applications sur un serveur central, avec déport de l'affichage sur des clients légers. Citrix vise ainsi à étendre son offre de produits à la virtualisation pour offrir une gamme de produits complète, allant de la centralisation d'applications à la centralisation de systèmes d'exploitation.

La société Qumranet a diffusé il y a peu le logiciel KVM, qui est basé sur QEMU pour la machine virtuelle. Cependant, KVM tire parti des instructions de virtualisation offertes par les nouveaux processeurs x86, ce qui amène un gain de performances significatif par rapport à une solution uniquement basée sur QEMU. Le tour de force de Qumranet a été de faire intégrer KVM au noyau Linux, lui assurant ainsi une grande diffusion et un fort succès auprès de la communauté.

Une jeune société nommée Virtual Iron, financée en grande partie par Intel, vient de sortir un nouveau produit de virtualisation, destiné à concurrencer les produits de VMware et XenSource. Ce nouveau logiciel utilise les instructions de virtualisation des nouveaux processeurs Intel et AMD. Il se base sur le code source du projet Xen et rajoute une interface de supervision au dessus des systèmes virtualisés pour en faciliter l'administration.

Tous ces investissements et acquisitions en l'espace de quelques mois montrent qu'il y a un réel mouvement de fond autour de la virtualisation. Toutes les entreprises veulent en faire partie et proposer une solution à leurs clients. Le marché de la virtualisation est en pleine croissance, et cela ne fait que commencer.

Étant donné le nombre de produits et de technologies disponibles actuellement sur le marché, il est nécessaire de bien étudier les caractéristiques des différents produits avant de choisir. En effet, selon les besoins et contraintes de la société, les solutions à adopter ne seront pas les mêmes.

Le chapitre suivant sera consacré à l'étude des besoins d'une PME spécialisée dans l'hébergement de sites web en matière de virtualisation, puis à l'analyse détaillée de quelques solutions de virtualisation.


III. Analyse de solutions majeures de virtualisation

Le choix de la bonne solution de virtualisation dans l'absolu est très difficile, et la pléthore de projets de virtualisation disponibles ne facilite pas la décision. C'est pourquoi il est nécessaire de réduire le champ d'étude aux solutions applicables dans un cas bien spécifique. Dans ce livre blanc, nous nous limiterons aux solutions de virtualisation utilisables pour une PME ayant comme principale activité l'hébergement d'applicationsWeb. La virtualisation pour les postes de bureau, comme par exemple pour le développement et le test d'applications Web, sera néanmoins survolée.


III-A. Expression des besoins et contraintes

Pour la plupart des petites entreprises faisant de l'hébergement, le parc de serveurs est très hétérogène, des machines récentes côtoyant des machines d'ancienne génération au fil des achats de nouveau matériel. Le taux d'utilisation des serveurs est quant à lui très disparate, certains serveurs étant déjà très chargés alors que d'autres sont loin des limites d'utilisation. Cet écart s'explique en partie par le type d'applications hébergées - certaines drainant plus d'utilisateurs que d'autres -; mais aussi par le type de technologie utilisée par les applications (PHP, framework PHP, Ruby on Rails, ...).

Tous ces facteurs rendent très intéressants la possibilité de se détacher des machines physiques pour la gestion des applications hébergées. Il s'agit donc d'arriver à répartir le plus uniformément possible le taux d'utilisation sur l'ensemble de ses serveurs.


III-A-1. Contraintes

Dans le monde des serveurs et de l'hébergement, le logiciel libre est prédominant, il est donc tout à fait logique de se tourner vers des solutions de virtualisation libres pour l'hébergement. En effet, beaucoup de sociétés d'hébergement se basent sur des technologies libres (Linux, Apache, PHP, MySQL, PostgreSQL, etc.). Par conséquent, la solution de virtualisation utilisée doit obligatoirement être libre.

De plus, les systèmes d'exploitation utilisés pour l'hébergement à l'aide de technologies libres sont la plupart du temps des systèmes GNU/Linux. Le projet retenu doit donc bien évidemment fonctionner sur GNU/Linux, permettre de faire fonctionner des systèmes invités GNU/Linux et être facilement intégrable à la distribution GNU/Linux utilisée par l'enterprise.


III-A-2. Besoins

Si les contraintes énoncées précédemment sont des conditions sine qua non pour utiliser le produit choisi, les besoins ne sont pas tous aussi indispensables, et il est envisageable de faire quelques concessions. Les besoins typiques d'une PME varient grandement en fonction de l'activité de celle-ci. On peut notamment lister deux grandes catégories : l'hébergement d'applications web d'une part, et le développement d'applications web d'autre part.

Pour l'hébergement

Tout d'abord, la solution choisie doit faciliter la création d'images systèmes complètes. Par image système complète, on entend la base du système d'exploitation ainsi que tous les logiciels nécessaires pour héberger une application (serveur web, base de données, etc.) dans une configuration donnée. On doit pouvoir très simplement créer et configurer un nouveau système virtuel, de manière à pouvoir déployer rapidement un environnement sur un serveur.

Avec la création rapide d'image système vient aussi le besoin de pouvoir déployer rapidement ces images sur les serveurs cibles, sans avoir à passer du temps à configurer le logiciel de virtualisation pour cela. Idéalement, il suffirait de déplacer l'image du système et éventuellement un simple fichier de configuration sur un serveur pour pouvoir instancier un nouveau système invité. La solution retenue doit donc faciliter la répartition des applications sur les serveurs physiques. Il y a plusieurs méthodes pour cela, mais la plus répandue est la migration des systèmes invités entre deux machines physiques. Il suffit en général d'arrêter le système invité, de déplacer l'image disque du système sur la nouvelle machine et redémarrer le système invité. On peut aussi envisager une migration « à chaud » (live migration), où le système invité n'a pas à être effectivement arrêté pendant la migration, juste brièvement mis en pause.

Afin de faciliter l'administration, il est nécessaire que l'on puisse contrôler facilement l'état des systèmes invités. En effet, la plupart des entreprises ont un système de surveillance des machines et des services, et l'intégration de la solution de virtualisation à ce système serait appréciable. Il est tout à fait envisageable d'avoir à programmer soimême cette intégration, mais il faut que cela soit possible, c'est à dire que la solution utilisée permette d'accéder simplement aux informations souhaitées.

Toujours dans l'optique de faciliter les tâches d'administration, il est indispensable que l'on puisse contrôler le produit utilisé entièrement par la ligne de commande. L'administration à distance sera ainsi possible, ce qui est indispensable quand il s'agit de vérifier un point de détail sur un serveur situé dans un datacenter éloigné géographiquement. De la même manière, l'obligation d'avoir une interface graphique sur la machine hôte est impensable : on doit pouvoir se servir de l'intégralité des fonctionnalités de la solution choisie sans écran ni affichage graphique ; un simple accès à distance en ligne de commande doit suffire.

Au niveau des performances, l'écart entre un système virtualisé et un système « natif » devrait être le plus faible possible. La performance d'un serveur web est la plupart du temps mesurée par son temps de réponse à une requête. Ce temps de réponse dépend généralement de :

  • la vitesse du processeur ;
  • la vitesse des Entrées/Sorties ;
  • la vitesse du matériel sous-jacent (disque dur, mémoire, carte réseau).
Le point le plus critique pour une solution de virtualisation est la vitesse des E/S. En effet, si la rapidité de traitement d'un système invité est quasiment celle du processeur de la machine physique - à quelques pour-cent près -, il n'en va pas de même pour les E/S. Il faut donc que la solution retenue soit performante pour le traitement des Entrées/Sorties, afin d'avoir un système invité à même d'héberger des applications exigeantes à ce niveau.

Il doit également être possible d'attribuer très rapidement une adresse IP publique à un système invité. En effet, une activité d'hébergement implique une connectivité à Internet, il faut donc que les systèmes invités soient joignables directement. Il suffit en pratique que la solution de virtualisation offre la possibilité d'avoir (au moins) une carte réseau virtuelle pour chaque système invité et qu'elle se charge de router le trafic à la bonne carte réseau virtuelle. Il est en effet souhaitable de conserver une IP publique par système d'exploitation (système hôte compris), afin de faciliter l'administration à distance. Avec un système d'exploitation GNU/Linux, ce n'est pas un problème, il existe plusieurs solutions pour obtenir ce résultat ; tout ce qui importe c'est que la solution de virtualisation soit en mesure d'exploiter ces mécanismes pour proposer les fonctionnalités voulues.

Les besoins en matière d'hébergement sont pour la plupart suffisamment généralistes et évidents pour que l'immense majorité des solutions de virtualisation les prennent en compte directement.

Pour le développement

Dans le contexte du développement web, la virtualisation est principalement utilisée pour effectuer des tests et pour accélérer le développement en local (par opposition au développement centralisé sur un unique serveur).

Tout d'abord, afin de faciliter le développement en local, il est nécessaire que chaque développeur dispose de sa propre machine virtuelle. Ainsi, il effectue les modifications et visualise le résultat sur sa propre machine virtuelle, sans avoir à envoyer ses modifications au serveur central. Une fois les modifications validées, il pourra les enregistrer et les envoyer sur le serveur central. Il faut donc que la solution de virtualisation choisie soit facile à déployer dans ce contexte d'utilisation, notamment au niveau de l'environnement et de la configuration nécessaire pour l'application web développée. On peut tout à fait rassembler tous les systèmes invités des développeurs sur une seule machine physique située dans le réseau local de l'entreprise, il n'est pas nécessaire que la solution fonctionne sur leur machine de travail.

De même, il est parfois nécessaire de déployer un système invité qui hébergera une version donnée d'une application web, qui n'est pas forcément celle qui est hébergée en production ou en test pour le client. Il faut donc que les développeurs puissent facilement instancier un système virtuel préconfiguré pour une application donnée, et qu'ils puissent ensuite facilement restaurer la version souhaitée.

Une autre application de la virtualisation serait la gestion de tests automatisés. En effet, les développeurs souhaitent avoir une architecture complète pour la réalisation de tests pour chaque application en cours de développement. Ce serveur installerait chaque application avec l'environnement qui lui est associé, à la demande. Une fois le système invité démarré et l'application désirée déployée, une batterie de test serait exécutée, et les résultats seraient envoyés à l'équipe de développement de l'application.

Derrière tous ces besoins se dessine un thème récurrent : la facilité de déploiement d'une image système dans une configuration donnée. C'est donc là dessus que devront se porter tous les efforts de recherche et de mise au point d'une architecture de virtualisation. Maintenant que les besoins pour l'hébergement et le développement sont connus, on peut passer à l'étude des solutions de virtualisation qui pourraient être utilisées.


III-B. Autres solutions

Avant de détailler les projets de virtualisation retenus pour l'analyse, il semble important de lister ci-dessous quelques projets qui, mêmes s'ils ne remplissent pas tous les critères de choix listés précédemment, méritent d'être mentionnés.


III-B-1. Bochs

Bochs (prononcer « box ») est un émulateur très complet et multi plate-forme de l'architecture PC moderne. Il utilise la virtualisation complète. La première version publique de Bochs date de 1994. Il a été racheté puis « libéré » - c'est à dire diffusé sous une licence libre - en mars 2000 par la société Mandriva.

Contrairement à la plupart des logiciels de virtualisation, Bochs interprète toutes les instructions du système invité. En effet, la majorité des machines virtuelles passent la plus grande partie des instructions directement au processeur de la machine hôte, pour avoir des performances proches de celles du système hôte. Toutefois cela a un coût sur la complexité du code d'interprétation, qui doit être adapté pour chaque architecture hôte pour prendre en compte toutes les spécificités. Le projet Bochs vise exactement l'inverse : l'intégralité du code est interprété par Bochs, qui fait ensuite appel au processeur hôte pour réaliser les tâches demandées par le système invité.

L'avantage est que le code d'interprétation n'a à être écrit qu'une seule fois, dans un langage de programmation portable. On peut alors porter très facilement Bochs sur une nouvelle architecture hôte, sans avoir à modifier le code d'interprétation. L'inconvénient est par contre des performances moindres que d'autres projets de virtualisation complète, à cause de l'interprétation de toutes les instructions.

De par son code source très clair et très portable, Bochs est un sujet d'étude très utilisé, notamment pour comprendre comment l'émulation complète fonctionne et comment on réalise un émulateur de l'architecture PC. Ses faibles performances le rendent toutefois inutilisable pour autre chose que des tests et de la recherche.


III-B-2. VMware Server

La société VMware édite plusieurs logiciels de virtualisation, pour les utilisateurs finaux ou pour les serveurs. Elle est leader dans le marché de la virtualisation pour PC. Le produit à destination des entreprises est VMware Server, solution de virtualisation complète pour serveur sous GNU/Linux et/ou Microsoft Windows.

Les performances et les fonctionnalités offertes par VMware Server le placent parmi les meilleures solutions de virtualisation pour l'architecture PC. On peut optionnellement activer des modules de paravirtualisation pour augmenter davantage les performances.

Si ce n'était pour sa licence non-libre et relativement restrictive5, VMware aurait tout à fait sa place parmi les solutions étudiées.

La section suivante étudiera les solutions de virtualisation qui pourraient être utilisées en production par une PME.


III-C. QEMU


III-C-1. Présentation

QEMU est le projet de virtualisation complète libre le plus abouti actuellement. Il a été fondé par Fabrice BELLARD et diffusé à la communauté en 2003. Fabrice BELLARD est également connu pour avoir fondé le projet FFmpeg, une suite d'utilitaires dédiés au traitement et à la conversion de flux numériques (vidéo et audio). À l'heure actuelle, M. BELLARD est toujours le mainteneur et développeur principal de QEMU, secondé par une communauté active.


III-C-2. Technologies

Techniquement, QEMU utilise la virtualisation complète (cf. tableau 2.1 page suivante), et il supporte de nombreuses architectures cibles (i.e. émulées), parmi lesquelles les processeurs x86 et l'architecture PC. Il fonctionne sur les plates-formes les plus courantes (Microsoft Windows, GNU/Linux, Mac OS X) et est très simple d'utilisation.

L'article [Bel05] détaille précisément les choix techniques effectués pour émuler l'architecture PC, ainsi que les difficultés rencontrées pour virtualiser le processeur (difficultés communes à tous les projets de virtualisation pour x86). QEMU peut en option utiliser un module d'accélération système pour améliorer les performances. Ce module s'appelle kqemu (kernel-QEMU) et est disponible pour Windows et GNU/Linux. Il s'intègre au noyau (ou dans les services dans le cas de Windows) et permet à QEMU de contourner certaines couches d'abstraction du système hôte, amenant ainsi un gain de performances.

Récapitulatif des technologies utilisées par QEMU

III-C-3. Fonctionnalités

Ce qui distingue QEMU de solutions plus intrusives (comme Linux-VServer ou Xen) est sa grande simplicité