Déroulement de l’article

Au cours de cet article, nous découvrirons les techniques et technologies qui sont liées à Xen et à la virtualisation. Nous commencerons par un bref retour sur les débuts de la virtualisation, puis l’environnement dans lequel est né le projet Xen, ainsi que ses fonctionnalités. Nous poursuivrons par l’architecture d’un système Xen, les apports de Xen 3.0 et ce que l’on peut attendre de la version 3.1.

Historique et environnement

Les premiers essais de virtualisation ont eu lieu dans les années 60 au centre de recherche Watson d’IBM, avec le projet M44/44X dont le but est d’évaluer et de développer le concept de système à temps partagé. L’architecture est basée sur un IBM 7044 (M44) sur lequel fonctionnent des machines virtuelles (44X), images expérimentales de la machine principale. IBM a poursuivi dans cette voie, où la machine virtuelle est une image du système sous-jacent, et a développé de nombreux systèmes basés sur des machines virtuelles. Comme le CP-40, développé pour une version modifiée de l’IBM 360/40. Le CP-67 pour l’IBM 360/67, ainsi que la fameuse VM/370 pour ces System/370 et d’autres encore. La famille des System/360 (1964), System/370 (1970) et System/390 (1990) permet de consolider une mainframe en autorisant plusieurs OS (CMS, OS/360, MVS) et applications à partager une unique machine. Les versions plus récentes, System/390, supportent GNU/Linux comme système invité. Une présentation de Xen 3.0 a été faite lors de FOSDEM 2006. Vous trouverez une vidéo sur ftp.belnet.be dans mirror/FOSDEM. La plupart des grandes sociétés historiques de l’informatique ont développé leurs mainframes, machines virtuelles et OS. Puis, est venu le temps de la micro-informatique, de son processeur unique, de son OS unique et mono-tâche. Au fil du temps, l’OS mono-tâche est devenu multitâche, les processeurs s’apparient et gagnent des cœurs. Et, ironie de l’histoire, nous voilà revenu au temps héroïque, avec l’éclosion de multiples projets de machines virtuelles. Il existe deux grands types de virtualisation. Elle peut être soit logicielle :

QEMU, émulateur de plate-forme x86, PPC et SPARC.
Plex86, Bochs, WMware (1999), VirtualPC (1997), émulateurs de plate-forme x86.
PearPC, émulateur de plate-forme PPC pour machine x86.
Java Virtual Machine (JVM), machine virtuelle pour le byte-code Java. Elle existe pour différentes architectures comme, x86/GNU/Linux, x86/Windows, SPARC/Solaris...
User Mode Linux, noyau Linux fonctionnant en espace utilisateur.
RT-Linux, micro noyau temps réel dur faisant fonctionner le noyau Linux en espace noyau non temps réel.
Virtuozzo, partitionnement du système au niveau noyau pour Linux et Windows 2003.
Linux VServer, BSD Jail, isolation du système de fichier et des processus.
Chroot, isolation du système de fichier en changeant la racine.
Denali, paravirtualiseur dimensionné pour faire fonctionner jusqu’à 1000 machines virtuelles, composées d’un OS minimal spécialisé pour les services Internet. Le terme de paravirtualisation est apparu pour la première fois dans des articles de recherches pour décrire l’hyperviseur de Denali.
Xen, paravirtualiseur composé d’un noyau léger fonctionnant en hyperviseur.
L4 et TRANGO sont aussi d’autres paravirtualiseurs pour l’architecture x86.
Windows 95 et suivants contiennent une Machine Virtuelle DOS (VDM), une machine virtuelle " Windows on Win32 " (WOW) pour les applications Windows 16 bits.
HP Virtual Partitions (VPAR), solution de partitionnement des systèmes HP-UX. Chaque partition fait fonctionner une copie du système HP-UX.
Solaris Containers, en 2002 avec Solaris 9, ce sont des environnements d’exécution dont l’usage des ressources est limité. Une seule instance de Solaris est utilisée, l’usage des ressources est contrôlé par le logiciel SRM.
Solaris Zones, en 2005 avec Solaris 10, le concept des zones est dérivé des " jails " des systèmes BSD. Une jail est un environnement d’exécution isolé et sécuriser. Une seule instance de Solaris est utilisée.
IBM Logical Partitioning (LPAR), solution de partitionnement pour les ordinateurs pSeries. LPAR permet le fonctionnement de partitions AIX et GNU/Linux.
IBM Dynamic Logical Partitioning (DLPAR), solution de partitionnement incluse dans AIX 5L version 5.2. DLPAR permet d’ajouter ou de retirer dynamiquement des ressources d’une partition.
La famille des iSeries d’IBM supporte le partitionnement logique. La première partition OS/400 charge l’hyperviseur appelé " the Hypervisor ", celui-ci permet le contrôle, la gestion et l’isolation entre les partitions. Celles-ci peuvent contenir le système OS/400 ou GNU/Linux.
z/VM est un OS permettant la virtualisation, il est le successeur de VM/ESA. z/VM supporte plusieurs OS invités comme GNU/Linux, OS/390, TPF, VSE/ESA, z/OS et lui-même. Les ressources de la machine hôte sont gérées par le programme de contrôle appelé " CP ".

Soit matérielle :

Mainframe IBM (zSeries), ils permettent de faire fonctionner simultanément plusieurs OS comme z/OS, z/OS.e, z/VM, VSE/ESA, TPF et GNU/Linux.
Sun E10k et E15k, partitionnement matériel statique pour Solaris en 1996, le partitionnement matériel devient dynamique en 1999 (Dynamic System Domains).
HP Superdome.
L’architecture POWER 4 d’IBM offre des fonctionnalités dédiées à la virtualisation au niveau du processeur et du firmware.

Xen est un projet du Groupe de Recherche sur les Systèmes du Laboratoire Informatique de l’Université de Cambridge. Il est un élément du projet XenoServers [XENO] fondé par l’Engineering and Physical Science Research Concil (UK EPSRC). Le projet XenoServers a pour but de fournir " une infrastructure publique pour une informatique globalement distribuée " (sic). Ce projet doit permettre à des XenoServers, répartis tout autour du globe, d’offrir un accès public pour l’exécution d’applications. Ce projet se décompose principalement dans le développement de deux parties :

Xen pour le partitionnement de la machine. Il permet à de multiples clients de faire fonctionner leurs OS et applications sur un même serveur. Xen fournit un environnement protégé, une isolation et gestion des ressources, ainsi qu’une comptabilisation de leurs usages.
Le logiciel de contrôle des plateformes XenoServers pour gérer les réseaux de XenoServers, ce qui inclut le stockage distribué, la découverte de serveur, la gestion des ressources, l’authentification, l’autorisation et la comptabilisation des usages.

Le projet Xen est né à l’Université de Cambridge en 2001 sous l’impulsion de Ian Pratt, leader et architecte en chef du projet. La première version publique de Xen (version 1.0) est publiée en octobre 2003. Elle est stable et est utilisée en environnement de production. La version 2.0 est publiée en octobre 2004. Elle apporte son lot d’améliorations, un support matériel plus large, une configuration plus souple. La version 3.0 est publiée le 5 décembre 2005. Les nouveautés notables sont : le support des architectures 32 bits SMP, des architectures 64 bits pour les OS invités et la technologie Vanderpool d’Intel. Le projet Xen bénéficie de la collaboration depuis 2003 de l’Intel Research Cambridge et depuis 2004 de l’HP Labs. En 2004, Ian Pratt, Nick Gault (fondateur de Network Physics) et Moshe Bar (leader d’OpenMosix) créent XenSource [XenSource], une société basée à Palo Alto (Californie) dédiée au développement de Xen, à sa promotion et à son support. Aujourd’hui, Xen est activement supporté par une vingtaine de grandes entreprises dont AMD, Hewlett-Packard, IBM, Intel, Network Appliance, Novell, Red Hat, Sun Microsystems ainsi que l’OSDL et une dizaine de grandes universités. La version 3.0 de Xen a vu la participation de plus de 150 développeurs open source, répartis tout autour du globe.

Les grandes lignes de Xen

Xen entre dans la même famille des solutions de virtualisation que WMware, Bochs ou Qemu. Mais à la différence de ceux-ci, Xen nécessite que l’OS invité soit porté sur l’architecture Xen, d’où le terme de paravirtualisation. Xen est un paravirtualiseur. Il présente à l’OS invité une API spécialisée, là où un virtualiseur présente une simulation d’une architecture matérielle. Dans le cas de QEMU ou WMware, qui sont des machines virtuelles complètes incluant un BIOS logiciel, l’OS invité a l’illusion de fonctionner directement sur une véritable machine. Le matériel virtuel, simulé par la couche de virtualisation, entraîne un surplus de consommation des ressources et des pertes de performances. Xen pallie ces problèmes de performance par le port de l’OS invité sur l’architecture Xen et par une conception du système originale. L’architecture de Xen présentée à l’OS invité est proche de l’architecture x86 sur laquelle Xen a été initialement développé. Cette proximité facilite le port sur Xen d’OS développés pour l’architecture x86. Xen supporte les processeurs x86 à partir des versions 686. Le port vers l’architecture x86_64 (EM64T pour Intel et AMD64 pour AMD) est apparu avec la version 3.0 de Xen. IBM travaille au portage vers le PowerPC 970, HP vers l’IA64 et Sun vers le Sparc. Le multiprocesseur (SMP) est supporté par Xen depuis la version 1.0, la version 3.0 permet à l’OS invité d’utiliser le SMP pour les architectures 32 bits. Le SMT, maintenant appelé hyperthreading, n’est pas une nouveauté. Le Simultaneous Multi Threading est une technique datant des années 1950. L’hyperthreading (SMT) est supporté par Xen et l’OS invité depuis la version 3.0. L’équipe de Xen rapporte qu’ils ont obtenu de très bons résultats sur des systèmes octo-processeurs avec la version 2.0. Ils ont aussi de bons retours d’utilisations de Xen sur des systèmes 32 voies. Le développement initial sur l’architecture x86 est en partie à l’origine du choix de la paravirtualisation. Dans une virtualisation complète, la machine virtuelle simule à l’identique la machine hôte, ce qui permet de faire fonctionner un OS invité non modifié. L’architecture x86 n’ayant pas été prévue pour gérer la virtualisation, elle rend complexe le développement d’une solution de virtualisation complète. Le choix de la paravirtualisation a aussi été motivé par la possibilité d’obtenir des performances proches d’un OS natif (cf. § Architecture d’un système Xen), performances difficiles à atteindre avec une virtualisation complète sur l’architecture x86. Xen pénalise les performances de 2 à 3% en moyenne. Intel avec l’extension d’architecture appelée " Vanderpool " ou " VT " et AMD avec " Pacifica " ont inclus dans leurs processeurs le support de la virtualisation. Ces extensions permettent la création de processeurs virtuels au niveau matériel. Intel et AMD contribuent au développement de Xen pour supporter les extensions Vanderpool et Pacific. Ils se sont accordés en 2005 sur une interface commune d’accès aux deux technologies, cette API est appelée HVM – Hardware Virtual Machine. Ces deux technologies vont permettre d’augmenter les performances de Xen et de virtualiser sur l’architecture x86 des OS sans les modifier. Toutes les licences ne permettent pas de modifier un OS librement. L’équipe de Xen a ainsi porté Windows XP sur Xen 2.0, mais la licence de Microsoft en interdit la publication. L’apport de Vanderpool et Pacifica lèvera cette barrière. Xen 2.0 supporte jusqu’à 4 Go de mémoire. Xen 3.0 supporte le mode PAE sur x86 pour passer la barrière des 4 Go de mémoire et le support d’une quantité supérieure à 1 To de mémoire pour les architectures 64 bits. Xen est dimensionné pour faire fonctionner au mieux 100 machines virtuelles hébergeant chacune un OS complet, le tout sur un serveur " standard ".

Question de ring

La famille des processeurs compatibles x86 possède un modèle de protection composé de quatre niveaux d’exécution aussi appelés " rings " et numérotés de 0 à 3, respectivement du plus privilégié au moins privilégié. Le ring 0 est couramment dédié à l’exécution de l’OS et le 3 aux applications de l’espace utilisateur. Les rings 2 et 3, originellement prévus pour la virtualisation, sont rarement utilisés. Les OS actuels sont conçus pour fonctionner sur le ring 0 et utilisent des instructions uniquement disponibles sur celui-ci. OS/2 est l’un des rares OS à utiliser les rings 2 ou 3. Ces deux rings ont été supprimés de l’architecture x86_64. Dans le cas d’un système Xen sur l’architecture x86, l’hyperviseur est exécuté dans le ring 0, les OS invités dans le ring 1 ou 2 et les applications dans le ring 3. Pour l’architecture x86_64, les OS invités et les applications sont exécutés dans le ring 3. Pour faciliter la virtualisation sur l’architecture x86, Intel avec l’extension Vanderpool ajoute deux nouveaux modes d’exécutions appelés VMX root et VMX non-root. Ces deux modes supportent les quatre niveaux d’exécutions (ring 0 à ring 3). Avec Vanderpool, les OS utilisent le ring 0 et n’ont plus besoin d’être modifiés. Les applications restent en ring 3. OS et applications fonctionnent dans le mode d’exécution VMX non-root, sans requérir de modifications. L’hyperviseur utilise le mode d’exécution VMX root, accédant ainsi à un niveau de contrôle et de privilège plus important. Seul l’hyperviseur doit être modifié pour pouvoir utiliser l’extension Vanderpool et gérer les nouveaux modes d’exécution VMX. Au mode d’exécution VMX root, Vanderpool associe des nouvelles instructions dédiées à l’hyperviseur, pour ainsi lui faciliter le partage et le contrôle des ressources de la machine hôte et, par là même, améliorer les performances. Par exemple, les changements, sauvegardes et restaurations de contexte associés à la bascule entre systèmes invités sont gérés au niveau du processeur par des instructions dédiées (VM entry, VM exit...). Les contextes sont stockés dans des structures (Virtual Machine Control Structure – VMCS) fournies par le processeur et enregistrées dans une zone réservée de la mémoire. La technologie Pacifica d’AMD [Pacifica] a plusieurs objectifs : faciliter la virtualisation, augmenter les performances et la sécurité des systèmes virtualisés. Elle sera disponible uniquement pour les processeurs AMD64. Elle utilise pour faciliter la virtualisation et améliorer les performances des TLB étiquetés (tagged TLB) et, comme Vanderpool, un nouveau mode d’exécution associé à son lot d’instructions. Du coté de la sécurité, Pacifica met en œuvre un filtrage des instructions et des événements potentiellement dangereux. Le TLB (Translation Lookaside Buffer) est un cache matériel interne à la MMU. Il stocke un certain nombre de traductions d’adresses virtuelles en adresses physiques. Dans le cas des TLB étiquetés, il s’agit d’associer aux entrées du TLB un identifiant d’espace (ASID – Address Space Identifier). Cet identifiant permet la coexistence de l’hyperviseur et des OS invités dans des espaces d’adressages séparés et n’oblige pas à vider la totalité du TLB à chaque changement de contexte, comme c’est le cas sur les processeurs x86. Les TLB étiquetés est une technologie issue des processeurs RISC comme les processeurs Alpha, MIPS ou SPARC. Comme Intel avec Vanderpool, AMD avec Pacifica ajoute deux nouveaux modes d’exécutions appelés " Host Mode " et " Guest Mode ". L’hyperviseur fonctionne dans le Host Mode et l’OS invité dans le Guest Mode. Comme dans le schéma d’Intel, le Host Mode permet à l’hyperviseur l’accès à un ensemble d’instructions pour gérer les machines virtuelles. Ces nouvelles instructions utilisent une structure dédiée appeler VMCB (Virtual Machine Control Block) fournie par le processeur. Coté sécurité, Pacifica isole, au niveau matériel, les OS invités les uns des autres, en filtrant les instructions et les événements, comme les accès DMA et en permettant de gérer les interruptions des processeurs virtuelles.

Architecture d’un système Xen

Xen est un hyperviseur. Son rôle est d’ordonnancer le fonctionnement des différentes machines virtuelles, en les perturbant le moins possible, pour approcher les performances d’un OS natif. Pour cela, Xen se doit d’être le plus léger et rapide possible. L’architecture d’un système Xen est composé de l’hyperviseur Xen et des différentes machines virtuelles sécurisées, appelées " domaine " dans la terminologie Xen. Le temps d’utilisation de la machine hôte par chaque domaine est ordonnancé par l’hyperviseur Xen. Dans ce temps imparti, charge aux OS invités d’ordonnancer leurs processus. Outre son rôle d’ordonnanceur, l’hyperviseur est chargé, au boot de l’ordinateur, de détecter et démarrer les processeurs non initialisés par le BIOS, de router les interruptions et d’énumérer les bus PCI. La gestion des pilotes est déléguée à un domaine particulier, le domaine 0. Le domaine 0 est créé lors de l’installation de Xen. Il est lancé automatiquement au boot et est nécessaire au fonctionnement d’un système Xen. Il est composé d’un noyau Linux modifié appelé " Xeno-Linux " et des logiciels de contrôle de Xen ///images Le domaine 0 est le seul à pouvoir interagir directement avec le matériel, et ce, par l’intermédiaire des pilotes du noyau Linux. Les autres domaines font appel à ces pilotes via l’utilisation des pilotes (virtuels) de Xen. Le domaine 0 permet de construire ou détruire d’autres domaines et de gérer leurs pilotes virtuels. Il assure les tâches d’administration du système comme démarrer, arrêter, restaurer ou migrer les domaines. Ces tâches sont réalisées par le daemon Xend qui fonctionne dans l’espace utilisateur du domaine 0. Le daemon Xend est responsable de la gestion des domaines et fourni un accès à leurs consoles. Il est accessible à la fois par un client en ligne de commande et par un navigateur web. Dans les deux cas, le protocole HTTP est utilisé pour l’échange des commandes et réponses. Cette architecture garantit à l’hyperviseur une protection contre les bugs et les plantages des pilotes. Elle décharge aussi l’équipe de Xen du développement des pilotes, pour se concentrer uniquement sur le rôle principal de l’hyperviseur. Elle assure de plus au système Xen un large support matériel via les pilotes du noyau Linux. Cette architecture simple et légère permet à Xen d’offrir de hautes performances.

La virtualisation des pilotes

Dans l’architecture d’un système Xen, seul l’hyperviseur et le noyau Linux du domaine 0 ont un accès direct au matériel et ont une connaissance des caractéristiques de celui-ci. Ils utilisent, pour chaque périphérique, le pilote et la configuration idoines fournis par le domaine 0. Ce dernier exporte une version virtualisée des périphériques vers les autres systèmes invités. Cette approche permet aux périphériques d’être contrôlés uniquement par le système du domaine 0 et d’être disponible pour tous les OS invités. Ce qui signifie que le système Linux du domaine 0 doit être configuré à la fois pour supporter le matériel sous-jacent, l’hyperviseur Xen et fournir des périphériques virtuels. Cette approche permet aussi de limiter le crash d’un pilote au pilote lui-même, sans affecter l’application qui fonctionne dans un autre domaine. Cela permet aussi de pouvoir redémarrer le domaine 0 pour retrouver un pilote opérationnel, ceci en perturbant le moins possible les applications des autres domaines. La communication entre les périphériques d’un domaine n et les périphériques virtuels du domaine 0 passe par une liaison appelée " device channel ". Ce canal est un lien point à point entre les deux domaines. Il permet l’envoi de message asynchrone d’un domaine vers un autre. Les messages sont communiqués via une page de mémoire partagée allouée par l’OS invité et mappée dans l’espace d’adressage du domaine 0. Ces opérations sont autorisées et contrôlées par Xen.

Le daemon Xend

Le daemon Xend est l’interlocuteur principal de l’administrateur pour toutes les activités d’un système Xen. Il lui permet de créer des nouveaux domaines, les détruire, les migrer d’un serveur à un autre, les arrêter, les démarrer, les sauvegarder, les restaurer, les surveiller... Il est en grande partie écrit en Python (version 2.3) et son interface HTTP est accessible par défaut sur le port 8000. Toutes les interactions entre Xend et Xen transitent par le serveur XCS (Xen Control Switch).

Migration des machines virtuelles

Xen permet de migrer une machine virtuelle d’un serveur Xen vers un autre sans quasiment arrêter la machine virtuelle. Durant cette procédure, la machine virtuelle en fonctionnement est copiée sur le serveur Xen final. Un arrêt de 60 à 300 ms est nécessaire pour synchroniser les machines virtuelles avant le démarrage de la machine virtuelle finale. Lors du Symposium Linux d’Ottawa (OLS) de 2005, Ian Pratt a présenté les traces de la migration d’un serveur Quake. Celles-ci ont montré une interruption du serveur d’à peu près 50 ms. Les joueurs n’ont rien vu.

Xen 3.0

La version 3.0 de Xen est sortie le 5 décembre 2005. Cette version amène de nombreuses nouveautés et améliorations tant du point de vue de la stabilité que des performances, de la sécurité et du contrôle de l’usage des ressources. Elle vise le marché des data centers et des serveurs d’entreprises avec le support du SMP, l’adressage de plus de 4 Go de mémoire et la possibilité de virtualiser tout OS sans les modifier (cf. Vanderpool). Il est à noter que cette version est sortie sous le nom de " community release ". L’annonce de presse [Xen3] associée indique que celle-ci est la première version publique et qu’elle demande à être testée par la communauté (partenaires, vendeurs et les distributions) pour régler les performances et la qualité. Ce nom indique surtout que c’est maintenant au tour de la communauté de développer et stabiliser ses offres basées sur Xen 3.0. L’architecture a continué d’évoluer dans le sens d’une simplification de l’hyperviseur, pour en faciliter l’audit, la maintenance et la robustesse. Une grande partie du code d’initialisation de la plate-forme est maintenant gérée par le noyau Linux du domaine 0, comme l’initialisation des bus PCI, des IOAPIC ou de l’ACPI. Ces éléments profitent du large support du noyau Linux et de son développement permanent. Le futur de Xen est clairement défini sur le site officiel. Parmi les objectifs, on trouve par exemple le portage vers d’autres architectures comme l’ARM. Avec cette version, l’un des OS invités a accès au périphérique vidéo, ce qui doit permettre aux développeurs de Xen de l’utiliser directement sur leurs machines et ainsi de corriger les bugs plus rapidement. La version 3.0 est aussi l’étape de la maturité avec le support des architectures x86, x86_64, IA64. Le port vers l’architecture PowerPC est quasi complet. Le port de Xen vers l’architecture x86_64 supporte les OS invités compilés pour la cible x86_64 et les applications 32 et 64 bits. Cette version inclut aussi le support de la technologie Intel Vanderpool. L’intégration de la technologie AMD Pacifica est prévue au cours l’année 2006. A ce titre, XenSource a annoncé à l’Intel Developer Forum d’août 2005 [IDF-2005], avoir réussi à faire fonctionner le système paravirtualisé GNU/Linux et le système totalement virtualisé Windows XP SP2 sur des plateformes composées de pré-version de Xen 3.0 et de processeurs Intel avec l’extension Vanderpool. Xen 3.0 apporte le support du SMP pour l’OS invité et le support de l’hyperthreading pour l’hyperviseur et l’OS invité. Le SMP est supporté jusqu’aux architectures 32 voies. Le daemon Xend a été modifié pour régulièrement rééquilibrer la charge, en déplaçant périodiquement les machines virtuelles sur les CPU supportés (hyperthreading compris). Deux nouveaux modes d’adressage de la mémoire sont inclus dans Xen 3.0 : le support du mode PAE sur x86 pour passer la barrière des 4 Go et le support de l’adressage mémoire sur 64 bits pour les architectures qui le supportent. Xen 3.0 supporte aussi les modules " Trusted Platform ". Ce support est issu de l’initiative " Secure Hypervisor " d’IBM. Le daemon Xend a été amélioré et offre la possibilité d’ajouter ou d’enlever à la volée un processeur virtuel à une machine virtuelle et améliore la migration des machines virtuelles entre serveurs. Ce qui a pour effet de fluidifier et de faciliter la répartition de charge des machines virtuelles composant un cluster. L’une des améliorations notables de cette troisième mouture de Xen est la qualité des outils de contrôle, qui ont été totalement revus et corrigés. Ils permettent de contrôler et de visualiser l’usage des ressources d’un serveur seul ou d’un cluster, à partir d’un point unique. Ils s’utilisent soit en ligne de commande, soit à partir d’un navigateur web. L’équipe de Xen utilisait BitKeeper pour le développement de la version 3.0 et a subi les effets collatéraux de l’opposition entre les développeurs du noyau Linux et l’entreprise BitMover. Cette dernière a annoncé début 2005 l’arrêt de la disponibilité gracieuse de l’outil BitKeeper pour les développements open source. Cet arrêt a perturbé et retardé le développement de la version 3.0 de Xen, obligeant l’équipe à rechercher un outil de remplacement pour le développement collaboratif. Le code source de Xen est maintenant géré par le système de gestion de code source Mercurial [Mercurial]. Le changement de gestionnaire de codes sources a eu lieu le 10 novembre 2005.

Xen 3.1

Tout en stabilisant la version 3.0, les développeurs de Xen se sont penchés sur la version 3.1. Celle-ci devrait supporter pleinement les extensions d’architecture Vanderpool et Pacifica, pour permettre une virtualisation complète et sans perte de performance sur les architectures x86 et AMD64 et ainsi permettre à Xen la virtualisation de tout OS sans devoir les modifier. Sont aussi au programme de la version 3.1, des améliorations des outils de contrôle et de configuration, le support du SMP sur les architectures 32 et 64 bits à la fois pour l’hôte et les OS invités, le support des systèmes NUMA, des périphériques InfiniBand, le support du hotplug CPU et du hotplug RAM. Ces dernières évolutions, liées au support matériel, passent aussi par l’évolution du noyau Linux. Des discussions sont en cours sur la liste de développement du noyau Linux et la liste de développement de Xen, concernant l’inclusion, dans la version stable du noyau Linux, d’une couche (API) dédiée à la virtualisation. Cette API dédiée permettra d’utiliser Xen sans devoir patcher le noyau. Elle sera aussi utile aux autres solutions de virtualisation comme UML...

Mise en œuvre

Selon vos goûts, il existe plusieurs façons d’installer et de tester Xen avec vos OS favoris :

Un CD live de démonstration d’un système Xen est disponible [Demo CD]. Il permet de tester Xen sur une machine sans l’installer sur le disque dur. Ce CD est basé sur la distribution Debian.
La distribution Xenophilia est une distribution GNU/Linux basée sur Xen [Xenophilia].
Des paquets Debian existent pour installer un système Xen complet [Deb].
Ubuntu Linux travaille à l’intégration de Xen dans sa distribution.
Red Hat [Fedora] intègre Xen 3.0 dans sa distribution Fedora Core 5 et travaille à son intégration dans la RHEL5.
Novell intégrera Xen dans la SLES 10. La SUSE Professionnal 9.3 intègre Xen. Novell a aussi présenté en 2005 un port de NetWare sur l’architecture Xen [Brainshare].
NetBSD version 3.0 inclut le support de Xen 2.0.
Sun travaille au port de Solaris et de OpenSolaris sur l’architecture Xen [Solaris] [OpenSolaris] et, depuis août 2005, Solaris boot sur Xen.

Conclusion

J’espère que ce tour d’horizon de Xen vous donnera l’envie de l’essayer et pourquoi pas de l’adopter. L’actualité autour de Xen est de plus en plus importante depuis la sortie de Xen 3.0, de multiples distributions sortent en incluant son support. Alors, soyez Xen !!! Pour aller plus loin sur la toile :

Il existe trois mailing-lists officielles pour suivre l’évolution du projet Xen :
xen-devel@lists.sourceforge.net
xen-announce@lists.sourceforge.net
xen-changelog@lists.sourceforge.net
Les utilisateurs de Xen peuvent poster sur la liste xen-devel.
Le portail francophone sur la virtualisation : http://xenfr.org
Conception de Xen et benchmarks : http://www.cl.cam.ac.uk/netos/paper/2003-xensosp.pdf
Performances comparées de GNU/Linux et NetBSD sur Xen : http://users.piuha.net/martti/comp/xendom0/xendom0.html