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

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 finalement 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 facilite 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.

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.

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éseau 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. Cet 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é.

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 :

• Le matériel ;
• Le pilote du matériel pour le système hôte ;
• La couche d'abstraction du système hôte ;
• Le matériel émulé par la machine virtuelle ;
• Le pilote du matériel pour le système invité ;
• 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.

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. Finalement, l'architecture obtenue est plus performante que l'empilement de couches d'abstraction de la figure 1.2.

Le terme paravirtualisation 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 passé 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).

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é³ 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.

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 matériel, l'hyperviseur peut s'assurer qu'ils n'accèdent qu'aux ressources autorisées, sans perturber le fonctionnement des autres systèmes.

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.

Finalement, 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 œuvre 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.

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.

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.

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.

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.

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.

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'entreprise.

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'images 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 soi-mê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 tests 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.

Bochs (prononcer « box ») est un émulateur très complet et multiplateforme 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ée 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.

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 restrictive⁵, 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.

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.

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 plateformes 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.

Ce qui distingue QEMU de solutions plus intrusives (comme Linux-VServer ou Xen) est sa grande simplicité d'usage. En effet, comme c'est un projet utilisant la virtualisation complète, il y a un simple programme à exécuter sur le système hôte pour obtenir une nouvelle machine virtuelle contenant un système invité.

Un des gros points forts de QEMU est la flexibilité qu'il offre au niveau des options pour la configuration de la machine virtuelle. La section suivante détaillera la gestion des interfaces réseau et du trafic réseau en général, car c'est un des points forts de QEMU. L'étendue de ses possibilités dans ce domaine a été l'un des critères pour sa sélection dans ce comparatif.

Gestion du réseau

QEMU offre plusieurs modes de fonctionnement pour la connexion du système invité au réseau. La première méthode, la plus simple, consiste à laisser un accès limité au réseau depuis la machine virtuelle. Dans ce mode - appelé user mode networking - QEMU offre un réseau privé au système invité, et filtre les communications. Du point de vue du système invité, il y a un réseau privé simple, avec un serveur DHCP qui attribue des adresses IP et une passerelle pour accéder à Internet. Ce mode est totalement indépendant du système hôte, le DHCP et la passerelle sont émulés par QEMU. Le déroulement du processus est le suivant :

• QEMU est initialisé en user mode networking ;
• le système invité démarre ;
• à l'initialisation du réseau, le système invité effectue une requête DHCP pour configurer la carte réseau ;
• la pile user mode de QEMU répond à la requête DHCP et attribue une adresse IP à la carte réseau du système invité ;
• une fois la carte configurée, le système invité peut émettre du trafic sur le réseau virtuel, comme s'il était connecté à un véritable réseau ;
• quand le système invité émet du trafic (par exemple quand une application utilisateur se connecte à Internet), QEMU récupère le trafic réseau et le passe au système hôte, qui se charge alors de l'émettre sur le véritable réseau physique.

Du point de vue du système hôte, QEMU est un programme comme un autre, y compris pour l'accès au réseau. Cette particularité fait que la configuration user mode est très simple, QEMU se chargeant de tout. Par contre, il n'est pas possible de faire fonctionner un programme hébergeant un service réseau (par exemple un serveur Web) avec ce mode, sauf à dire explicitement à QEMU d'écouter sur un port donné et d'avoir l'autorisation du système hôte pour écouter sur ce port. Ce mode est donc réservé aux tests rapides, ou aux cas d'utilisation ne nécessitant qu'un usage basique de l'accès à Internet.

Le deuxième mode proposé est le mode TAP (ou tuntap). Dans cette configuration, une interface réseau virtuelle est créée sur le système hôte. Cette interface virtuelle est ensuite reliée à l'interface physique par un pont (bridge), qui servira à faire passer le trafic réseau de l'une vers l'autre. QEMU relie alors le système invité à l'interface virtuelle. Dans ce mode de fonctionnement, il y a donc une interface virtuelle assignée à une machine virtuelle. Comme cette interface est reliée à une interface physique, on peut lui envoyer du trafic réseau, ce qui offre la possibilité d'héberger des serveurs dans la machine virtuelle. Chaque machine virtuelle ainsi créée dispose donc de son adresse IP au sein du réseau. Les systèmes invités deviennent indissociables de véritables machines, du point de vue du réseau.

Ce fonctionnement est toutefois un peu plus complexe à mettre en place que le mode précédent, et nécessite des privilèges administrateurs, au moins pour la création de l'interface virtuelle et le lien avec l'interface physique. C'est le mode de connexion au réseau le plus intéressant, dans l'optique de l'hébergement de services au sein des systèmes invités.

Une autre particularité intéressante de QEMU est la possibilité de relier les systèmes invités entre eux, indépendamment du réseau physique sous-jacent. Chaque instance de QEMU démarrée peut se voir préciser un numéro de VLAN (réseau virtuel). De cette manière, seules les machines virtuelles partageant le même numéro de VLAN peuvent communiquer entre elles. On peut ainsi relier les instances QEMU entre elles même si elles sont sur des machines physiques différentes.

QEMU dispose d'énormément de possibilités en ce qui concerne la gestion du réseau, mais ce n'est pas son seul point fort. En effet, il y a quantité d'options paramétrables au lancement du programme, qui contrôlent le type de matériel émulé, la connectivité au réseau, les disques et répertoires à rendre accessibles au système invité, etc.

Gestion des images systèmes

En ce qui concerne les images systèmes, QEMU se base sur des images disques complètes, avec son propre format de stockage (QCOW - QEMU Copy On Write). Il y a un utilitaire qui permet de créer des images de la taille souhaitée. Les images au format QCOW sont « creuses », c'est-à-dire qu'à la création du fichier, il n'occupe que quelques octets. Il grossira au fur et à mesure que le système invité remplit l'espace disque. Cela permet d'économiser de la place et de ne pas avoir un énorme fichier de plusieurs gigaoctets à déplacer quand il y a seulement une image système minimale installée. À titre d'exemple, une distribution Debian minimale installée dans une image QCOW de 5 gigaoctets occupe sur le disque seulement 700 mégaoctets.

L'inconvénient principal des images disques est qu'il est relativement difficile d'accéder au contenu de l'image depuis le système hôte. En effet, le format QCOW n'est pas une simple image de disque dur. Si l'on souhaite pouvoir accéder aux fichiers dans une image disque créée avec QEMU, il y a deux alternatives possibles : la première est de démarrer le système invité installé sur l'image disque et d'effectuer les modifications. Ce n'est pas toujours possible, ni particulièrement rapide. La seconde possibilité est de créer les images disques au format « brut » (raw), c'est-à-dire une copie conforme d'un disque dur. Par contre, avec cette solution, une image disque de 5 gigaoctets occupera effectivement 5 gigaoctets sur le disque.

Le projet a su attirer de nombreux contributeurs, parmi lesquels Rusty Russell (auteur de Lguest, mentionné page 27). L'activité autour de QEMU est toujours importante et les contributions externes sont relativement régulières, gage que QEMU dispose d'une forte communauté. Cette communauté est rassemblée autour d'une liste de diffusion, d'un forum de discussion et d'un wiki*. De plus, il y a plusieurs projets autour de QEMU, qui visent pour la plupart à offrir une interface aux nombreuses options de ligne de commande du programme.

De par sa robustesse et ses fonctionnalités étendues, QEMU est réutilisé dans plusieurs solutions de virtualisation. On peut notamment citer :

KVM la partie utilisateur de KVM utilise une version légèrement modifiée de QEMU;

Xen lorsque Xen est utilisé avec les processeurs supportant les instructions de paravirtualisation, QEMU est la machine virtuelle se chargeant des E/S ;

Virtualbox la solution de virtualisation Virtualbox se base également sur QEMU pour la réalisation des E/S.

QEMU est diffusé sous la licence GNU GPL. Jusqu'à récemment, le module d'accélération kqemu était diffusé sous une licence interdisant la redistribution, mais il est dorénavant distribué sous la même licence. QEMU est donc un logiciel libre parfaitement compatible avec les contraintes énoncées précédemment.

Tout d'abord, du fait de la grande complexité du code réalisant l'émulation du processeur, il sera difficile de comprendre et modifier les sources du programme, si jamais le besoin se fait sentir. L'évolution du projet est donc aux mains des personnes à même de comprendre l'architecture bas niveau de QEMU.

Toujours au niveau du code, il est dit dans [Bel05] que QEMU est dépendant de la version du compilateur GCC (GNU Compiler Collection, le compilateur du projet GNU). En effet, le projet se base sur GCC pour générer des extraits de code à la volée durant la compilation. Ces bouts de code seront ensuite utilisés pendant la phase d'émulation de certaines instructions du processeur. Or, à chaque changement de version du compilateur, le code généré change légèrement, « cassant » d'une certaine manière tout l'alignement prévu par QEMU. C'est pourquoi il est nécessaire de compiler QEMU avec des versions très précises de GCC : les versions 3.2 ou 3.4. Cela commence à devenir problématique, car ces versions ne sont plus vraiment supportées à l'heure actuelle ; la dernière version de la branche 3.2 date de 2003 et celle de la branche 3.4 de 2006. La branche actuelle de GCC est la 4.2. La solution la plus simple est donc pour l'instant d'utiliser la version de QEMU fournie par la distribution GNU/Linux utilisée (dans notre cas, la version de Debian). Toutefois si l'on souhaite tester un changement ou modifier les options de compilation, il est nécessaire d'installer une ancienne version de GCC.

Les performances de la machine virtuelle sont un autre facteur limitatif. Comme toutes les solutions de virtualisation complète, QEMU pêche au niveau de la rapidité des Entrées/ Sorties. Le module d'accélération kqemu améliore certes les performances, mais on reste loin des performances « natives ». Il faut toutefois signaler que même si les performances sont éloignées de celles d'une véritable machine, QEMU se place parmi les solutions de virtualisation complète les plus performantes.

QEMU reste une solution intéressante dans les cas d'utilisation où l'on a simplement besoin de tester le comportement d'un programme ou d'un système. Les options d'interconnexion qu'il offre, tant avec le système hôte qu'avec d'autres machines du réseau sont très intéressantes, et permettent de mettre au point des architectures très complexes, impossibles à réaliser avec des machines physiques.

Cependant, pour l'hébergement de serveurs en production, QEMU seul offre des performances insuffisantes par rapport à la puissance de la machine hôte. Ce n'est donc pas une solution retenue dans notre étude.

Il sera potentiellement plus intéressant d'utiliser KVM, détaillé dans la section suivante.

Le projet KVM (Kernel-based Virtual Machine - machine virtuelle dans le noyau) a été créé en 2006 par la société Qumranet. KVM a su très vite attirer les contributions externes et le code source du projet a été intégré au noyau Linux dès février 2007. Le mainteneur principal de KVM est Avi KIVITY. À l'heure actuelle, le projet KVM est financé principalement par Qumranet, mais IBM participe aussi au développement en salariant un développeur pour travailler sur KVM : Anthony LIGUORI. Il est d'ailleurs intéressant de constater qu'un des fondateurs de la société Qumranet, Moshe BAR, est aussi un des fondateurs de la société XenSource, la société à l'origine de Xen (cf. page 54).

KVM est un projet de virtualisation complète qui utilise les instructions de virtualisation des processeurs x86 récents. Techniquement, KVM se compose :

• d'un module noyau qui utilise les instructions de virtualisation et communique avec le processeur ;
• d'un programme utilisateur, qui utilise le module noyau pour toutes les opérations privilégiées.

La partie utilisateur de KVM est une version légèrement modifiée de QEMU, simplement adaptée pour que les opérations pouvant bénéficier des instructions de virtualisation du processeur fassent appel au module noyau.

L'article [Qum07] présente brièvement les principes derrière KVM. Lors du dernier Linux Symposium, qui s'est tenu au mois de juin 2007, Avi KIVITY et d'autres développeurs de KVM ont tenu une conférence sur le fonctionnement détaillé de KVM. L'article correspondant (plus complet que le précédent) est [KKL+07].

Le tableau 2.2 récapitule les technologies utilisées par KVM. Il y a actuellement en développement un module de paravirtualisation, qui pourra servir à accélérer encore davantage les performances des Entrées/Sorties, notamment au niveau de la communication réseau. Ce module est toutefois facultatif - en plus d'être instable et toujours en développement - et l'on peut tout à fait s'en passer, c'est pourquoi il est marqué entre parenthèses dans le tableau.

KVM étant basé sur QEMU, il reprend naturellement toutes les fonctionnalités de ce dernier, qui ont déjà été traitées en page 38.

Il y a toutefois une différence notable : grâce à l'utilisation des instructions de virtualisation des processeurs récents, les performances des systèmes invités sont bien plus élevées qu'avec QEMU.

Une autre fonctionnalité qui se démarque de QEMU est la migration des systèmes invités. KVM propose en effet la migration « à chaud » des hôtes, mais d'un fonctionnement différent de la migration d'images de QEMU. Le processus de migration de systèmes invités de KVM est actuellement plus performant que celui de QEMU, mais QEMU bénéficiera sous peu des améliorations de KVM.

La communauté autour de KVM est à l'image de celle de QEMU : diversifiée et active. Les deux projets partagent d'ailleurs une bonne partie de leur communauté. Les mêmes moyens de communication sont utilisés : liste de diffusion et wiki.

Le développement est principalement assuré par les employés de Qumranet (notamment Avi KIVITY, mainteneur officiel), mais il y a des contributeurs externes réguliers. On peut notamment citer Rusty RUSSELL, décidément très actif dans le milieu de la virtualisation, ou encore des employés d'Intel, d'AMD ou d'IBM. Le projet a donc réussi à attirer l'attention des grands acteurs de la virtualisation.

La société Qumranet collabore étroitement avec les développeurs de QEMU, et la plupart des modifications apportées à QEMU pour le rendre plus performant sont répercutées dans le projet original. Seules les modifications spécifiques à KVM ne sont pas appliquées, car elles n'ont de sens que pour KVM.

KVM est majoritairement sous licence GNU GPL, avec quelques variations mineures sur certains composants. L'intégralité du projet est néanmoins sous une licence libre, le rendant compatible avec les contraintes énoncées précédemment.

Étant basé sur QEMU, KVM souffre des mêmes inconvénients sur la complexité du code et la difficulté de manipuler les images disques.

En plus de cela, la partie propre à KVM, c'est-à-dire le module noyau utilisant les instructions de virtualisation, est encore jeune et manque de maturité. La stabilité de l'interface de programmation (API) vient tout juste d'être atteinte, mais il n'est pas exclu que l'API change à nouveau. Cela signifie qu'un outil très proche de KVM peut ne plus marcher après une mise à jour.

La jeunesse du projet a un autre inconvénient : le manque de retours d'expérience concernant des architectures complexes de virtualisation utilisant KVM. En effet, peu d'entreprises - voire pas du tout - ont publiquement annoncé qu'elles utilisaient KVM pour virtualiser des serveurs à grande échelle. Même si KVM est effectivement utilisable en production pour un petit nombre de machines virtuelles, la difficulté de maintenance et la montée en charge restent inconnues. Il y a donc un risque (certes faible, mais pas inexistant) d'affronter des difficultés inattendues en utilisant KVM pour virtualiser un ensemble de serveurs.

Le projet KVM, en dépit de sa jeunesse et de son manque apparent de maturité, est très intéressant pour une société souhaitant virtualiser des serveurs. Son intégration au noyau Linux lui assure une durée de vie incomparable par rapport à un projet externe, et l'attrait de la communauté et des entreprises pour ce projet est un gage supplémentaire de pérennité.

Le potentiel d'évolution de KVM est très élevé, avec une communauté motivée et un développement pour l'instant ininterrompu. Même s'il n'a pas toutes les fonctionnalités nécessaires à l'heure actuelle, il y a des chances qu'elles soient implémentées rapidement.

C'est pourquoi, même s'il est actuellement risqué de l'utiliser en production, il été sélectionné dans la liste des projets à étudier plus profondément. En effet, KVM sera très certainement un des acteurs majeurs plus tard, il faut donc l'étudier et le maîtriser dès maintenant, ne serait-ce que pour être prêt le jour où il sera vraiment utilisable.

Le projet Linux-VServer est un projet de virtualisation par cloisonnement pour la plateforme GNU/Linux. Au départ, ce projet s'appelait Virtual private servers and security contexts et était géré par la société Solucorp. Il a été ouvert à la communauté fin 2001, et a eu une évolution lente, mais constante depuis. La version actuelle est la version 2.2.0.3, qui a été diffusée au début du mois de juillet 2007.

Parmi les utilisateurs connus de Linux-VServer, on retrouve notamment LinuxFr.org, site communautaire d'informations autour du logiciel libre et de GNU/Linux. Le site de LinuxFr.org génère actuellement 100 000 visites par jour et près de 10 millions de pages vues par mois. La charge engendrée par une telle activité est absorbée par un serveur HP très haut de gamme, et Linux-VServer est utilisé pour cloisonner les différents systèmes hébergés sur la machine. Les autres systèmes invités s'exécutant sur cette machine ne sont pas impactés par la forte charge du site LinuxFr.org.

Un autre utilisateur réputé de Linux-VServer est le projet One Laptop Per Child (OLPC). Ce projet vise à créer et diffuser des ordinateurs portables à très bas coût dans les écoles des pays en voie de développement. Le projet OLPC se base intégralement sur des logiciels libres pour la création des applications éducatives à destination des enfants. Linux-VServer est utilisé pour cloisonner les applications, afin d'éviter tout risque de propagation de malware*.

Le projet Linux-VServer utilise le cloisonnement, c'est-à-dire qu'il isole des instances du système d'exploitation par dessus un système hôte. Le tableau 2.3 récapitule les technologies utilisées par le projet.

Du point de vue technique, il se compose de patches* à appliquer sur le code source du noyau Linux et d'utilitaires fonctionnant dans l'espace utilisateur pour contrôler la création et l'administration des systèmes invités.

Linux-VServer se base sur les fonctionnalités déjà implémentées au sein du noyau pour la séparation des processus et les droits d'accès pour implémenter une séparation complète au niveau du noyau. Les modifications apportées utilisent et étendent les fonctionnalités déjà présentes dans le noyau.

Il y a un seul noyau Linux, qui contrôle toujours l'accès au matériel, mais il est partagé entre plusieurs instances du système, qui ont chacune un accès complet au noyau, sans connaissance des autres systèmes invités. La possibilité d'avoir un accès complet au noyau signifie entre autres qu'il n'y a pas besoin de porter les applications utilisateurs pour qu'elles fonctionnent sur Linux-VServer. Pour l'administrateur, la machine physique comporte un seul système d'exploitation, mais pour les programmes utilisateurs, chaque partition du système voit sa propre instance du noyau.

Comme le projet utilise une technologie de cloisonnement, il n'y a quasiment pas de perte de performances par rapport à un système natif, mais il y un net gain en sécurité et simplicité d'administration du fait de la séparation entre les systèmes invités.

Contrairement à QEMU et KVM, Linux-VServer ne travaille pas avec une image disque du système, mais avec un simple ensemble de fichiers dans un répertoire, qui représentera la racine du système invité. Cela implique une plus grande facilité d'utilisation. En effet, il est possible avec ce mode de fonctionnement de modifier des fichiers du système invité en les ouvrant depuis le système hôte, comme n'importe quel autre fichier. On peut donc opérer des modifications, ou déplacer une image système d'une machine à l'autre très facilement.

Par contre, les possibilités de configuration réseau sont moindres que pour QEMU, car Linux-VServer reste très proche du noyau Linux. Il y a quelques options pour assigner une carte réseau à un système invité ou au contraire répartir la carte entre plusieurs. Pour de l'hébergement de serveurs en production, cela est amplement suffisant, mais certainement pas pour faire des tests avec des configurations spécifiques.

Il est intéressant de noter qu'il y a à l'heure actuelle deux projets d'outils pour la partie en espace utilisateur, nécessaire pour administrer et créer les systèmes invités. Le premier outil est util-vserver, qui est l'outil de gestion « historique » du projet Linux- VServer. Le second outil, VServer Control Daemon, est en phase de développement et permettra d'avoir une centralisation des serveurs sur une seule interface.

La communauté du projet Linux-VServer est moyennement active, centrée autour d'un wiki et d'une liste de diffusion. Il y a quelques acteurs principaux, dont le fondateur du projet et deux mainteneurs.

Le projet souffre néanmoins d'une diffusion trop confidentielle et d'un manque de visibilité qui lui porte préjudice. La communauté ne s'agrandit pas, ou du moins pas assez vite pour que cela se remarque.

Le projet Linux-VServer est intégralement sous licence GNU GPL.

Malgré des performances très élevées, le projet Linux-VServer souffre de quelques inconvénients. Tout d'abord, la séparation entre les systèmes invités est trop « faible », dans le sens où il y a un seul noyau Linux pour plusieurs systèmes invités. Si un système invité trouve un moyen de contourner les protections et affecte le noyau, tous les autres systèmes de la machine en pâtiront. C'est une faiblesse dont souffrent toutes les solutions de virtualisation utilisant le cloisonnement.

Un autre problème majeur est la difficulté de maintenir le projet à jour. En effet, comme le code de Linux-VServer est un patch pour le noyau Linux, il est possible – et même très fréquent – qu'une nouvelle version du noyau « casse » la compatibilité du patch. Il faut alors attendre qu'une nouvelle version du projet Linux-VServer sorte spécifiquement pour la nouvelle version du noyau. Ce reproche peut être adressé à tous les projets modifiant en profondeur le noyau, mais qui sont maintenus séparément. Garder ce genre de projets à jour est difficile et très consommateur de temps. En cas de mise à jour de sécurité, il y a toujours un décalage entre la sortie du noyau et la sortie de projet, ce qui peut apporter un risque supplémentaire si le serveur est exposé.

Pour conclure, le projet Linux-VServer, en dépit de ses qualités, n'offre pas toutes les garanties nécessaires, notamment sur le soutien de la communauté, trop réduite. Il est de plus relativement complexe à maîtriser, et rares sont les administrateurs connaissant ce projet. C'est pourquoi cette solution n'a pas été retenue pour une architecture de virtualisation. Cependant, si au sein de l'entreprise, un administrateur maîtrise Linux-VServer, ce dernier devient une alternative intéressante qu'il convient de ne pas négliger.

OpenVZ est un projet de virtualisation par cloisonnement géré par la société SWsoft. Le modèle commercial de SWsoft consiste en une offre propriétaire (et payante) nommée Virtuozzo, qui se base sur le projet libre OpenVZ. Les clients souhaitant un support technique de qualité et des performances très élevées peuvent se tourner vers le produit Virtuozzo, les clients préférant utiliser une technologie libre et pouvant se contenter du support fourni par la communauté utiliseront OpenVZ.

La société SWsoft a été créée aux États-Unis en 1997. En 2001, le produit Virtuozzo est diffusé, avec son pendant libre : OpenVZ. SWsoft rachète Parallels en 2004, une société spécialisée dans la virtualisation pour les particuliers, très populaire sur Mac OS X. La société SWsoft est également connue comme éditrice de Plesk, une interface web sous forme de panneau de contrôle pour gérer des hébergements de sites web.

Le principe de fonctionnement d'OpenVZ est très similaire à celui de Linux-VServer, car ils se basent tous les deux sur une modification du noyau Linux pour implémenter un système de cloisonnement au niveau du système d'exploitation.

OpenVZ modifie le noyau Linux plus en profondeur que le patch de Linux-VServer. Il y a donc des fonctionnalités spécifiques à OpenVZ.

Parmi ces nouvelles fonctionnalités, on peut notamment citer l'ajout d'un niveau supplémentaire d'indirection pour les ordonnanceurs* du noyau. Ce nouveau niveau d'indirection permet de gérer les priorités entre les systèmes invités, puis ensuite au sein d'un système invité. C'est-à-dire que l'ordonnanceur de bas niveau décide d'abord à quel système invité passer la main, puis ensuite l'ordonnanceur traditionnel du noyau Linux décide à quel processus passer la main, au sein de ce système. La répartition de charge entre les systèmes invités est donc plus fine qu'avec Linux-VServer, qui utilise un système d'ordonnancement bien moins complexe qu'OpenVZ.

Les fonctionnalités de haut niveau d'OpenVZ sont quasiment identiques à celles de Linux-VServer : arrêt, instanciation et contrôle des systèmes invités sont d'un fonctionnement similaire. Seule une étude approfondie permet de noter quelques différences, qui viennent pour la plupart d'une intégration plus en profondeur.

Une fonctionnalité intéressante d'OpenVZ est la possibilité de migrer un système invité « à chaud », sans avoir à le désactiver avant. Le terme utilisé dans le cas d'OpenVZ est checkpointing. Cela consiste à sauvegarder l'état complet du système invité dans un fichier sur le disque, puis à le transférer sur une autre machine où l'état pourra alors être restauré.

Au niveau du contrôle des ressources, OpenVZ propose un ensemble de limites par système invité, que l'administrateur peut configurer. Par exemple, il peut allouer un nombre maximal de processus qu'un système invité aura le droit de créer, ou encore le nombre de connexions réseau, etc. Ces limites par système invité permettent un très bon contrôle et garantissent qu'un système ne nuira pas aux autres.

La connectivité réseau est là aussi très similaire aux autres solutions, chaque système invité peut disposer de sa propre adresse IP, c'est le noyau modifié qui s'occupe de rediriger le trafic réseau vers le bon système.

La communauté d'OpenVZ est centralisée autour d'un wiki, de plusieurs listes de diffusion et du site web de SWsoft. Dans l'ensemble, la communauté donne une impression de meilleure organisation et de plus grande activité que celle de Linux-VServer.

Le projet OpenVZ est certes mis en avant par la société, mais uniquement après la solution propriétaire Virtuozzo.

La documentation disponible est par contre très bien fournie, et on peut très rapidement avoir une idée du produit, tant du point de vue utilisation et administration que pour l'aspect technique.

Le projet OpenVZ est distribué sous la licence GNU GPL.

Le principal problème avec OpenVZ est que SWsoft ne « joue pas le jeu » du logiciel libre. En effet, le projet libre dispose de moins de fonctionnalités que la version propriétaire et payante. La version payante est montrée comme la version complète, alors que la version libre est juste là pour appâter la communauté et attirer les contributions.

De plus, la société se targue de posséder plusieurs brevets sur les méthodes de virtualisation. Le mouvement du logiciel libre étant en général plutôt opposé à l'idée de brevetabilité des logiciels et des idées, cette mise en avant de brevets logiciels est plutôt malvenue.

Pour les raisons citées précédemment, et malgré d'excellentes performances et une très bonne documentation, le projet OpenVZ n'est pas acceptable pour une PME impliquée dans le logiciel libre, en raison d'un décalage idéologique trop grand. Il n'a donc pas été retenu pour une étude approfondie. Il est cependant tout à fait envisageable de l'utiliser si l'on fait abstraction de ce problème.

Xen (dont le nom vient du grec xenos, étranger) est un projet de virtualisation par hyperviseur géré par la société XenSource. Le projet était à l'origine mené au sein de l'Université de Cambridge, sous le nom de Xenoserver. Le but était alors d'héberger 100 systèmes invités sur une seule machine physique, avec les meilleures performances possible.

En 2003, les initiateurs du projet ont fondé la société XenSource et ont lancé le projet Xen en se basant sur le code source de Xenoserver.

Le rachat en août 2007 de la société XenSource par Citrix ne devrait rien changer pour la communauté, la licence du produit libre restant inchangée. Toutefois, les entreprises pourront être rassurées de voir que XenSource est maintenant soutenue par des moyens financiers importants.

La solution de virtualisation Xen est séparée en plusieurs produits, ayant tous des finalités différentes. Il y a tout d'abord la version libre, nommée Xen 3.0, qui concentre toute la technologie de virtualisation. Les autres versions (propriétaires) de la gamme se distinguent uniquement par le support proposé, les nombres de machines virtuelles supportées, les systèmes invités supportés et les logiciels annexes. Ainsi, la version Xen Enterprise se base intégralement sur Xen 3.0, mais rajoute des outils de contrôle pour gérer plusieurs dizaines d'instances de Xen.

Le modèle commercial de XenSource est donc très différent de celui de SWsoft (société éditrice de Virtuozzo et OpenVZ, cf. page 51). Dans le cas de Xen, la technologie de virtualisation est la même partout, les versions propriétaires ont seulement des outils de gestion à grande échelle et un support technique fourni par XenSource. Les performances sont donc identiques entre les produits.

Xen est un hyperviseur, c'est-à-dire qu'il vient s'insérer entre le matériel et le noyau. C'est donc Xen qui a l'accès exclusif au matériel, et les systèmes d'exploitation fonctionnant par dessus doivent obligatoirement passer par l'hyperviseur pour y accéder. Il peut ainsi répartir précisément les ressources entre les systèmes invités. Le tableau 2.5 récapitule le type de technologie que Xen utilise.

Xen étant une solution à base d'hyperviseur, les systèmes destinés à s'exécuter au-dessus doivent être portés pour pouvoir cohabiter avec l'hyperviseur. Or, la modification des couches basses d'un système pour améliorer les performances est précisément la définition de la paravirtualisation. C'est pourquoi on considère que Xen est aussi une solution à base de paravirtualisation, car le système doit être modifié pour cohabiter.

Au-dessus de l'hyperviseur se trouvent les systèmes invités, qui sont tous contrôlés par Xen. Le premier système d'exploitation démarré par Xen a des privilèges particuliers. Ce système est appelé « domaine zéro » (dom0), par opposition aux systèmes démarrés plus tard, appelés « domaines utilisateurs » (domUs). Le domaine zéro (ou domaine 0) est le seul autorisé à créer et contrôler les domaines utilisateurs.

Le projet Xen se compose d'un ensemble de modifications à appliquer au noyau Linux (des patches) ainsi que des utilitaires en espace utilisateur qui permettent d'administrer les systèmes invités (les domaines utilisateurs, dans la terminologie de Xen). Les utilitaires sont dans le domaine zéro et interagissent avec l'hyperviseur par le biais d'appels systèmes spécifiques.

Une partie du code source de Xen a finalement été intégrée au noyau Linux durant l'été 2007, après plusieurs années d'attente. La plus grosse partie du code source est cependant encore maintenue séparément, avec les inconvénients que cela comporte.

Au niveau des fonctionnalités, Xen est très certainement un des plus complets, il n'a pas à rougir de la comparaison avec des technologies propriétaires plus anciennes et mieux établies, telles que les solutions de la société VMware.

La configuration du réseau est à l'image de celle de QEMU : difficile à appréhender, mais néanmoins très puissante une fois maîtrisée. Au démarrage, Xen prend en charge la gestion des interfaces réseau, et crée une interface virtuelle pour chaque système invité, qui seront toutes reliées à une interface physique par un système de pont (bridging). On peut donc, comme avec QEMU, attribuer une adresse IP distincte à chaque système invité, les rendant ainsi impossibles à différencier de véritables machines physiques sur le réseau.

Au niveau des images disques, Xen peut fonctionner de la même manière que les solutions à base de cloisonnement vues précédemment (Linux-VServer et OpenVZ) : le système invité sera un simple ensemble de fichiers dans un répertoire du système hôte.

Il y a néanmoins la possibilité de placer les systèmes invités sur des partitions dédiées du disque dur, voire sur un autre disque. De cette manière, les machines virtuelles bénéficient de leur propre espace, séparé du système hôte. Cela permet d'exploiter toutes les fonctionnalités de GNU/Linux pour la gestion des disques, notamment le RAID* logiciel et le redimensionnement⁶ des partitions sans perte de données. On peut dans tous les cas accéder directement aux fichiers des domaines utilisateurs, il suffit de « monter » la partition dans le système de fichiers du système hôte, de la même façon que l'on monte une clef USB ou un lecteur réseau.

Un autre point fort du projet Xen est la gestion des systèmes invités : on peut très facilement, avec les outils d'administration fournis, contrôler l'état d'un système, son activité (consommation du temps processeur et de la mémoire allouée), le mettre en pause ou l'arrêter complètement. Les outils de gestion permettent également de migrer les systèmes invités entre différents systèmes hôtes.

La migration « à chaud » est possible dans certaines conditions. En effet, Xen ne peut pas traiter correctement la conservation des connexions réseau si les systèmes d'origine et de destination ne sont pas sur le même domaine de collision (c'est-à-dire la même portion de réseau physique). La migration « à chaud » d'un système invité sans connexion réseau active est toutefois réalisable assez simplement, et le processus n'interrompt la machine virtuelle que quelques instants (le site web parle d'une durée d'interruption de 100 millisecondes).

Pour que la migration s'effectue rapidement, il est néanmoins nécessaire que les deux systèmes hôtes aient accès à l'image disque, par exemple par le biais d'un disque partagé sur le réseau. La rapidité de la migration dépend alors des performances du disque partagé.

Une migration avec le système invité arrêté est réalisable sans contraintes, et c'est de toute manière la fonctionnalité la plus pratique dans le cas d'utilisation envisagé.

La communauté de Xen est rassemblée autour de plusieurs listes de diffusion, d'un wiki et de plusieurs forums. Elle est dans l'ensemble assez active, tant en contribution de documentation qu'en projets annexes, permettant de profiter au mieux de Xen.

L'attitude de la société XenSource vis-à-vis de la communauté est résumée par la phrase suivante, affichée de manière très visible sur leur site web :

« XenSource is totally committed to the Xen community and the open source process. (XenSource est entièrement impliquée dans la communauté Xen et dans le processus open source.) »

        Ian PRATT, leader du projet Xen

Contrairement à SWsoft avec OpenVZ, la société XenSource est donc très ouverte et soutient activement la communauté utilisateur de Xen. La version propriétaire et payante de Xen apporte juste un contrat de support et des outils de gestion de plus haut niveau, mais pas de gains de performances.

Dans l'ensemble, la communauté Xen est très certainement la plus grande communauté parmi celles analysées ici. Le projet a su convaincre des milliers d'utilisateurs, gage de grande qualité et garantie que le projet ne sera pas à court de contributeurs du jour au lendemain.

Le projet Xen est diffusé sous la licence GNU GPL.

Xen n'est toutefois pas dépourvu de défauts. Un des reproches majeurs faits à Xen est sa grande complexité. En effet, pour implémenter un hyperviseur performant, Xen modifie les couches basses de tous les systèmes d'exploitation, afin qu'ils puissent collaborer avec l'hyperviseur. Les modifications apportées au noyau Linux sont de l'ordre de plusieurs milliers de lignes de code. Elles portent essentiellement sur la création d'une interface avec l'hyperviseur et sur la gestion de l'accès au matériel à travers ce dernier. Ces modifications sont assez intrusives, et altèrent profondément la façon dont le noyau travaille en interne.

L'hyperviseur du projet Xen est également très complexe. En effet, pour assurer une répartition équitable des ressources, il faut un ordonnanceur très performant, capable d'assurer que chaque système invité aura accès aux ressources, tout en appliquant les politiques définies. L'hyperviseur doit donc avoir un ordonnanceur capable de fournir d'excellentes performances, ce qui est loin d'être évident. Les développeurs du noyau Linux ont mis quelques mois avant d'arriver à obtenir un ordonnanceur de processus performant, et l'hyperviseur de Xen a besoin d'un ordonnanceur de systèmes d'exploitation, basé sur le même principe.

En plus de l'ordonnanceur, l'hyperviseur implémente aussi une gestion de la mémoire vive et des accès disque. Toutes les couches basses d'un système d'exploitation sont en fait réécrites au sein de l'hyperviseur. Cela augmente sensiblement la complexité du logiciel, ainsi que les risques d'erreurs.

En ce qui concerne la gestion du réseau, Xen est là aussi difficile à appréhender. La documentation utilisateur est très succincte à ce sujet, et il faut se contenter de laisser Xen tout gérer.

De plus, si la documentation est certes suffisante pour se servir de Xen, il n'y a pas de documentation technique officielle, qui détaille le fonctionnement interne de Xen. Ce type de documentation est nécessaire pour savoir comment optimiser l'architecture de virtualisation bâtie autour de Xen. Il y a bien quelques détails techniques sur le wiki, mais ils sont parfois incomplets, voire obsolètes.

Un autre aspect négatif du projet Xen est le fait qu'il est externe au projet Linux. Actuellement, seule une très faible portion du code modifiant le noyau Linux a été intégrée dans la branche officielle. Xen est donc en partie composé de patches de plusieurs milliers de lignes, maintenus et mis à jour séparément. Comme pour les autres projets extérieurs au noyau, cela pose un risque d'incompatibilité avec d'éventuelles modifications du noyau effectuées par l'utilisateur. De même, en cas de faille de sécurité, il y a un risque certain que la version Xen du noyau sorte plus tard que la version officielle, le système restant potentiellement vulnérable plus longtemps. Ce risque est donc à prendre en compte.

La complexité de Xen a un avantage : les performances et les fonctionnalités sont impressionnantes, très proches de celles d'un système d'exploitation s'exécutant directement sur une machine physique, sans virtualisation.

Les fonctionnalités sont également à la hauteur des performances, permettant aux administrateurs de véritablement s'abstraire des machines physiques pour la gestion des systèmes. Les outils annexes proposés par la communauté sont aussi très efficaces, et apportent une véritable plus-value.

En plus de ses fonctionnalités complètes, Xen dispose d'une communauté très active, qui développe régulièrement de nouveaux outils pour simplifier l'administration ou la supervision des systèmes invités.

C'est pour toutes ces raisons que Xen a été retenu, et sera donc étudié en détail dans le chapitre suivant.

Dans ce chapitre, plusieurs solutions de virtualisation ont été étudiées, chacune avec des technologies et des buts différents. Le tableau 2.6 récapitule les différentes technologies utilisées par les projets étudiés.

Parmi les projets non retenus, QEMU a été éliminé à cause de performances insuffisantes ; OpenVZ pour une « incompatibilité idéologique », malgré des performances de premier ordre ; Linux-VServer, enfin, n'a pas été retenu, car il n'offrait pas assez de garanties sur la pérennité et l'évolution des développements à long terme.

Parmi les projets retenus, KVM a été sélectionné parce qu'il offrait le meilleur potentiel d'évolution à court et moyen terme ; Xen a lui été choisi, car c'est tout simplement la solution libre la plus performante et la plus complète du marché à l'heure actuelle.

Le chapitre suivant analysera donc les deux solutions retenues pour une étude approfondie : KVM et Xen.

Le projet Xen a été fondé par Ian PRATT en 2003, en se basant sur un projet de recherche de l'université de Cambridge. La première version de Xen, sortie en 2003, était limitée dans ses performances et ses fonctionnalités. Elle a toutefois réussi à attirer des contributeurs et des investisseurs, permettant d'amorcer le développement.

La version 2 du projet a été diffusée fin 2004, et a apporté beaucoup d'améliorations, tant en terme de fonctionnalités (support des noyaux récents, couche réseau plus flexible, etc.) qu'en terme de performances. La version 2 a été maintenue jusqu'au milieu de l'année 2005, date de sortie de la version 2.0.6.

En parallèle, la communauté avait déjà commencé à développer la nouvelle version majeure du projet, la version 3.0. Elle a été diffusée début 2006, et a apporté davantage de fonctionnalités, notamment le support de plusieurs processeurs dans les domaines utilisateurs, améliorant sensiblement les performances. La version 3.0.2 a ajouté le support des instructions de virtualisation pour les processeurs le permettant, offrant la possibilité d'exécuter des systèmes invités au-dessus de l'hyperviseur, sans avoir à les modifier.

En mai 2007 est sortie la version 3.1 de Xen, nouvelle version majeure améliorant encore le support des instructions de virtualisation et les performances en général.

Le projet Xen dispose en outre d'une feuille de route (roadmap) très complète, qui donne une idée très précise de la direction que vont prendre les développements à moyen et à long terme. Le fait qu'elle soit respectée et tenue à jour inspire confiance dans l'avenir de Xen, car on voit qu'il y a une réelle envie de progresser, et pas seulement des ajouts de fonctionnalités au hasard, selon l'humeur des développeurs.

Xen est un projet très complexe, constitué de plusieurs composants visant à fournir une solution de virtualisation utilisable très simplement par l'administrateur. Cette simplicité apparente cache toutefois une complexité technique non négligeable, qu'il est souhaitable de maîtriser -ou au moins de connaître -si l'on veut pouvoir exploiter Xen au maximum de ses possibilités.

Il est de plus difficile d'obtenir une documentation technique pour connaître les détails de fonctionnement de Xen. En effet, la documentation utilisateur [XeM] est très succincte et ne couvre que les options de configuration, pas les détails d'implémentation. La documentation pour le programmeur [XeI] ne couvre que l'utilisation de l'API. Il est donc nécessaire d'effectuer un travail de recherche et de recoupement pour synthétiser toute la documentation disponible. L'analyse détaillée qui suit est donc une synthèse, d'après des informations tirées soit du wiki non officiel de Xen, soit de discussion avec la communauté des utilisateurs de Xen.

L'analyse détaillée de Xen portera sur les versions 2 et 3 du projet. Les évolutions apportées par la version 3 n'ayant pas fortement modifié l'architecture globale du logiciel, la plupart des documentations techniques portant sur la version 2 sont applicables à la version 3.

Le projet Xen peut être séparé en plusieurs modules :

• l'hyperviseur ;
• les patches à appliquer au noyau Linux ;
• les programmes de contrôle en espace utilisateur.

La figure 3.1 représente l'architecture générale de Xen. Par rapport à l'architecture théorique d'un système à hyperviseur (cf. figure 1.4 page 20), on peut noter la présence d'un système invité particulier, dénommé domaine 0. Ce système manipule l'hyperviseur Xen à travers une interface standardisée.

Toutes les actions d'administration passent par l'interface de programmation (API, Application Programming Interface) de l'hyperviseur Xen. Ainsi, quand l'administrateur souhaite démarrer un domaine utilisateur, il exécute un utilitaire dans l'espace utilisateur, qui fait appel à l'interface de contrôle du domaine 0. Cette dernière communique alors directement avec l'hyperviseur pour instancier le domaine utilisateur.

Seul le domaine 0 a un accès complet au matériel (mais toujours à travers l'hyperviseur). C'est donc dans le domaine 0 que s'effectue toute la configuration des systèmes invités :

• réservation de l'espace disque ;
• création du fichier de configuration du domaine utilisateur
• création ou copie des fichiers du système d'exploitation…

Inversement, les domaines utilisateurs n'ont accès qu'à ce que l'administrateur a configuré (c'est-à-dire les partitions du système, plus éventuellement des lecteurs partagés sur le réseau).

L'hyperviseur

L'hyperviseur est démarré directement par le chargeur de démarrage de l'ordinateur, en lieu et place d'un système d'exploitation traditionnel. L'hyperviseur instancie ensuite le domaine 0 et lui passe la main pour le reste de l'initialisation des périphériques, tâche qui n'est pas réalisée par l'hyperviseur Xen.

En pratique, au démarrage de la machine, on voit s'afficher quelques lignes traitant de l'hyperviseur et de sa configuration avant que le noyau Linux ne prenne le relais et entame le processus de démarrage « traditionnel ».

Comme pour le noyau Linux, il y a une partie de la configuration de l'hyperviseur qui doit être passée par le chargeur de démarrage, soit parce qu'elle n'est pas modifiable en cours d'exécution (par exemple la quantité de RAM à affecter au domaine 0 ou les paramètres de la console série), soit parce que la lecture dans un fichier de configuration est impossible, car le système de fichiers n'est pas encore activé au moment où l'information est nécessaire. Dans la configuration du chargeur de démarrage, l'hyperviseur apparaît comme un système d'exploitation de type GNU/Linux, avec simplement des options différentes de celles passées à un noyau Linux.

Techniquement, l'hyperviseur est le point de passage obligatoire pour tout accès au matériel. Il régule et répartit les accès aux ressources entre les systèmes invités (domaine 0 et domaines utilisateurs). À l'image des ordonnanceurs du noyau Linux pour la répartition des accès au processeur et aux périphériques d'Entrées/Sorties entre les différents processus du système d'exploitation, les ordonnanceurs de l'hyperviseur Xen répartissent les Entrées/Sorties et le temps processeur entre les systèmes invités. Il y a donc un niveau d'indirection supplémentaire, rendu nécessaire par la cohabitation de plusieurs systèmes d'exploitation sur la même machine.

Dans Xen, la mémoire physique installée est répartie sans recouvrement entre les systèmes invités. C'est-à-dire que si la machine dispose de 512 mégaoctets de RAM, l'administrateur pourra par exemple faire fonctionner 4 systèmes invités (incluant le domaine 0) disposant chacun de 128 mégaoctets. Il ne pourra pas allouer plus de mémoire qu'il n'y en a de disponible, la mémoire n'est pas une ressource « partageable » entre les systèmes d'exploitation. Il est par contre tout à fait possible d'arrêter un domaine utilisateur et d'en démarrer un autre à la place, du moment que le nouveau système ne nécessite pas plus de RAM qu'il n'en reste.

À l'inverse, l'accès au processeur n'est pas exclusif, tous les systèmes invités en cours d'exécution ont chacun une part du temps processeur total disponible sur la machine. Selon le type d'ordonnanceur choisi, l'administrateur peut assigner des priorités aux systèmes, afin d'affecter un quantum de temps plus important à un système par rapport aux autres.

En plus de gérer l'accès aux ressources, l'hyperviseur doit aussi gérer la correspondance entre la représentation de la mémoire des systèmes invités et la disposition effective de la mémoire pour le processeur. En effet, comme dit dans la section 1.2.2 page 14, c'est le processeur qui s'occupe de la gestion physique de la mémoire sur les architectures PC. Or, les systèmes d'exploitation ne sont pas conçus pour coopérer et tenir compte les uns des autres. C'est le rôle de l'hyperviseur de gérer la mémoire avec le processeur, et plus celui des systèmes d'exploitation, qui ne feront que communiquer avec l'hyperviseur pour cela.

De manière simplifiée, chaque système invité gère lui-même sa mémoire comme s'il était seul, dans un espace mémoire réservé, et tient au courant l'hyperviseur des opérations relatives à la gestion de la mémoire. L'hyperviseur est lui en charge de faire la correspondance entre l'adresse virtuelle du système invité et l'adresse réelle manipulée par le processeur.

Le noyau Linux et l'hyperviseur communiquent par le biais d'appels systèmes spécifiques, appelés hypercalls (pour hypervisor calls, appels à l'hyperviseur). Ces appels permettent de passer des messages à l'hyperviseur, sur les tâches à accomplir (par exemple l'allocation ou la libération de mémoire).

Modifications apportées au noyau Linux

La plupart des modifications apportées au noyau Linux portent sur l'ajout de paravirtualisation pour la coopération avec l'hyperviseur, notamment pour la gestion de la mémoire, qui concentre la majorité des modifications.

Les patches ont pour effet de rajouter une architecture matérielle dans les options de compilation du noyau : xen_x86. Cette architecture matérielle, « fictive », car elle ne correspond pas réellement à du matériel, permet de regrouper toutes les modifications, au lieu de modifier directement les fichiers concernés pour l'architecture x86, opération très intrusive.

La communication avec l'hyperviseur s'effectue au moyen d'hypercalls. Il y a en tout une trentaine d'hypercalls définis, couvrant toutes les opérations courantes de Xen : gestion de la mémoire, gestion des Entrées/Sorties, etc.

Si la communication depuis le système invité vers l'hyperviseur est réalisée par un hypercall, le passage d'informations dans le sens inverse est réalisé par un bus d'évènements, au fonctionnement très similaire à celui des interruptions matérielles. Dès qu'un évènement susceptible de nécessiter une action de la part du système survient (arrivée d'un paquet sur l'interface réseau, fin d'un transfert de données sur le disque…), il est signalé au système, qui prend alors le relais et traite l'évènement. Les bus d'évènements de Xen ont le même rôle, mais pour la transmission d'informations relatives à l'hyperviseur (par exemple domaine utilisateur créé ou arrêté avec succès).

Les modifications apportées couvrent donc la gestion des messages de l'hyperviseur Xen, les hypercalls et l'adaptation à l'hyperviseur.

Applications en espace utilisateur

Les applications utilisateurs sont des programmes permettant de contrôler l'exécution des domaines utilisateurs. Ils se situent exclusivement dans le domaine 0.

L'application principale de l'espace utilisateur est xend (pour Xen daemon*). xend est démarré en tant que service avec le système d'exploitation et sert d'interface entre les hypercalls de l'hyperviseur et les outils de contrôle de Xen. Il est aussi chargé de faire passer les informations du bus d'évènement vers l'espace utilisateur.

La figure 3.2 représente l'architecture de Xen. Les applications utilisateurs communiquent avec xend sous le mode client/serveur, xend assurant le rôle du serveur. La communication avec le noyau s'effectue sous la forme d'appels systèmes traditionnels Unix. Le noyau fait alors un hypercall en fonction de l'appel système et des paramètres reçus.

L'empilement de couches d'abstraction est ici une bonne chose, car cela évite de lier la partie utilisateur à l'interface de programmation de l'hyperviseur. Avec des couches d'abstraction entre eux, les composants de Xen peuvent évoluer séparément, il suffit de maintenir une simple interface entre les couches.

Les autres outils de gestion sont principalement commandes servant d'interface à xend, permettant de démarrer ou d'arrêter les domaines utilisateurs, ou encore de surveiller leur état (notamment la consommation mémoire et le temps processeur), un peu à la manière de la commande top de GNU/Linux.

Configuration

Xen stocke la configuration des domaines utilisateurs dans des fichiers de configuration, qui sont de simples fichiers textes éditables par l'administrateur.

Le fichier de configuration d'un domaine utilisateur comprend toutes les informations nécessaires à Xen pour pouvoir démarrer le système :

• le noyau à démarrer ;
• 'emplacement des fichiers du système invité (partition dédiée, LVM, répertoire, etc.) ;
• la quantité de mémoire vive à allouer ;
• l'adresse IP de la machine.

Avec ces informations et les fichiers du système invité, Xen est à même de démarrer un domaine utilisateur.

La configuration de l'hyperviseur se fait quant à elle soit dans le fichier de configuration du chargeur de démarrage, soit dans un fichier de configuration lu par xend au démarrage du domaine 0. En dehors de la configuration initiale lors de l'installation de Xen sur une machine, il n'est pas nécessaire de toucher à la configuration de l'hyperviseur.

Comme énoncé dans le paragraphe consacré aux fonctionnalités de Xen (section 2.7.3 page 56), Xen propose soit de dédier une partition à un système invité, soit de placer l'image du système dans l'arborescence du domaine 0. En pratique, cela implique peu de différences, car même dans le cas d'une partition dédiée, il est facile d'y accéder depuis le domaine 0, de la même façon qu'on accède à une clef USB ou un disque externe. Et, de la même façon qu'avec une clef USB ou un disque externe, l'attribution à un système invité d'une partition distincte de celle de l'hôte permet de déplacer et de sauvegarder facilement le système invité.

Ce système, couplé à une gestion de haut niveau des partitions avec la technologie LVM (Logical Volume Manager, gestionnaire de volumes logiques) permet de s'affranchir des disques physiques pour gérer les partitions accessibles par les systèmes d'exploitation. En effet, avec une couche d'accès aux disques utilisant LVM, il est possible d'agréger plusieurs disques en un seul espace de stockage, partitionnable librement et indépendamment de la configuration des disques. Par exemple, avec deux disques de 40 gigaoctets, il est possible par le biais de la couche LVM de créer une partition de 60 gigaoctets et une partition de 20 gigaoctets. Ce principe permet de faciliter grandement la gestion de l'espace disque pour un système d'exploitation, offrant la possibilité de créer autant de partitions que nécessaire en rajoutant simplement des disques à la machine. On peut alors combiner ces partitions avec du RAID logiciel, pour rajouter de la tolérance aux pannes matérielles.

La combinaison LVM plus RAID logiciel est à la fois souple, performante et fiable. C'est d'ailleurs la configuration recommandée par la communauté Xen pour un serveur en production.

L'instanciation du système invité est effectuée via l'utilitaire xen-create-image. Cet utilitaire, développé par un membre de la communauté, permet d'automatiser tout le processus de création du système invité, tant sur la partie récupération des fichiers et des programmes nécessaires pour avoir un système utilisable que sur la partie configuration de Xen. L'avantage de xen-create-image est sa grande flexibilité au niveau des options de création : on passe toutes les options au lancement du programme et il procède ensuite automatiquement à la création des fichiers nécessaires. Quand le programme se termine, le nouveau domaine utilisateur est prêt à être démarré.

La flexibilité de xen-create-image nous permet de créer très rapidement des nouveaux domaines utilisateur, en changeant simplement quelques paramètres lors de l'appel de la commande.

Pour un serveur web « typique », destiné à héberger des applications en PHP avec une base de données MySQL (ce qui représente l'écrasante majorité des applications web), l'utilisation de Xen au sein du processus d'hébergement est faite comme suit :

• Détermination des caractéristiques du système invité (espace disque, mémoire vive nécessaire, etc.) en fonction de celles de l'application (nombre d'utilisateurs, charge système, etc.) ;
• Allocation de l'espace disque sur un système hôte disponible ;
• Allocation de la mémoire sur le système hôte ;
• Instanciation du système invité par l'utilitaire xen-create-image ;
• Démarrage du nouveau domaine utilisateur ;
• Déploiement de l'application.

Avec cet utilitaire, l'utilisation de Xen pour l'hébergement de serveurs et le déploiement rapide de serveurs virtuels devient très simple. C'est un des gros avantages de Xen.

La section suivante sera consacrée à une analyse poussée du projet KVM, sur le même modèle que celle menée sur Xen.

Comparativement à Xen, le projet KVM est beaucoup plus récent. La première version publique date en effet de la fin de l'année 2006, avec une intégration au noyau Linux dès le début de l'année 2007. Les premières versions publiques étaient déjà quasiment fonctionnelles, les nouvelles versions ont simplement étendu les fonctionnalités.

À la fin du mois de février 2007, peu après l'intégration au noyau, la migration « à chaud » a été ajoutée, permettant de déplacer un système invité d'une machine physique à une autre avec une très courte interruption, sans devoir l'arrêter.

Après le mois de février a suivi une longue phase de maturation et de correction de bugs, visant à stabiliser le projet et à pouvoir séparer le module noyau du code en espace utilisateur. L'interface entre les deux a été déclarée stable durant le mois de mai 2007.

La société Qumranet, qui finance le projet, devrait présenter à la fin du mois de septembre son premier produit commercial, dont on ne connaît l'instant rien, si ce n'est qu'il aura un rapport avec la virtualisation.

Le projet KVM se compose de deux grandes parties : un module noyau et un programme utilisateur.

Module noyau

Le module noyau de KVM sert à communiquer avec le processeur et à utiliser les instructions de virtualisation. Les détails concernant ces instructions et les rôles respectifs du processeur et de la machine virtuelle pourront être trouvés dans [NSL+06] et [AMD06].

Concrètement, le module noyau sert à faire le relais entre la machine virtuelle, en espace utilisateur, le processeur et le système d'exploitation. La compréhension de son fonctionnement n'est pas nécessaire pour maîtriser l'utilisation de KVM.

Programme utilisateur

Le programme en espace utilisateur, sobrement dénommé kvm, est une version modifiée de QEMU, étendue pour pouvoir faire appel au module noyau.

Son fonctionnement général est identique à celui de QEMU, c'est-à-dire que c'est une machine virtuelle qui interprète et traduit les instructions du système invité. Toutefois certaines instructions ne sont plus traduites, mais gérées directement par le processeur, améliorant ainsi les performances.

Sous KVM, la gestion des systèmes invités et totalement différente de celle de Xen. En effet, ici le système invité est installé dans une image disque complète, qui est un seul et unique fichier pour le système hôte.

Pour déployer un nouveau système invité, on effectue donc une installation « standard », comme si on installait un système d'exploitation sur une machine physique. L'image disque ainsi créée est ensuite utilisable sur n'importe quelle autre machine physique disposant également de KVM⁷.

Afin d'éviter d'avoir à effectuer le processus d'installation à chaque fois que l'on a besoin d'un nouveau système, ce qui serait fastidieux, il est recommandé de stocker des images systèmes qui serviront de référence pour chaque nouveau système à déployer. Ainsi, on conserve sur un serveur des systèmes invités fraîchement installés, qu'on peut simplement copier sur la machine qui devra l'héberger en quelques minutes. Avec ce système, le déploiement consiste à copier l'image sur la bonne machine physique, démarrer le système invité, installer les programmes nécessaires puis installer l'application.

La configuration de KVM s'effectue par le biais des options de la ligne de commande, au moment de l'appel à kvm. C'est de cette manière que l'on décide de la quantité de mémoire vive à allouer au système, des périphériques supplémentaires à activer, de la configuration réseau, etc.

kvm exécute un script pour la configuration réseau, notamment pour la mise en place du pont entre les interfaces réseau, car il peut y avoir plusieurs méthodes pour cela, selon les besoins.

Le mode de fonctionnement snapshot (capture) de KVM permet de démarrer un système invité en lecture seule, sans altération de l'image système. Toutes les modifications de fichiers effectuées au sein du système invité sont uniquement conservées en mémoire, sans écriture sur le disque. Cela permet donc de démarrer un système invité, d'effectuer une action potentiellement destructrice (installation d'un programme inconnu, suppression de fichiers de configuration, etc.) et de revenir à l'état initial du système invité en redémarrant simplement le programme. Ce mode est extrêmement pratique quand on souhaite rapidement tester quelques modifications, sans avoir à copier une image système complète car le test est temporaire.

Une fonctionnalité complémentaire au mode snapshot est le mode overlay (surcouche). Avec ce mode de fonctionnement, très similaire au snapshot, les modifications apportées aux fichiers sont stockées dans un fichier supplémentaire, qui ne conserve donc que les éléments différents du fichier image original. On peut ainsi configurer deux systèmes séparément tout en conservant la même base. Ce mode de fonctionnement est très intéressant pour économiser l'espace disque, surtout lorsque les différences entre les systèmes sont mineures (par exemple, des détails de configuration d'une application).

La complexité de Xen, ainsi que son manque de documentation, sont des facteurs qui pourront se retourner contre le projet, à long terme. En effet, il est difficile dans cette situation d'attirer les contributeurs extérieurs, la période d'apprentissage nécessaire pour maîtriser le code source étant très longue (de l'ordre de quelques mois).

Il a fallu effectuer un véritable travail de recherche et de synthèse pour obtenir une bonne idée du fonctionnement interne de Xen, car les documents disponibles sont rarement à jour, et sont même parfois répartis sur plusieurs sites (site officiel, wiki, site de l'université de Cambridge, etc.). Cette complexité est un gros défaut si l'on souhaite un jour modifier le comportement de Xen. La documentation existante, notamment le manuel utilisateur, renseigne plus sur des détails de configuration de Xen que sur comment Xen fonctionne. Or, il est pour nous indispensable que l'on sache comment se il comporte dans une situation donnée.

De plus, du fait même de la technologie utilisée par Xen, un modèle à hyperviseur, le projet est condamné à rester en grande partie hors du noyau Linux, seules les modifications suffisamment génériques et peu intrusives ont une chance d'être intégrées au noyau, comme cela a été le cas au mois d'août 2007.

L'utilisation d'un hyperviseur a un autre effet : Xen doit réimplémenter tous les algorithmes d'ordonnancement entre les systèmes invités. En effet, l'hyperviseur étant le logiciel qui contrôle l'accès aux ressources (processeurs, mémoire vive, disques durs, cartes réseau, etc.), c'est à lui que revient la tâche de répartir les accès de manière équitable. C'est une tâche très complexe, qui est toujours la source de nombreux bugs. Ce travail d'ordonnancement des tâches est déjà effectué par le noyau Linux au niveau des processus du système d'exploitation, et Xen doit refaire le même travail pour les systèmes d'exploitation. Dans le noyau Linux, les modules d'ordonnancement sont l'objet d'années de développement et d'optimisation, il est à craindre que le projet Xen consacre une grande partie de ses efforts de développement à dupliquer les mêmes fonctionnalités pour simplement pouvoir faire cohabiter plusieurs systèmes d'exploitation sur la même machine.

Du côté communautaire, le récent rachat de la société XenSource par Citrix inquiète beaucoup la communauté, qui craint de voir XenSource se tourner de plus en plus vers un modèle propriétaire similaire à celui de Virtuozzo, la version libre devenant un simple produit d'appel, aux performances inférieures à la version propriétaire.

Il y a eu par le passé quelques tentatives de se tourner vers un modèle commercial plus rentable de la part de certains projets libres. On peut notamment citer le détecteur d'intrusions Snort, qui se sert d'une base de signatures pour repérer le trafic suspect. Les signatures sont véritablement le cœur de Snort, ce qui fait toute la valeur du projet. Il y a quelques mois, l'accès aux signatures les plus récentes est devenu payant, avec interdiction de les redistribuer. En réaction à cette fermeture, un projet parallèle, nommé bleeding Snort (jeu de mots avec bleeding edge, qui signifie « à la pointe ») s'est créé, et diffuse une base de signatures libre, et ce très régulièrement.

Cet épisode, loin d'être isolé, montre bien que les projets doivent faire très attention à l'image qu'ils diffusent auprès de leur communauté, sous peine de voir cette dernière se retourner contre le projet.

La société XenSource devra donc faire attention à ne pas s'aliéner la communauté et les contributeurs, lors des prochaines évolutions de Xen.

En définitive, Xen souffre de quelques problèmes, notamment au niveau de la documentation technique disponible et de la grande complexité du code source. Il faudra surveiller de près le comportement de XenSource par rapport au code source du projet, pour pouvoir anticiper tout changement dans la politique de licence.

Comparativement à Xen, le projet KVM a l'air plus intéressant, tant au niveau de la simplicité d'utilisation que de la complexité du code source.

En effet, étant donné que KVM est un simple processus au sein du système hôte, il n'a pas à réinventer tous les algorithmes d'ordonnancement pour obtenir de bonnes performances. La différence peut se résumer simplement par la citation suivante :

   « We get for free what Xen works hard to achieve. (Xen doit travailler dur pour obtenir ce dont nous bénéficions gratuitement.) »

         Dor LAOR, développeur de KVM

Dor LAOR met ici l'accent sur la différence primordiale entre Xen et KVM : comme KVM s'exécute au sein du système hôte, il bénéficie des fonctionnalités du noyau Linux en ce qui concerne la gestion des processus et des accès aux ressources, alors que Xen doit tout redévelopper.

On retrouve une différence au niveau de la communauté : les contributions externes sont plus nombreuses pour KVM que pour Xen, en dépit de la jeunesse du projet KVM. La différence peut facilement s'expliquer par la jeunesse du projet, la nouveauté étant toujours très attractive, ainsi que par la simplicité -par rapport à Xen -du code source.

De plus, le risque de changement de licence est très faible, et quasiment sans risque pour la pérennité du projet. En effet, maintenant que le code du module KVM est intégré au noyau Linux, il sera toujours diffusé avec, et si Qumranet vient à changer la license du projet, il restera toujours la partie libre intégrée au noyau, que n'importe qui pourra reprendre pour en faire un nouveau projet libre.

Toutefois, les performances sont encore à l'heure actuelle en deçà de ce que Xen offre, même s'il y a récemment eu des améliorations en ce sens. Les performances sont le dernier facteur limitatif de KVM pour l'utilisation en production et l'hébergement de serveurs. Sa grande simplicité lui vaut d'être déjà utilisé par beaucoup de monde pour les tests d'installation et l'utilisation bureautique. Il ne manque pas grand-chose pour que le monde de l'hébergement se tourne vers KVM, il y a déjà des discussions sur la liste de discussion parlant d'hébergements à base de KVM.