Virtualisation vs. Emulation

La question de l’émulation ou de la virtualisation revient souvent, très souvent.

ll faut dire que la communication des divers éditeurs de l’une ou l’autre des approches ne nous aident pas à avoir les idées claires.

• Qu’est ce qu’une émulation ?
• Qu’est ce qu’une virtualisation ?
• Quelles sont les différences ?
• Quand dois je émuler ? Quand dois je virtualiser ?
• Quelles sont les solutions disponibles ?
• Quelles sont les impacts de performances ?

C’est en synthèse ce que je me propose de partager avec vous au travers de ce billet.

Tous les commentaires sont les bienvenus.

Emuler c’est faire semblant de, se “déguiser” en quelque chose que l’on n’est pas.

En informatique, ce qui permet à une plateforme de se déguiser en une autre est un émulateur.

Un émulateur est constitué de code binaire dédié à la plateforme d’origine, celle qui l’exécutera.
C’est ce code qui tel un Oudini informatique, permettra à la plateforme de se déguiser en une autre.

Exemple, je souhaite faire tourner “StarCraft”, célébrissime jeu de stratégie sous Windows,  sur ma debian (distribution Linux).

Je vais pour cela opérer en deux étapes:

1. Installer un émulateur, le logiciel qui me permet de déguiser mon système d’exploitation (matériel + logiciel) en quelque chose d’autre, ici en Windows.
2. J’installerai ensuite le jeu en question au sein de mon émulateur s’éxécutant directement depuis mon système d’exploitation natif…Linux.
   Ce faisant je pourrai lancer la procédure d’installation puis le jeux en question sur une plateforme pour laquelle il n’est absolument pas compatible.

Mon exemple n’est pas innocent, les deux systèmes d’exploitation n’ont ni le même système de gestion de fichiers, ni le même format de binaires…

Grâce à mon émulateur, et tant que ce dernier s’exécutera, je déguise, mon système Linux en Windows, émulant, mimant parfaitement ce dernier.

Dans mon exemple je me suis limité à “mimer” un environnement de système d’exploitation, sachant que même si les deux formats de fichiers sont incompatibles, tous les deux encapsulent des données binaires compatibles puisque mon Linux pour PC à processeur Intel Ix86 et Windows sont dédiés au même processeur.

Mais un émulateur peut aussi mimer un processeur Sparc (Sun) ou un Motorola 6502 (celui des premiers Apple, rappellez vous).

Dès lors ce formidable outil permettra de faire tourner sur une plateforme X, un système d’exploitation et des applications initialement conçues pour une plateforme toute autre (matériels et logiciels différents).

Il exite de nombreuses solutions d’émulations pour Linux, la plus célèbre n’est autre que Wine (parce qu’il est gratuit et très efficace).

Mais Wine à son pendant commercial que je vous engage réellement à esssayer: CrossOver, plus souple, plus “packagé” il fait gagner un temps tel qu’il vaut tous les centimes des quelques 60 euros de sa licence.

Grâce à l’une ou l’autre de ces solutions vous pourrez sous Linux faire tourner Office 2007 (avec des performances que vous ne soupçonnez pas… oui c’est plus rapide que sous Windows!) ou toute autre application qui manquerait cruellement à vos habitudes Microsoftiennes ou encore à votre productivité…

Ces deux applications phares ne permettent pas d’émuler un autre matériel, un autre processeur, si tel est votre objectif je vous invite à vous tourner vers QEmu.

Il y a t il des limitations ? Bien sûr (hélas) !

Dans le cas de mon exemple d’Office 2007 sous CrossOver, oui les applications sont bien plus rapides à se lancer, car certains appels à .Net sont éliminés, ce qui veut dire aussi que certaines fonctions propres à ce middleware ne seront pas assurées (comme les mises à jours des correctifs par exemple)… On devra alors les appliquer à la main.

En terme de charges, l’émulateur est un processus natif de votre plateforme, si cette dernière est déjà totalement surchargée au moment ou vous lancerez une application dépendant de l’émulateur, et par la même l’émulateur lui même… alors les performances ne seront clairement pas au rendez-vous.

La gestion de performance d’un émulateur est le fruit d’un juste équilibre entre ce que vous émulez et ce sur quoi vous l’émulez.

En terme clair c’est un ratio:
Puissance nécessaire à faire tourner l’application émulée (x variable) + charge de l’émulation (k constante) / Puissance disponible par la plateforme faisant tourner l’émulateur (X si le nombre d’applications pouvant tourner en parallèle est variable, K autrement)

Faire tourner une application suspecte dans un émulateur me protège t il de tous mauvais tours que cette dernière pourrait me jouer?

Oui et non.

Si l’application suspecte est compatible au format binaire avec la plateforme d’origine, la réponse est non!
Car faire tourner une application suspecte compatible DOS 3.1 depuis un émulateur sous XP ne protège en rien mon environnement XP d’une quelconque infection.

Si l’application suspecte n’est pas compatible, alors le risque est moindre, car en général un virus ou tout autre application “comique” va chercher en tout premier lieu à infecter un format de fichier qu’elle connait.

Retenez néanmoins, que l’émulateur n’est en rien une boite à sable, une “Sand Box”, puisqu’il s’exécute depuis votre système de gestion de fichiers, il a accès à ce dernier en totalité!
Ce n’est pas un défaut il a été conçu pour ça. Il mime un environnement ou un processeur pour exécuter une application, mais toutes les sauvegardes, tout le travail réalisé doivent pouvoir être stockés sur la plateforme d’origine, c’est là tout l’intérêt.

C’est aussi LA différence majeure avec la virtualisation, qui comme nous allons le découvrir offre par conception une étanchéité parfaite entre toutes les machines virtuelles…enfin plus ou moins, suivez moi…

Commençons tout de suite par quelques termes dont les informaticiens ont le secret.
Nous appellerons machine hôte, la machine sur laquelle nous allons éxécuter l’application de virtualisation.
Nous appellerons machine invitée, la machine virtuelle s’éxécutant sur la machine hôte depuis l’application de virtualisation.

Si émuler c’est se déguiser, mimer, virtualiser c’est partager, diviser, répartir les ressources physiques et logiques de la machine hôte et faire en sorte que ce partage soit assuré quelque soit la charge de la machine hôte.

L’application en charge de ce partage parfait se nomme un hyperviseur, c’est le coeur de toute virtualisation.

Les applications de virtualisation classiques offriront toutes les fonctionnalités de la virtualisation depuis le système d’exploitation qui les exécutent.

Nous trouverons parmis ce type d’Hyperviseur applicatif des solutions aussi connues que VMWare Workstation (solution Windows), Parallel Desktop (solution Mac) ou encore VirtualBox (multi plateformes).

Avant d’aller plus loin, revenons sur la notion de partage sous tendues par toutes ces applications.

L’idée est simple, imaginons que vous disposiez de 4 Go de Ram, d’un processeur à deux cores, vous pourrez alors créer une machine virtuelle composée comme suit:

• 2 Go de Ram, et un processeur à un core…
• 512 Mo de Ram et un processeur à 2 cores (performances moins bonnes pour des raisons évidentes…puisque la machine virtuelle empiète à 100% des ressources processeur).
• 3Go de ram et processeur à 2 cores (performances divisée par deux en comparaison d’une machine physique de  même configuration, puisque plus de 50% des ressources globales de la machine hôte sont réquisitionnées par la machine virtuelle…ce qui n’est pas très raisonnable)

C’est magique et ça marche à ravir…

Quid de la machine virtuelle, comment est elle représentée ensuite sur la machine hôte ?
Comme un ensemble de fichiers stockés sur le système de gestion de fichiers de la machine hôte.

On trouvera toujours deux grandes catégories de fichiers:

1. Les fichiers de configurations, qui décrivent la configuration de la machine virtuelle… qu’il est possible de modifier par la suite, de la même manière que l’on rajoute du matériel sur sa plateforme.
2. Les fichiers représentant le ou les disques virtuels, contenant toutes les applications, les fichiers de productions, les numéros de licence etc…

Que se passe t il alors si l’on déplace ces fichiers sur une autre machine hôte équipée du même hyperviseur ?
On retrouve la totalité de sa machine virtuelle… aussi simplement que ça.

Cela veut il dire que toute une machine peut alors être sauvegardée sur un DVD et envoyée au bout du monde ? Oui !

Que se passe-t-il en terme de gestion concurrente des périphériques et du matériel de façon général (ex: une webcam, une clé USB, un lecteur de disquette…) ?

En ce qui concerne les périphériques non « removables »,non détachables, ils sont « attachés » à la machine virtuelle au travers de la configuration de cette dernière… n’oublions pas, virtualiser c’est partager…
Ce qui veut dire que tant que la machine virtuelle tourne, la machine hôte n’a pas ou peu d’accès sur ces périphériques.
Pour les périphériques amovibles par définition, comme une clé USB, une petite fenêtre apparaitra demandant à qui est destiné le périphérique nouvellement en place: Machine hôte ou machine virtuelle, à condition bien évidemment que l’on ait configuré la machine virtuelle avec un controlleur USB, dans le cas contraire tout périphérique de cette nature sera « pris » à la volée par la machine hôte, comme si la machine virtuelle n’existait pas.

Quid des performances ?

Si nous reprenons notre ratio:
Puissance nécessaire à faire tourner l’application virtualisée (x variable) / (puissance virtuelle disponible (k constante) = à la puissance réelle pour une même machine physique)

Le travail principal de l’hyperviseur applicatif, l’application de virtualisation, est de s’assurer qu’au dénominateur on aura toujours une constante, identique, ou presque à celle disponible sur une machine physique de même puissance…A condition que les ressources de la machine virtuelle soit strictement inférieures aux ressources globales de la machine hôte.

Si je décide de tester une application suspecte au sein de ma machine virtuelle, suis je totalement protégé sur ma machine hôte ?

Oui ! complètement à 100%, sauf (oui je sais, j’ai dit sauf…) si vous avez autorisé une quelconque communication entre la machine virtuelle et la machine hôte… dans le cas contraire vous n’avez rien à craindre.

En cas de soucis il reste alors à supprimer la copie de la machine virtuelle (car on aura fait une copie n’est ce pas ? réinstaller une machine virtuelle est aussi long que d’installer une machine physique), et repartir sur une version saine.

Que se passe t il si le système d’exploitation de la machine hôte plante ? Et bien, tout plante… puisque la machine virtuelle n’est rien d’autre qu’une application tournant sur la machine hôte en question.

C’est  justement pour résoudre ce problème que sont nés après les “Hyperviseurs Bare Metal”, traduisons les Hyperviseurs en métal renforcé, appellation qui désigne des solutions de virtualisation totalement indépendantes de la stabilité du système d’exploitation de la machine hôte… et pour cause elles sont installées avant tout système d’exploitation !

L’hyperviseur “Bare metal” (schéma ici de la solution Microsoft, source Wikipédia, mais on trouvera la même approche chez VMWare ou Citrix), s’installe directement sur le matériel, c’est lui qui se lance en premier, et c’est depuis la console d’administration de l’hyperviseur que l’on lancera les machines virtuelles, qu’on les administrera, etc…

On le voit clairement sur ce schéma, toute application de ring 0 peut planter, sans mettre en péril les machines virtuelles concurrentes… Ici nos amis de Microsoft ont même inventé pour l’occasion le ring level de niveau –1, pour mettre en exergue l’encapsulation offerte, ainsi que le niveau d’étanchéité qui va de paire.

Ces solutions sont aujourd’hui réservées à des approches serveurs, et sont assez onéreuses.
La raison de leur isolation dans le parc des serveurs est relativement simple à comprendre.
Comme nous l’avons dit, l’hyperviseur est directement installé sur le matériel, matériel que par la suite il aura la charge de partager entre toutes les machines virtuelles du niveau N+1.

C’est justement la gestion de ce matériel qui pose problème et qui pour le moment cantonne ces approches au monde des serveurs, dont on peut exiger une configuration matérielle donnée. C’est à contrario impossible pour le segment des stations de travail…

Il faut néanmoins savoir, qu’il y a deux jours, nos amis de chez Citrix (ex Xen) ont pris tout le monde de vitesse en proposant le premier hyperviseur bare métal dédié aux stations de travail, coupant ainsi l’herbe sous le pied de leur ennemis juré VMWare.

Clairement donc, la virtualisation totalement matûre dans le monde des serveurs, parfaitement maitrisé en terme d’hyperviseurs applicatifs dans le monde des workstation, est en train de doucement mais surement devenir bare-metal sur ce segment aussi, pour notre plus grand bonheur à tous.

Je suis personnellement un fervent défenseur de la virtualisation.
C’est la meilleure façon d’optimiser le coût de son matériel, de disposer sur une seule et même machine de plusieurs OS sans les inconvénients du multiple boot, de permettre de sauvegarder ces dernières, de transporter au sein d’un unique laptop un réseau virtuel, adossé à un serveur et à une ou deux stations (avec pas mal de mémoire et un très, très bon processeur).
L’arrivée sur les machines nomades de processeurs de type I7, quadruple cores, avec Hyperthreading, autorisant 8 coeurs virtuels est une porte ouverte à toutes les fantaisies…
Si vous n’avez jamais essayés, testez vous serez rapidement conquis, rien ne vous empêchant de combiner une émulation au sein d’une machine virtuelle… les combinaisons et les avantages deviennent alors infinis.

Voila vous savez tout ou presque.
Vous passez trop de temps devant votre écran

Au plaisir de vous lire
Christophe Carvounas