Retrouvez cet article dans : Linux Magazine 87

Bien qu’existants depuis très longtemps, les produits de virtualisation sont de plus en plus nombreux. IBM commercialisa, il y a plus de trente ans déjà, son très populaire VM/370 et, de nos jours, VMware est la référence en matière de virtualisation de l’architecture x86. Toutefois, le domaine du Logiciel libre ainsi que le monde de la recherche ne sont pas en reste et démontrent une étonnante créativité notamment avec Xen [1]. D’autres projets du monde libre comme QEMU [2] (Linux Magazine 74), Bochs [3], User Mode Linux (UML) [4], Plex86 [5] ou encore Denali [14] témoignent de cette vitalité dans ce domaine. Xen, qui provient de l’université anglaise de Cambridge est en train d’émerger singulièrement puisque les plus grands éditeurs du monde libre le proposent (Novell-SLES10) ou le proposeront (RHEL 5, Fedora Core 6) en standard. Par ailleurs, des acteurs de pointe du secteur informatique comme Voltaire [8] dans le domaine du calcul scientifique annoncent aussi son utilisation dans des solutions de grid computing. En outre, Xen, bien qu’initialement un sous-projet de XenoServers [6], acquiert une notoriété importante. Il a même engendré la création de la société californienne XenSource [7] qui passe des accords technologiques avec Microsoft à propos de la future offre de virtualisation du serveur Longhorn. Avant de décrire succinctement l’architecture et l’installation de Xen, nous proposons une classification des différentes solutions existantes et donnons quelques définitions relatives à la virtualisation Brièvement, Xen permet de disposer de plusieurs instances de Linux (ou Net/Free BSD) sur un unique serveur, ordinateur personnel, ou même portable. Ainsi, il est possible d’effectuer des tests sans crainte de détruire une de ces instances. Autrement dit, Xen permet une mise en œuvre simple de machines éphémères encore appelées bac-à-sable ou sandboxes. Il existe de nombreux autres avantages à la virtualisation des systèmes informatiques comme le retour sur investissement (ROI) pour les entreprises qui pourront consolider plusieurs serveurs dans une même machine physique. Le projet Xen permet de bénéficier de tous ces avantages, tant sa richesse de fonctionnalités est complète. Outre la migration " live " de ses machines virtuelles d’un serveur vers un autre, Xen est capable d’ajuster dynamiquement la mémoire allouée aux différentes machines virtuelles, d’interrompre momentanément leur exécution ou encore de fonctionner sur des gros serveurs SMP de 32 processeurs.

Classification des techniques de virtualisation

Plusieurs approches sont possibles pour classifier les différentes techniques de virtualisation [10]. Nous décrirons ici une classification très simplifiée, mais représentative des produits existants sur le marché. Un premier type de virtualisation est constitué par les produits créant des compartiments au sein d’une même instance d’un système d’exploitation. Les applications fonctionnant à l’intérieur d’un même compartiment étant complètement isolées de celles des autres compartiments. Virtuozzo de Swsoft [11] permet par exemple de créer plusieurs environnements virtuels (VE) ayant chacun une adresse IP propre et pouvant être redémarrés les uns indépendamment des autres. SUN Microsystems commercialise Zones [13], fonctionnant sur une base Solaris et pouvant être placé dans cette première catégorie. Toujours dans cette même catégorie de virtualisation par compartiments, appelés aussi " containers ", il existe des projets du monde libre comme le Linux-Vserver [12]. Un deuxième type de produits est constitué par les machines virtuelles hébergées qui donnent la possibilité de démarrer des instances de systèmes d’exploitation sur une machine hôte, au côté d’autres applications. Les exemples les plus connus sont la VMware Workstation le VMware Server (précédemment connu sous le nom de GSX). Microsoft est présent dans cette catégorie avec Virtual PC 2004. Dans le monde libre, les projets les plus représentatifs sont le User Mode Linux (UML) [4] et QEMU [2], largement décrit dans Linux magazine 74. En troisième lieu, nous pouvons considérer les produits du type de VMware ESX, Microsoft Virtual Server, HP Integrity VM, Xen ou encore les micropartitions d’IBM. Ils disposent tous d’une couche logicielle plus ou moins intégrée au silicone et complètement dédiée à la gestion de machines virtuelles. Cette couche est dénommée " Moniteur de Machines Virtuelles " (VMM) ou encore " Hyperviseur " ou " Platform Monitor " (PMAN) et même " hôte " (host). Les machines virtuelles s’appuyant sur ces VMM sont appelées " guests " ou systèmes invités. La figure 1 décrit l’agencement logique des différents composants constituant un ensemble complet [matériel, VMM, systèmes invités]. Les caractéristiques ainsi que le " taux de virtualisation " des VMM varient selon les produits ou projets de virtualisation. Par exemple, QEMU dans son mode d’émulation complète est capable de présenter une architecture matérielle de type PowerPC au système invité (guest) tout en s’appuyant sur un ou des processeurs physiques de type x86. En revanche, HP Integrity VM est capable d’héberger uniquement les versions Itanium® de Linux, Windows, HP-UX et (bientôt) OpenVMS.

Figure 1 : Moniteur de machine virtuelle

Xen : Moniteur de machines para-virtuelles

Xen et un moniteur de machines virtuelles faisant partie de notre troisième catégorie. Toutefois, il existe une différence fondamentale entre Xen et les autres produits ; le noyau de ses systèmes invités doit avoir été modifié au préalable avant de pouvoir démarrer " au dessus de Xen ". Le barbarisme " Xenification " des systèmes invités est quelquefois employé pour qualifier ces modifications et la documentation ajoute même le préfixe " Xen " devant le nom du système d’exploitation modifié (ex. : XenLinux, XenBSD, XenWindows). C’est à cause de ces modifications que l’on dit que Xen est un des produits de paravirtualisation, par opposition aux autres qui permettent le démarrage de systèmes d’exploitation " intacts ". Il est toutefois important de noter que les applications de type utilisateur des systèmes invités de Xen ne nécessitent pas de modifications (cf. Figure 2, " Unmodified User Software "). Les modifications apportées sur les systèmes invités ont pour but d’améliorer les performances globales de la machine virtuelle. Ces améliorations sont possibles et substantielles, car le travail de virtualisation du VMM est moindre puisque déjà préparé dans le système invité. En contrepartie, seuls les systèmes xenifiés sont éligibles comme systèmes invités au-dessus de Xen (sur des machines ne disposant pas de processeurs intégrant des technologies de virtualisation. Cf. paragraphe " virtualisation et silicone "). Une autre particularité de Xen vient de sa terminologie. Celle-ci différencie une machine virtuelle, du contexte dans laquelle elle évolue. Ce contexte est appelé " domaine ". Selon le manuel de l’utilisateur, " la relation entre les machines virtuelles et les domaines, est similaire à celle entre les programmes et les processus : une machine virtuelle est une entité persistante qui réside sur disque (un peu comme un programme). Quand elle est chargée pour exécution, elle fonctionne dans un domaine. Chaque domaine possède un identificateur unique, analogue à un identificateur de processus. " Aujourd’hui, les noyaux Linux (2.4 et 2.6) et NetBSD/FreeBSD peuvent constituer des domaines Xen. Par ailleurs, les chercheurs des laboratoires de Microsoft disposent d’une version xenifiée de Windows mais non commercialisée.

Le Domaine privilégié

Sur la figure 2, la couche matérielle est directement surmontée du moniteur Xen. Sur la gauche, et au-dessus de ce moniteur, se trouve le domaine0 encore appelé " domaine privilégié " (privileged domain). Le domaine0 est particulier, car il peut utiliser des appels système spécifiques (hypercalls) que lui seul est capable de mettre en œuvre. Ainsi, le contrôle des autres domaines (création, modification, effacement de domaines…) se fait à partir de ce domaine privilégié. C’est le processus xend qui est responsable de l’administration des machines virtuelles et de l’accès à leurs consoles. La communication avec xend est réalisée via une interface HTTP [16, 17] ou via la ligne de commande, principalement grâce à xm. Les distributions RedHat permettent le démarrage de xend via chkconfig. Par ailleurs, depuis la version 2.0 de Xen, seul le domaine0 dispose de pilotes natifs, en communication avec le matériel. Les requêtes encapsulées des autres domaines sont transmises au domaine0 via Xen et un système de passage de messages. Le domaine0 réalise les entrées-sorties via le pilote natif et un accès sécurisé au matériel. Cette architecture qui a de nombreux avantages se révèle très performante. Du fait de ses spécificités, le domaine0 utilise un noyau différent des autres domaines. La documentation explique comment créer ce noyau particulier et propose de lui ajouter le suffixe –xen0, par opposition au suffixe du noyau des autres domaines qui est -xenU.

Virtualisation et silicium

L’engouement pour la virtualisation ainsi que le potentiel d’amélioration des performances des machines virtuelles en reléguant certains travaux aux processeurs, font qu’Intel et AMD intègrent dans leur dernière puce des techniques de virtualisation. La proximité des centres de recherche d’Intel, de Microsoft et du campus de l’université de Cambridge en Angleterre favorise aussi la communication entre les chercheurs de ces différents centres… Intel propose la technologie de virtualisation VT-i, présente dans ses processeurs x86 et Itanium®. AMD met à disposition AMD-v connu sous le nom de code Pacifica. Ces technologies sont potentiellement bénéfiques à tous les hyperviseurs d’instructions IA-32 ou IA-64 et elles permettent à Xen d’accepter des systèmes invités non xenifiés (Figure 2, bloc de droite) comme par exemple Windows. D’ailleurs, XenSource explique comment effectuer cette opération sur son site Internet [18] avec Xen 3.0.2. Notons qu’IBM, qui conçoit à la fois ses puces et son hyperviseur de micropartitions, intègre complètement son système de virtualisation de silicone de ses systèmes basés sur le processeur POWER5TM.

Figure 2 : Architecture de Xen 3.0

Mise en œuvre de Xen et du domaine0

Le moyen le plus simple pour jouer avec Xen est de télécharger le live-CD de démonstration depuis le site de XenSource [7]. Ce CD permet de démarrer Xen 3.0, ainsi que le domaine privilégié dont le noyau est basé, soit sur une Debian Etch ou alors CentOS 4.1. Ensuite, l’utilisateur, après s’être connecté sur ce domaine0, pourra créer plusieurs autres domaines en suivant les instructions apparaissant sur les différents écrans (xterm et firefox). Ce live-CD met en œuvre une technique de copy-on-write afin de pouvoir simuler des accès en écriture sur ce support, qui est, par essence accessible en lecture seulement. Cette technique permet aussi de réutiliser l’ensemble du système d’exploitation du domaine0 pour les autres domaines. Une autre possibilité de mise en œuvre de Xen, à partir de Fedora Core 4, RHEL 4.1 ou Novell-Suse SLES 9.2 connectés à l’internet, est de télécharger les scripts d’installation automatique depuis le site de XenSource. Ces scripts rapatrient automatiquement et installent les paquets Xen contenant les noyaux XenLinux correspondants et ajoutent une entrée dans le système de démarrage (grub). Un redémarrage du système complet permettra de choisir cette nouvelle entrée qui, après avoir chargé Xen en mémoire, enchainera immédiatement sur le démarrage du domaine0. Ensuite, il sera possible de créer d’autres domaines et de les tester. La documentation disponible chez XenSource décrit aussi les méthodes d’installations à partir d’un tarball binaire, de paquets RPM ou des sources. Elle explique comment créer des noyaux XenLinux pour le domaine0 et pour les autres domaines. Bien que présent sur les médias de la distribution RHEL-AS5, Xen n’est pas intégré dans les dialogues d’installation. Il est nécessaire d’invoquer les paquets suivants pour bénéficier d’un XenLinux 2.6.16.1 fonctionnel :

kernel-xen-2.6.16-1.2290_EL.i686.rpm
xen-3.0.2-9.i386.rpm
libvirt-0.1.0-1.i386.rpm
libvirt-python-0.1.0-1.i386.rpm
bridge-utils-1.0.6-2.i386.rpm

Création d’un domaine>0

Dès que le domaine0 est démarré, il est possible de créer un ou plusieurs autres domaines en éditant, pour chacun, un fichier de configuration. Des exemples se trouvent dans le répertoire /etc/xen du domaine0. Grâce à quelques informations seulement, il est possible de démarrer sa première machine virtuelle. Il suffit d’indiquer, au minimum, le chemin complet vers le noyau à utiliser, les paramètres éventuels à passer au noyau, la quantité de mémoire initiale disponible, le ou les unités de stockage que le domaine0 doit présenter au nouveau domaine. Ces dernières contiendront le reste du système d’exploitation (/usr, /bin…) ainsi que les espaces pour les données. D’autres paramètres intuitifs comme le nom de ce nouveau domaine, le nombre d’interfaces réseau et leur mode de fonctionnement peuvent être aussi renseignés. L’exemple de fichier de configuration suivant s’inspire de celui de la documentation Xen 2.0. Il a été simplifié et est destiné à mettre en œuvre la micro-distribution ttylinux [15] :

Domaine0# cat /etc/xen/ttylin1.conf
kernel = "/boot/vmlinuz-2.6.12.6-xen3_7.1_rhel4.1"
root = "/dev/sda1 ro"
disk = [ ‘file:/xenvm/ttylinux-xen,sda1,w’ ]
memory = 64
name = "ttylin1"

La variable kernel contient le chemin complet dans le domaine0 du noyau XenLinux à utiliser pour démarrer. En l’occurrence, nous allons utiliser un noyau Linux 2.6.12.6 provenant d’une distribution RHEL4.1, et " patché " par Xen 3. Ce noyau fut installé par les scripts d’installation automatiques de XenSource. Les paramètres de la variable root seront passés au noyau lors du démarrage du domaine. Le fichier spécial /dev/sda1 contenu dans cette variable, correspond au paramètre sda1 de la variable disk. Cette dernière indique que le fichier /xenvm/ttylinux-xen sera présenté par le domaine0 sous le nom /dev/sda1, en mode lecture-écriture au nouveau domaine. On aurait pu présenter ce fichier sous un autre nom, comme /dev/hda, en respectant toutefois une cohérence avec le contenu de la variable root ainsi qu’avec le fichier /etc/fstab du nouveau domaine. Dans notre cas, il faudrait respecter la cohérence avec le fichier /etc/fstab étant à l’intérieur de /xenvm/ttylinux-xen. Par défaut, la distribution ttylinux [15] disponible sur le site de XenSource référence /dev/sda1 dans son fichier /etc/fstab. De ce fait, si nous souhaitons utiliser un autre fichier spécial, il nous faut modifier /dev/fstab se trouvant à l’intérieur de /xenvm/ttylinux-xen grâce, par exemple, à un montage en " loopback " (-o loop). La taille mémoire de notre nouveau domaine sera initialement de 64MO. Elle sera modifiable dynamiquement par la suite. Son nom, apparaissant dans le domaine0 sera ttylin1. Vérifions que le fichier contenant le système d’exploitation existe réellement :

 Domaine0# ls -l /xenvm/ttylinux-xen
-rwx------  1 root root 16384000 Dec 30  2005 /xenvm/ttylinux-xen

Il est alors possible de lancer la commande de création du domaine :

 Domaine0# xm create –c /etc/xen/ttylin1.conf

L’exécutable xm constitue la principale commande de gestion de Xen. La directive create effectue la création du domaine préalablement décrit dans le fichier /etc/xen/ttylin1.conf. L’option –c enchaîne la création sur la connexion à la console (/dev/console) du nouveau domaine. Cela permet de visualiser le démarrage de la machine virtuelle, et de se retrouver sous le prompt bien connu de login. Grâce à la séquence ctrl-], il est possible de quitter cette console et donc de revenir sous l’invite du domaine0. La commande xm list (figure 3) renvoie la liste des domaines présents à un instant donné, ainsi que le numéro d’identification associé à chaque domaine. Dans notre cas, le domaine ttylin1 a reçu le numéro 34. On utilisera cet identifiant pour envoyer des commandes aux différents domaines. Par exemple, si l’on désire retourner à la console du domaine ttylin1, on enverra la commande xm console 34, à partir du domaine0.

Figure 3 : Liste des domaines

Si l’on souhaite visualiser l’évolution en temps réel des différents domaines, la commande xentop nous renseignera périodiquement (figure 4) sur leur état. Sur les distributions de type RedHat, les machines virtuelles peuvent être démarrées automatiquement grâce à la commande service xendomains start (cf. chkconfig) de la même manière que n’importe quel autre service.

Figure 4 : xentop renseigne périodiquement sur l’état des domaines

Blocs de stockages virtuels (VBD)

Bien que l’exemple précédent soit très simple à mettre en œuvre et nécessite peu d’espace disque (la distribution ttylinux tenant dans un fichier de 16MO !), il n’est pas représentatif d’un environnement de production.En effet, placer le système d’exploitation d’une machine virtuelle ou les données d’une de ses applications dans un fichier du domaine0 comporte plusieurs inconvénients liés aux performances et à la sécurité ; les performances sont moindres, car le nombre de couches logicielles à traverser avant l’accès au média est plus important que si l’on présente un disque ou une partition brute. Les ordres d’entrée/sorties de la VM devront traverser son propre système de fichier, puis, éventuellement la couche d’un gestionnaire de volumes (ex. : LVM) et, ensuite, le système de fichier du système hôte et peut-être encore le gestionnaire de volume de ce même système hôte. Si l’on présente un disque ou une partition brute à la VM, seules les couches de son système de fichier et de son gestionnaire de volumes devront être traversées. Les performances sont donc forcément meilleures. Le risque de perdre des données en cas d’utilisation d’un fichier du domaine0 comme VBD (Virtual Block Device) est important, par rapport aux autres possibilités. Ce risque est lié au fait qu’en cas de demande d’écriture de la VM, il est vraisemblable qu’au final, le domaine0 cache en mémoire cette demande d’écriture tout en l’acquittant formellement. Si par malheur, à cet instant précis, le domaine0 a un problème majeur, les données cachées sont perdues. Le système invité aura certainement beaucoup de mal à les retrouver, car il aura vraisemblablement purgé ses journaux, puisqu’il pense que les données ont effectivement atteint le média physique du fait de l’acquittement. Heureusement, Xen dispose de plusieurs autres moyens de présenter des espaces de stockage aux machines virtuelles ; un disque physique ou une partition d’un disque physique visible par le domaine0 peuvent être présentés à un ou plusieurs domaines. Dans ce cas, le contenu de la variable disk du fichier de configuration contiendra le préfixe phy:. Par exemple, si l’on souhaite présenter le disque /dev/hda3 du domaine0 en mode lecture-écriture et qui sera vu comme /dev/sda1 dans le domaine, on trouvera dans le fichier de configuration la ligne : disk = [‘phy :hda3,sda1,w’]. Présenter des espaces de stockage bruts améliorera la performance des entrées-sorties, mais au détriment de la flexibilité et même de la sécurité des données. Si l’on privilégie ces spécificités, il est aussi possible de présenter aux systèmes invités des volumes de type LVM. D’autres types de stockage sont expliqués ou mentionnés dans la documentation comme NFS, iSCSI, ainsi que des méthodes permettant de partager les exécutables et les librairies Linux entre plusieurs domaines.

Réseau

Par souci de simplicité, l’exemple de création de domaine précédent ne met pas en œuvre le réseau. Cette fonctionnalité est bien sûr activable dans Xen. Son architecture ne requiert aucun effort de compréhension, car elle repose sur la notion de " pont réseau " (bridge) qui fut développée pour le noyau Linux 2.2 et incorporée aux noyaux 2.4 et 2.6. Le paquet bridge-utils est donc nécessaire pour la mise en œuvre du réseau dans Xen. Chaque domaine peut disposer d’une ou plusieurs interfaces réseau. En version 3.0.0, ce nombre est fonction du contenu de la variable nics (voir plus bas) déclarée dans le fichier de configuration (en 3.0.2, seule la variable vif est prise en compte). Chacune de ces interfaces est reliée par un " câble croisé virtuel " à l’interface virtuelle (vif) d’un pont du domaine0 (xenbr0 par défaut), ce pont étant rattaché à son autre extrémité à une interface réseau physique, comme par exemple eth0. Le démon xend est responsable de la création et de la suppression automatique, pour tous les domaines, de ce/ces pont(s) et autres interfaces virtuelles. En fait, xend appelle à bon escient les scripts network-bridge et vif-bridge pour réaliser ces tâches. Puisque Xen utilise des composants réseau standards de Linux, il est possible d’éditer ces scripts afin de les personnaliser et d’affecter éventuellement des règles de pare-feu (firewall) aux interfaces virtuelles. Les directives de configuration (Xen 3.0.0) suivantes indiquent que le domaine aura une seule interface réseau virtuelle connectée au pont xenbr0. Son adresse physique est fournie ainsi que son mode de configuration (DHCP) :

nics=1
vif = [ ‘mac=00:16:3e:73:ae:8a, bridge=xenbr0’ ]
dhcp=”dhcp”

Xen étant encore jeune, la syntaxe du fichier de configuration évolue. Dans la version 3.0.2, la variable nics est remplacée, ou plutôt englobée par la variable vif. En conséquence, en version 3.0.2, seules les deux dernières lignes de l’exemple précédent sont valides. Les exemples de fichiers de configuration fournis dans les paquets Xen ainsi que la documentation associée expliquent en détail les différentes manières de constituer le réseau. En outre, on y trouvera aussi comment paramétrer l’affectation d’adresses IP statiques à un groupe de machines virtuelles. Il est en effet possible d’éditer un fichier de configuration unique pour un groupe de systèmes invités.

Caractéristiques dynamiques de Xen

" L’Ultime " pour un système de virtualisation est de pouvoir accepter de multiples modifications dynamiquement, sans redémarrage. Dans cette catégorie, Xen n’a pas à rougir devant les autres produits, puisqu’il est possible d’ajouter ou de supprimer à la volée des CPU virtuels, d’augmenter ou de rétrécir la taille de la mémoire (balloon driver) des domaines. Les deux commandes suivantes modifient, respectivement la mémoire et le nombre de CPU virtuels du domaine 6 :

Domain0# xm mem-set 6 768
Domain0 xm vcpu-set 6 2

Il est aussi possible de déplacer un système hôte vers un autre (live motion chez VMware) grâce à xm migrate, ou encore d’interrompre momentanément l’exécution d’un domaine sans perte de contexte (xm pause et xm unpause). La fonction " undo " encore appelée " snapshot ", permettant de replacer rapidement une VM dans un état antérieur connu, peut être mise en œuvre de plusieurs manières. La première, qui est d’ailleurs utilisée dans le CD de démonstration de XenSource, est d’utiliser le système de fichier unionfs, et d’activer la fonctionnalité de Copy-On-Write. Une autre possibilité, citée dans le manuel de Xen V3, et présente depuis le noyau 2.6.8 est liée au snapshots persistants du gestionnaire de volumes de Linux (LVM) appelés aussi " Copy-on-Write clones ".

Conclusion

Avec le projet Xen, le monde du Logiciel libre démontre sa créativité, sa crédibilité et son pouvoir fédérateur ; durant la seule année 2006, on apprend que les majors RedHat et Novell/Suse l’intègrent dans leurs distributions d’entreprise, que les fabricants de puces électroniques mettent sur le marché des produits avec des techniques facilitant la virtualisation des instructions x86 et IA64. Cela permet donc à Xen d’héberger des domaines non xenifiés. Il est aussi important de noter que les grands constructeurs de matériel, tels HP et IBM, annoncent le support de Xen sur leurs machines x86, Itanium® et PowerPC. Mais surtout, Microsoft passe des accords technologiques avec XenSource, afin de combler le vide existant entre Windows et le monde du Libre. Autrement dit, on peut dire, sans risque de se tromper, que ce projet a un bel avenir. Références :

• [1] http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
• [2] http://www.qemu.org/
• [3] http://bochs.sourceforge.net/
• [4] http://user-mode-linux.sourceforge.net/
• [5] http://plex86.sourceforge.net/
• [6] http://www.xenoservers.net/
• [7] http://www.xensource.com/
• [8] http://www.voltaire.com/
• [9] http://www.ecsl.cs.sunysb.edu/tr/TR179.pdf
• [10] http://www.cs.nps.navy.mil/people/faculty/irvine/publications/2000/VMM-usenix00-0611.pdf
• [11] http://www.swsoft.com/en/products/virtuozzo/
• [12] http://linux-vserver.org/
• [13] http://www.sun.com/bigadmin/content/zones/
• [14] http://denali.cs.washington.edu/
• [15] http://prdownloads.sourceforge.net/xen/ttylinux-xen.bz2
• [16] http://sourceforge.net/projects/xenman
• [17] http://enomalism.com/
• [18] http://www.xensource.com/files/
• [19] http://linux-net.osdl.org/index.php/Bridge

Retrouvez cet article dans : Linux Magazine 87