Pascal Haté

Introduction
Je pense qu’il est un sujet dont c’est un euphémisme de dire qu’il est à la mode : la virtualisation.
S’il y a encore quelqu’un qui n’a pas lu le mot sur internet ou dans une revue spécialisée quelconque c’est qu’il était dans le coma ou en voyage au fin fond de l’Himalaya.
Je vais ici parler de virtualisation Open Source car si comme pour les systèmes d’exploitation on parle souvent de Microsoft, pour les bases de donnée d’Oracle : pour la virtualisation, on parle souvent de Vmware.
Et bien entendu dans ce domaine, comme dans la quasi totalité des autres domaines de l’informatique, l’Open Source apporte SA (ses) solution(s).
Toutefois, avant d’étudier “LA” solution (Xen), nous allons commencer par voir quelles sont “les” solutions.

En effet, le mot virtualisation est un abus de langage amené par les journalistes et les consultants pour simplifier comme souvent au maximum les problématiques, recouvrir et condenser sous un même mot un nombre important de choses et de concepts pour amener leurs lecteurs ou clients au coeur de l’information qu’ils veulent délivrer.
Ici, (et c’est l’honneur et le rôle d’un blog technique comme celui de Devoteam), nous allons, à rebours, rentrer dans la forêt des concepts techniques et scientifiques de ce domaine de l’informatique cachés par l’arbre qu’est le simple mot de virtualisation.
Il existe en réalité trois (et même quatre, mais la quatrième nous ne ferons que la nommer sans le présenter plus avant) façons de faire de la virtualisation. Tout dépend où l’on place la couche de virtualisation :

1. l’isolation d’application,

2. la virtualisation complète (et par extension, l’émulation),

3. la para-virtualisation.

La fameuse quatrième méthode dont nous ne parlerons pas ici qui est représentée principalement par les produits UML (User-Mode-Linux) et coLinux : le noyau en espace utilisateur.
Il n’y a maintenant plus grand chose d’intéressant dans UML par rapport à la para-virtualisation, sinon la facilité de développement qu’il apporte au niveau du noyau.
Nous allons présenter et expliquer les concepts qui sont derrière chaque technique de virtualisation, parce que les maîtriser, permettra à tout un chacun de savoir et de comprendre de quelle virtualisation il a besoin et il peut vouloir ; plutôt que de se laisser imposer un système qui ne leur conviendrait pas obligatoirement par des gens qui n’ont qu’une vue parcellaire et étriquée, biaisée, ou intéressée de ce domaine de l’informatique.

Explication des concepts scientifiques et des implémentations
qui en ont été faites

L’isolation

Que nous dit Wikipedia de l’isolation dans la Virtualisation (car on ne va pas réinventer à l’infini ce qui a déjà été mieux dit) ?
Un isolateur est un logiciel permettant d’isoler l’exécution des applications dans des contextes ou zones d’exécution. L’isolateur permet ainsi de faire tourner plusieurs fois la même application (à base d’un ou plusieurs logiciels) prévue pour ne tourner qu’à une seule instance par machine.
Par exemple, nous pourrons avoir plusieurs apache qui écoutent sur le port 80, ou plusieurs instances de Tomcat qui écoutent sur le même port, etc.
On peut donc avoir un contexte d’exécution propre et unique pour chaque application, la couche de virtualisation se situe au niveau même du système d’exploitation (qui a été modifié en conséquence).
On reprend, on étend et améliore les concepts de base des BSD Jails ou Zone Solaris .
Les produits phares (ultra performants dans leur catégorie) sont Linux VServer et OpenVZ (ce dernier porté sous Windows a donné Virtuozzo).
L’avantage de ce mécanisme de virtualisation est clair : c’est la performance, aucune autre technique n’existe actuellement qui donne une meilleure performance, les pertes par rapport à une application installée sur une machine physique sont infinitésimales.
L’inconvénient majeur c’est que le système d’exploitation est unique et commun entre toutes les applications virtualisées. On partage le même noyau, le même espace mémoire, etc. On ne peut donc pas virtualiser intégralement une machine avec son noyau, ses bibliothèques, etc. etc.

La virtualisation complète (et l’émulation)

Ici, c’est simple : on virtualise le « matériel » donc on peut prendre le CD fourni par le distributeur (Microsoft, RedHat, Novell, etc…), le mettre dans le lecteur de cdrom (ou en faire une image ISO), et on installe son système « comme si » on était sur une machine physique.
Ce concept apparu plus « récemment » est finalement le plus « évident » à concevoir (mais pas forcément le plus simple à implémenter).
L’avantage énorme de ce système de virtualisation est évident : on ne modifie rien à son CD d’installation, tout doit être vu par le système comme s’il était sur une machine physique.
L’inconvénient majeur c’est une perte de performance assez phénoménale (minimum 20%) du fait même du concept utilisé : on va analyser tous les appels passés par le système d’exploitation au « matériel » qu’il croit être réel. Tous les appels x86 sont envoyés brut de fonderie, captés par la couche de virtualisation, translatés, transformés, manipulés, et envoyés au matériel physique. Les réponses repassent par la couche de virtualisation, qui les manipule, les transforme, les translate, et les renvoie à la bonne machine virtuelle ; etc. etc. etc.
C’est très lourd !
Les produits les plus présents en Open Source dans ce domaine là sont Qemu et virtualBox. Côté logiciels propriétaires on trouve Vmware Server et dans une certaine mesure Vmware ESX même s’ils ont largement optimisé cette partie là, le principe reste le même.
Ce sont donc des produits pratiques, simples d’utilisation que l’on installera plutôt sur son propre ordinateur, pour faire des tests, avoir un autre système d’exploitation que le sien pour éviter de tout casser sur sa propre machine mais qui ne servent pas en production sous aucune forme que ce soit (sauf pour ESX évidemment, qui est la seule solution propriétaire actuellement viable en matière de virtualisation complète en production de masse).
Quid de l’émulation ? c’est l’extension du même concept de virtualisation au matériel. Quand je disais plus haut : « on virtualise le matériel », ce n’était pas tout à fait exact. En fait, on présente le matériel sous-jacent à la machine virtuelle. Ca permet d’économiser pas mal de puissance. Mais on peut tout à fait émuler du matériel : on peut, par exemple, avoir un processeur SPARC ou RISC émulé sur un matériel X86 … Evidemment, je ne vous dirai rien sur les performances d’une telle solution, on n’est pas là pour ça, les gens qui veulent faire ça, le font plus dans le cadre d’un laboratoire, d’un environnement de test et/ou développement. Le logiciel phare de cette technologie est Qemu.

La Para-virtualisation

En marge de ces deux concepts, une équipe des laboratoires d’informatique de l’Université de Cambridge menée par Ian Pratt en Angleterre a développé un nouveau concept : la para-virtualisation. Pour la comprendre revenons aux principes de fonctionnement du matériel x86.
Lorsque IBM a conçu ses premiers ordinateurs personnels, il les a équipés du matériel le plus bas de gamme qu’il trouvait (surtout au niveau processeur), qui ne possédait qu’un jeu d’instructions matérielles limitées et surtout qui nécessitait de la part du système d’exploitation de passer en mode prioritaire pour accéder aux registres, aux interruptions, aux bus, etc etc. Ceci allait très bien dans le cas où ledit système d’exploitation était seul au monde sur son matériel.
Là où c’est devenu compliqué c’est que le succès et les améliorations formidables des plates-formes x86 aidant, ce matériel est devenu de plus en plus commun dans les grands centres informatiques, au point de se rendre majoritaire et indispensable dans toutes les DSI. Et quelque chose qui était possible et même commun avec les vrais grands processeurs professionnels de l’époque (le partage de temps entre les systèmes d’exploitation), était impossible avec ce matériel là, alors que sa puissance le permettait.
Au final, si l’on regarde et que l’on rationalise les instructions x86, on s’aperçoit qu’il n’y a pas beaucoup à faire pour que les systèmes d’exploitation soient nettoyés de ces instructions privilégiées et que l’on rende le matériel (en l’aidant d’une couche de virtualisation), et les systèmes d’exploitation (en les modifiant un peu) virtualisables !
C’est le concept de la para-virtualisation : on développe une couche minuscule de virtualisation qui sera directement posée sur le matériel (un hyperviseur), et on modifie le système d’exploitation invité pour le rendre « virtualisable ».
L’avantage fondamental de cette technique c’est la puissance. Il y a une perte infime en matière de performances (certes plus grande que pour l’isolation, mais comme je l’ai dit, il n’y a rien de mieux en matière de performances que l’isolation). Le système para-virtualisé se comporte presque comme s’il était directement sur le matériel.
L’inconvénient incontournable c’est qu’il faut que le système d’exploitation soit modifié : exit donc Microsoft qui ne fournit pas de version « para-virtualisée » de son système d’exploitation. On ne pourra avoir que Linux, BSD, et quelques autres systèmes plus minoritaires dans les entreprises.
A l’heure où ces lignes sont écrites le SEUL hyperviseur para-virtualisateur qui existe sur le marché est Xen. Pour l’instant, en effet, car lorsque Windows 2008 sortira, son système Hyper-V sera lui aussi un système de para-virtualisation qui pourra même exécuter des machines virtuelles « xénifiées », et de même il sera possible de para-virtualiser des serveurs Windows 2008 dans un hôte Xen.

Xen et Vmware ESX

Chacun resterait dans son monde et personne n’embêterait personne, si Intel et AMD n’avaient pas ajouté leur « grain de sable » dans les processeurs. En effet, Intel et AMD ont annoncé respectivement la création des processeurs Vanderpool (en septembre 2003) et Pacifica (en février 2005), ce qui a vu la naissance et l’apparition de nouvelles instructions matérielles dans les processeurs Intel-VT et AMD-V.
Qu’apporte cette technologie de virtualisation matérielle ? Tout simplement la possibilité aux logiciels qui savent l’utiliser de déléguer une partie du travail de virtualisation au matériel. Ceci permet notamment à un logiciel comme Xen de faire fonctionner des systèmes d’exploitation non modifiés (comme par exemple, mais c’est juste un exemple hein …) Windows, tout en conservant de très bonnes performances.
Au final, et sous couvert d’utiliser des processeurs assez récents (ce qui est le cas si on achète du nouveau matériel de nos jours), avec Xen on gagne sur les deux tableaux : on fait de la virtualisation complète de systèmes non modifiés (comme avec Vmware ESX), et on fait de la para-virtualisation dans le même temps avec les systèmes d’exploitation qui le supportent (Linux, BSD, etc), et on gagne sur les performances.
Vmware va proposer son propre système de para-virtualisation et la version ESX 3.5 va relancer la course à la performance en intégrant également la gestion des systèmes matériels AMD-V et Intel-VT, la différence ne se fera donc plus là à l’avenir alors qu’elle s’y fait aujourd’hui pour les versions 3.0.
Par contre, Vmware ne gère « que » 256Go de RAM sur les serveurs de virtualisation, Xen va jusqu’à 8To de RAM. Enfin, Xen gère les architectures IA64, ou PowerPC ou SPARC et Vmware ? « Uniquement » X86 ! Pour ceux qui veulent réutiliser du matériel (cher à leurs yeux), qu’ils auront libérés en migrant leurs anciens serveurs Unix propriétaires vers Linux qui leur restent sur les bras, c’est un bon moyen de réutiliser et valoriser à nouveau ce matériel qui était d’une robustesse et d’une qualité incomparables !
Au fait ? les systèmes d’exploitation Windows virtualisés sur Vmware sont-ils supportés officiellement par Microsoft ? Que nenni ! alors que ceux virtualisés sous Xen oui… Ca peut faire réfléchir quelques décideurs frileux de perdre le support éditeur.