====== 1. Introduction ====== Les techniques de **virtualisation** sont diverses et peuvent répondre à plusieurs problèmes. Il y a en général deux grandes catégories de virtualisation: * Utiliser un même matériel pour plusieurs logiciels non prévus pour coopérer (ex: des systèmes d'exploitation), ce qui est souvent désigné de préférence par le terme **virtualisation** * Utiliser un logiciel dans un environnement matériel et/ou logiciel non prévu à cet effet, on parle alors d**'émulation** La frontière entre émulation et virtualisation est mince et les deux concepts sont en général indissociables. On verra que les meilleurs logiciels de virtualisation sont également les meilleurs émulateurs, et vice-versa. Dans le scénarion de virtualisation, on appelle le système d'accueil l**'hôte** (//host//) et le système émulé l**invité** (//guest//). ====== 2. Emulation de la couche logicielle ====== Dans le cas où l'on n'a pas besoin de changer de plateforme matérielle, on peut utiliser des programmes prévus pour des environnements logiciels différents simplement en émulant ceci avec un logiciel présentent les caractéristiques (API) identiques mais étant prévu pour tourner sur la plateforme de réception. ===== FreeDOS, Wine ===== Si on reste dans le monde du PC, les exemples les plus connus sont [[http://dosemu.sourceforge.net/| DOSEMU]] et [[http://www.winehq.org/| Wine]]. Ces logiciels sont des //portages// (re-programmation au dessus d'un environnement logiciel différent tel que POSIX/UNIX) de couches logicielles connues, et profitent du fait que le processeur est inchangé pour utiliser des programmes binaires non natifs tels quels. Du point de vue de l'hôte, l'émulateur est un applicatif et possède les droits restreints habituels. Cette tehnique ne permet donc pas (en général) de profiter des pilotes de périphérique de l'invité pour gérer un matériel (réel) exotique. ===== UML ===== [[http://user-mode-linux.sourceforge.net/ |User-mode Linux]] est un cas intéressant: il est possible (avec Linux 2.4 et 2.6) de compiler le noyau Linux en tant que simple application. Il est alors possible de lancer une distribution GNU/Linux de même plateforme à partir d'une autre distribution, et en particulier d'avoir un environnement où l'on semble posséder une "machine virtuelle avec GNU/Linux". Le manque d'émulation du processeur n'assure pas la sécurité et le cloisonement habituel entre les applications et le noyau, donc cette solution n'est pas viable pour des utilisations de "production". Par contre UML est extrêmement utile pour étudier ou développer le noyau lui-même, sans passer par la lourdeur d'un émulateur complet ou d'un matériel dédié (on peut "booter" instantanément). ====== 3. Emulation matérielle ====== L'émulation matérielle consiste en premier lieu à reproduire le fonctionnement d'un processeur, en écrivant logiciellement les opérations classique de décodage et intérprétation des mots machines. Mais cela n'est pas suffisant, pour qu'un logiciel - et en particulier un OS - puisse être exécuté sur un processeur émulé, il lui faut également un environnement suffisant : contrôleur clavier, écran, réseau, etc. L'émulation consiste alors à reproduire le comportement des "puces électroniques" de matériel réel; il s'agit en quelque sortes de "pilotes de périphériques inversés". ===== QEMU ===== QEMU est un émulateur complet, il permet notamment d'émuler plusieurs processeurs (i386, x86_64, ARM, MIPS, SPARC, etc.), de nombreux matériels divers et "populaires" (interfaces réseau, son, vidéo, etc.) et donc de fournir à un système d'exploitation quelconque l'illusion complète d'une plateforme matérielle d'accueil. Dans le cas où l'hôte et l'invité partagent le même type de processeur (et pour certains processeurs), QEMU peut profter de cet avantage et effectuer des "adaptations" du code binaire et l'exécuter nativement plutôt que de passer par une émulation du processeur. Il est alors possible d'émuler un système matériel complet avec une perte minime de performances entre l'hôte et l'invité (5 à 10%). ===== Valgrind ===== [[http://valgrind.org/| Valgrind]] est un cas à part de l'émulation: il est destiné aux développeurs de logiciels et leur fournit un processeur équivalent (type i386) mais équipé de nombreux outils d'analyse donnant des informations poussées sur le comportement d'un programme, qui ne pourraient être obtenues à l'aide d'un processeur matériel. ===== Consoles de jeu ===== Les efforts d'émulations furent initialement concentrés sur l'adaptation de plateforme matérielle de jeu telles que les consoles, grâce à l'essor de la plateforme générique PC et de sa montée en puissance. A peu près toutes les consoles historiques et actuelles peuvent être émulées de manière générique (c'est-à-dire sous n'importe quel système d'exploitation moderne). Exemples : * [[http://www.mame.net/| MAME]] * [[http://www.zsnes.com/| ZSNES]] * [[http://psxemulator.gazaxian.com/| pSX]] ====== 4. (Para-)virtualisation ====== La **virtualisation** en tant que telle désigne en générale la faculté d'utiliser un unique matériel et de le présenter comme un équivalent de plusieurs plateformes virtuelles équivalentes, en partageant les ressources réelles (capacité mémoire, stockage, etc). Ces systèmes sont en général composés de deux éléments distincts : * le **système hôte**, dont le rôle est de gérer les systèmes invités, voire assurer le partage des ressouces * les **systèmes invités**, qui sont les sytèmes installées dans leur "plateforme virtuelle" ===== Technologies ===== On distingue deux approches principales pour la virtualisation : * la **virtualisation complète**: chaque "plateforme virtuelle" est une émulation fidèle et complète permettant notamment de faire tourner un système d'exploitation tel quel * la **para-virtualisation**: dans ce modèle, le système invité héberge un système d'exploitation qui est conscient d'être sur une plateforme virtuelle et coopère avec lui La **virtualisation complète** a bien sûr l'avantage de la transparence et de garantir le fonctionnement de tous les logiciels existants pour une plateforme donnée, notamment ceux historiques. Mais elle souffre en général d'une pénalité en performance et complexité pour assurer l'émulation du matériel. La **para-virtualisation** requiert un système d'exploitation modifié, en général au niveau le plus bas de son noyau. Si cela est facile à effectuer avec Linux, ce n'est pas le cas de la plupart des sytèmes d'exploitation propriétaires. Cependant dans ce cas la virtualisation est plus simple car il n'y a pas de matériel à émuler, et l'invité peut profiter de performances quasi-natives pour l'accès aux ressources. **Note**: récemment les processeurs x86 ont été équipés d'extensions permettant une réelle **virtualisation complète**. En effet avant ceux ci (Intel VP et AMD-V), cette technique demandait une émulation partielle du CPU. ===== Linux-VServer ===== [[http://linux-vserver.org/Welcome_to_Linux-VServer.org| Linux-VServer]] est une technologie de **para-virtualisation** limitée, mais historiquement la première et également la plus simple dans le monde de Linux. Cette technique permet uniquement de lancer des systèmes invités utilisant le **même noyau** que le système hôte. On parle de //kernel level isolation//, car dans les détails il s'agit en fait de cloisonnement à l'intérieur d'un noyau standard, faisant croire à différentes applications qu'elles ont une vue personnalisée et isolée des autres du noyau. Cependant tous les sytèmes invités partagent les mêmes ressources matérielles, et doivent coopérer (au moins au niveau de leur configuration initiale) pour les partager. ===== Xen ===== [[http://www.xensource.com/products/xen/| Xen]] est une technologie de para-virtualisation. Il utilise pour ce faire son propre système hôte, qui est un noyau très simplifié appelé l**'hyperviseur** dont le rôle va être d'arbitrer l'exécution des systèmes invités. Xen ne se chargeant que de l'arbitration bas-niveau (CPU, RAM, DMA, interruptions), il va reposer sur un système d'exploitation (GNU/Linux par exemple) pour gérer le matériel au sens large (vidéo, réseau, disques, etc). Le système d'exploitation dédié à cette tâche est appelée le **dom0**. Les systèmes virtualisés - appellés **domU** - vont alors pouvoir accéder aux ressources telles qu'elles seront gérées et présentées par le **dom0**. L'administration des "plateformes virtuelles" se fera donc naturellement depuis un système standard dédié à cette tâche. ===== KVM ===== [[http://kvm.qumranet.com/kvmwiki| KVM]] (Kernel-based Virtual Machine) est une technologie de virtualisation similaire à Xen, mais récente et apportant les différences notables suivantes : * pas d'hyperviseur, les fonctionnalités comparables étant implémentées directement dans Linux * possibilité d'effectuer une virtualisation complète à l'aide de QEMU si nécessaire Cette technologie, bien que jeune (intégrée dans Linux depuis la versin 2.6.20) est extrêmement fonctionnelle et probablement plus facile à maintenir à terme. Le fait que Linux lui-même soit l'hyperviseur promet la possibilité de virtualiser toutes les plateformes ou Linux tourne (bientôt dans votre montre). Et le renfort de QEMU garantit que dans les cas ou la para-virtualisation n'est pas possible (système invité non modifiable), toutes les options restent ouvertes (avec des dégradations de performance proportionnelles). ====== 5. Récapitulatif ====== ^ **Solution** ^ **Emulation CPU** ^ **Emulation plateforme** ^ **Utilisation**^ | **Wine** | non | non | Emulation Windows| | **UML** | non | non | R&D, sandboxing| | **Valgrind** | oui | non | Analyse| | **QEMU** | oui | non | R&D (cross-platform), sandboxing| | **QEMU-System** | oui | oui | Virtualisation| | **Linux-VServer** | non | non | Virtualisation| | **Xen** | non | non | Virtualisation| | **KVM** | non | oui (via QEMU) | Virtualisation|