Synopsis

Où en sont les principaux *BSD du marché en ce qui concerne Xen, la hype du moment ? Nous allons procéder à une petite inspection surprise de l’état des lieux de Xen sur NetBSD, FreeBSD et OpenBSD. Où en est l’intégration de Xen en tant que "Dom0/DomU" dans les différents noyaux BSD, et comment peut-on profiter de ces extraordinaires systèmes d’exploitation lorsque l’on n’a qu’un système GNU/Linux sous la main ? Maintenant, plus de problèmes, vous saurez toujours comment sortir avec vos *BSD pour rentrer en boîte.ATTENTION Attention, cet article est très volatile, mais non inflammable. Les informations contenues ici font état d’un avancement et donc sont sujettes à évolution.

Xen : vite fait, sur le pouce

"Allez, un dernier rappel sur Xen et j’y vais Georges", mais c’est vraiment le dernier ce coup-ci, parce que la dernière fois, on sait comment ça a fini. Il est effectivement de bon ton de commencer ce genre d’article par un rapide rappel afin de mettre le lecteur dans les meilleures conditions pour la suite du sujet. Xen est donc un logiciel de paravirtualisation, ce qui signifie que l’on peut lancer une machine virtuelle sur n’importe quel type de processeur. Toutefois, les noyaux de la machine hôte et des machines virtuelles doivent être modifiés pour fonctionner avec Xen, si le processeur ne supporte pas de technologie de virtualisation. Le principe de base est d’installer un noyau Xen pour la machine hôte. Au démarrage de cette machine, une première machine virtuelle est créée (Dom0). C’est ce domaine qui va ensuite contrôler les machines invitées (DomU). Si vous ne comprenez pas de quoi je parle, il suffit de commander les GNU/Linux Magazine 85, 87 et 89 qui donnent un bon aperçu de ce qu’on peut faire avec l’engin. Dans la suite de cet article, je parlerai indifféremment de Domain0, Dom0 ou "host" pour le système hôte et de DomainU, DomU ou "guest" pour le système virtuel.

Alors là, on a une boite et là une autre

On sait maintenant tous que Xen c’est la vibe, c’est le hype, c’est le sujet de toutes les soirées bobo parisiennes du moment. Eh bien, pour vraiment vous la claquer en soirée, il n’y a qu’une solution, parler de l’intégration de Xen dans les 3 principaux *BSD de la place. Alors, on va faire simple, plan en 3 points thèse/antithèse/synt^W NetBSD, FreeBSD et OpenBSD.

NetBSD

NetBSD [1] a été le premier système BSD à intégrer Xen dans son noyau, le premier commit dans le noyau [4] daté de mars 2004 [5], et la première sortie officielle de décembre 2004 dans la version 2.0 de NetBSD [6]. Actuellement, le support de Xen2 est complet (Dom0/DomU) dans la version stable de NetBSD (3.1). Cette version a aussi vu arriver le support de Xen3 en DomU. L’intégration de Xen3 en Dom0 se fait dans la version CURRENT et est prévue pour la version 4.0 qui devrait être sortie au moment où vous lisez ces lignes. L’intégration de Xen2 dans NetBSD-3 est très bonne et l’installation d’un Dom0 ou DomU est d’une simplicité enfantine [7].

FreeBSD

Pour le moment Xen n’est pas officiellement intégré dans FreeBSD [2], il y a un travail mené dans la branche –CURRENT, mais cela constitue un "work in progress". Xen devait être intégré dans la version 6.1 sortie en mai 2006, mais c’est maintenant repoussé à une date et une release inconnues [8]. Les développeurs se trouvent confrontés à des problèmes assez profonds dans le fonctionnement du noyau FreeBSD, ces problèmes et le travail en cours sur le "newbus" empêchent toute avancée du projet [9].

OpenBSD

Pour le moment, il est possible de faire tourner un noyau OpenBSD en "guest" dans un Xen2 ou Xen3 [10]. Le support pour le Dom0 devrait arriver, mais il est nécessaire de faire des changements dans le bootloader OpenBSD pour que le noyau se charge correctement. Il n’y a, a priori, aucun projet d’intégration de Xen dans le système. De là à dire que Theo est has been...

Les *BSD dans ton GNU/Linux

"Eh oui, Maryse, ce n’est pas un *BSD que nous allons vous proposer avec le SuperXen, mais bien 3 *BSD, vous avez bien entendu, 3 *BSD pour la même somme qu’un seul pack de SuperXen." La machine hôte est basée sur une distribution Debian, la machine Xen2 est une Sarge avec un Xen2.0.7 compilé et la machine Xen3 est une Etch avec un Xen3 packagé standard. L’installation de cette machine n’a rien à foutre ici, donc ne posez même pas la question, nan, mais c’est vrai quoi, vous êtes pénibles à la fin [17][18]. Le système de fichiers des machines virtuelles sera créé dans un fichier pour des raisons de simplicité et pour éviter de me la péter avec tout le matos que je pourrais avoir. Mon répertoire de stockage des machines virtualisées est /var/xen/domains/<nom_domu>. Mes noyaux et autres fichiers en dehors de la configuration se trouvent dans mon répertoire personnel ~/xen/.

NetBSD dans la boiboite

NetBSD est d’une simplicité déconcertante à installer dans un DomU. Il faut récupérer les 2 noyaux concernés, un noyau pour l’installation et un noyau pour le fonctionnement courant. Ces noyaux peuvent être récupérés sur n’importe quel miroir NetBSD. En l’occurrence je choisis ftp.fr.netbsd.org. Ils se trouvent dans le répertoire /pub/NetBSD-daily/ des miroirs sous le chemin particulier netbsd-<release>/<snapshot>/i386/binary/kernel/netbsd-[INSTALL_]XEN[23]_DOMU.gz. Je vais là vous en mettre plein la vue et télécharger ces noyaux sans Firefox : Ou alors Une fois les noyaux décompressés, on peut commencer et se faire tout plein de plaisir.

Fichier de configuration

Le fichier de configuration est /etc/xen/netbsd.cfg. Pour commencer, j’indique que le noyau utilisé est celui d’installation. On remarque que j’ai déjà la ligne précisant le noyau de fonctionnement normal en commentaire. J’alloue 128M de ram au système "guest" et j’indique le système de fichiers à utiliser.

Création du système de fichier

On crée un fichier de 3Go qui va porter le système de fichiers pour cette installation :

Installer la machine

Il suffit maintenant de lancer le DomU et de procéder à l’installation du NetBSD. Après sélection de la langue de sysinst, on obtient l’écran nCurses suivant :

Il suffit maintenant de procéder à une installation normale de votre système. Cette installation est entièrement couverte dans l’excellent guide NetBSD [11]. A la fin de l’installation, ne redémarrez pas. Il reste une manipulation à faire. Depuis la racine de l’outil sysinst, choisir e: Menu utilitaire et ensuite a: Exécuter /bin/sh.

Démarrer la machine

Éditons le fichier de configuration pour maintenant utiliser le noyau netbsd-3-XEN2_DOMU. Il ne nous reste plus, à présent, qu’à relancer le DomU sans la console qui ne devrait plus servir. Le domaine est maintenant lancé, il faut finir l’installation en précisant une adresse IP pour la carte réseau qui apparaîtra sous le nom de xennet0 et éventuellement démarrer le service ssh, histoire de ne pas recourir à la console pour prendre la main sur cette machine. A l’issue de cette première configuration, on se déconnecte de la console à l’aide de [ctrl+]] et on ne discute pas ! Cette installation aurait pu se faire dans un Xen3 avec la même facilité.

Et c'est là que le Verbe s'adressa à moi

Le courant vacille, un puits de lumière s’abat sur mon visage et une voix tonitruante résonne dans mon crâne à m’en faire péter les synapses. "Tu peux faire BEAUCOUP mieux !". Et, effectivement, on peut encore s’amuser avec la serviette orange, même quand elle semble essorée comme une serpillière. Imaginons que vous vouliez ajouter le support de "PF" dans le noyau de votre DomU. Je suppose que tu sais compiler ton propre kernel NetBSD, sinon tu retournes dans ta chambre m’apprendre ce cours [12] ! Et tu seras probablement déconcerté par la simplicité enfantine de la procédure. Je vérifie d’abord si mon système actuel a le support kivabien pour PF (cf. article de Gaston p. 20 du hors-série 29). Nous allons donc compiler un nouveau noyau DomU avec le support de cet extraordinaire firewall qu’est PF (cf. article de Gaston) avec pour cible un Dom0 en Xen2. Le fichier de configuration de base pour ce faire se trouve dans le répertoire de configuration correspondant à ton architecture (arch/<architecture>/conf) avec un nom du type XEN[23]_DOMU. On décommente simplement les 2 lignes qui correspondent à PF et PFlog et c’est parti pour la partie de compilation habituelle. En aparté, la machine utilisée est équipée de 2 Xeon cadencés à 2,8GHz. Les guests en Xen2 ne peuvent profiter que d’un seul processeur. Le support multiprocesseur n’étant pas encore implémenté dans les DomU, l’hyperthreading n’apparaît pas non plus. A la fin de la compilation, on se retrouve avec un mignon petit noyau tout frais tout chaud dans le fichier netbsd. On transfère ce fichier sur la machine Dom0 pour pouvoir l’utiliser. On éteint la machine NetBSD d’une façon ou d’une autre. On peut se la faire cool avec un halt -p directement en console ou alors comme un sauvage avec un xm destroy. Il faut modifier le fichier de configuration pour que la variable kernel pointe vers ce nouveau noyau et on redémarre le DomU. Je me connecte maintenant à la machine NetBSD et je teste si PF : Chouette, on peut maintenant faire des circuits majorette avec nos lutins, des sens interdits, des culs de sac, des loopings et même la boucle qui monte sur le mur.

from __future__ import netbsd-4.0

Rassurez-vous tout de suite, nous n’aurons pas besoin d’1.21 jigowatts de puissance pour faire tourner netbsd-4 dans un environnement Xen3, le professeur Emmett Brown vous le dirait. Tout ce que ça nous coûte, c’est un petit téléchargement à l’adresse suivante ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/<snapshot>/i386/binary/kernel/ On va modifier un peu les choses par rapport à nos installations de NetBSD précédentes. On va effectuer l’opération dans une partition physique.

Fichier de configuration

C’est là que se situe la principale nouveauté en dehors de la version du noyau. On a précisé une partition physique comme disque. La syntaxe est simple à comprendre. Je vous laisse donc à vos copies : vous avez 1h pour épuiser le sujet suivant : "Les huîtres pratiquent-elles le cululingus ?". À noter tout de même, l’obligation d’ajouter une entrée vif vide pour activer la création d’une carte réseau virtuelle.

Installation de la machine

Tout se passe comme un charme, bien évidemment, et exactement de la même façon que précédemment indiqué dans la partie sus-citée... tout pareil quoi.

Il faut quand même adapter le chemin où aller chercher le système lorsque l’on choisit le mode d’installation FTP. Le chemin de base indiqué doit être celui du snapshot du noyau que vous utilisez de la forme pub/NetBSD-daily/netbsd-4/<snapshot>.

Il n’est plus nécessaire d’effectuer la copie des devices à la fin de l’installation et, là, on se retrouve avec Marty McFly les yeux pleins d’espoir devant une Deloreane 4.0_BETA2.

FreeBSD dans la boiboite

Installer un FreeBSD fonctionne à peu près de la même façon grâce à la contribution des développeurs FreeBSD [13] et d’utilisateurs [14]. Pour le moment, FreeBSD ne tourne que sur du Xen2 en version 5.3. Les efforts sont portés sur Xen3. Le principe est donc de télécharger 2 noyaux qui vont servir pour l’installation et le fonctionnement du DomU.

Fichier de configuration

C’est le même principe que précédemment hormis la variable extra que vos yeux de lynx n’auront pas manqué de repérer. L’option vfs.root.mountfrom nous permet de spécifier un point de montage fictif précisant le système de fichier utilisé. Quant à kern.hz, sa présence n’est pas nécessaire. Important Il est nécessaire que le montant de mémoire alloué lors de l’installation soit de 32, toute autre valeur fera planter le DomU au démarrage.

Création du système de fichier

On crée un fichier de 3Go qui va porter le système de fichier pour cette installation :

Installer la machine

J’ai obtenu les meilleurs résultats d’affichage en choisissant un terminal VT100. Vous devriez être illuminés par l’apparition du système d’installation de FreeBSD sysinstall :

Il faut noter tout de même qu’il y a quelques pièges au cours de l’installation. La création du slice FreeBSD va planter violemment si vous ne précisez pas une géométrie pour votre disque, quitte à en donner une fausse. L’option "G" de l’outil fdisk permet de donner une géométrie de 1/1/1 par exemple. Il faut aussi préciser quel serveur FTP utiliser pour installer le système. La release 5.3 étant passée en archive, il faut choisir un autre serveur FTP via l’option Specify some other ftp site by URL et donner le chemin suivant : ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/ L’installation risque d’être très lente via ce serveur d’archives.

Lorsque l’installation du système est terminée, il vous est demandé si vous voulez configurer des services de base tels que NFS, inetd ou SSH. Si vous souhaitez activer la compatibilité Linux, il faudra indiquer un serveur FTP particulier comme précédemment, la même adresse doit être utilisée. Finalement, il est recommandé de créer un compte utilisateur qui appartient au groupe wheel au cas où la configuration de la console ne fonctionnerait pas. A la fin de l’installation, revenir au menu pour configurer les TTY via le menu TTYs - Configure system ttys. Il faut activer la console et désactiver tous les pseudo-terminaux (ttyv[0-8]).

On précise que la connexion via la console se fait en mode secure, donc root est autorisé à se connecter.

Démarrer la machine

On peut modifier le fichier de configuration pour faire maintenant démarrer la machine en mode de fonctionnement normal : ATTENTION Il est très important de conserver la virgule en début de la variable extra : votre système ne démarrerait pas, et ça, pour une raison que nous ne la connaissons ni vous ni nous. On peut maintenant lancer le DomU avec console, pour vérifier son fonctionnement correct.

Le Bonux : l'installation plus rapide

Le principe est un peu bancal, mais permet d’installer le système beaucoup plus vite. La release 5.5 étant encore dans tous les FTP à l’heure de l’écriture de cet article, au lieu de préciser un repository archive, on va utiliser cette version FreeBSD. Au démarrage de sysinstall, allez dans le menu Options - View/Set various installation options. Une fois dans le menu, changer la valeur de "Release Name" et la mettre à "5.5-RELEASE".

Lors du choix du serveur FTP pour installer les ports, il suffit de choisir un serveur classique type ftp.fr.freebsd.org.

OpenBSD dans la boiboite

L’installation d’un DomU OpenBSD n’est pas aussi simple que pour les 2 précédents BSD. Le *BSD au poisson qui pique fait bien son office en piquant un peu là, oui là, juste sous l’ongle. Mais rien n’est impossible à une personne déterminée et encore une fois, à l’exception de NetBSD, l’intégration de Xen dans les noyaux *BSd en est à ses débuts. L’installation se fait ici dans un Xen3, on installe un OpenBSD 4.0.

Construire les noyaux

Le noyau nous est fourni par Christoph Egger qui a travaillé sur ce projet dans le cadre d’un Google Summer Of Code [15]. La machine utilisée comme repository mercurial est une machine de développement sur une petite connexion de toute évidence. Ne téléchargez les sources qui si vous souhaitez vraiment compiler ce noyau. En solution de remplacement, vous trouverez une archive des sources mercurial du noyau datant du 9 janvier 2007 dans l’archive de l’article [20]. Cette compilation doit se faire dans un environnement OpenBSD. Nous avons maintenant 2 noyaux OpenBSD à monter en DomU, openbsd-4_0-RAMDISK_XENU et openbsd-4_0-XENU.

Fichier de configuration

Le fichier de configuration est très semblable à ce que nous avons déjà mis en place précédemment. Vous devriez le comprendre sans problème.

Création du système de fichier

On crée un fichier de 3Go qui va porter le système de fichiers pour cette installation :

Installer la machine

Pour le moment, il m’a été impossible de lancer le noyau OpenBSD en mode installation. Malgré des rapports de succès de la part de la personne chez Google qui supervisait le projet [16], la réponse qui m’a été donnée est la suivante :

Conclusion

L’intégration de Xen dans les systèmes *BSD est faite de façon très inégale. Ca va de l’intégration complète pour NetBSD aux premiers balbutiements pour OpenBSD. L’intégration dans FreeBSD devrait être améliorée dans les futures versions du système, alors qu’OpenBSD n’a pas encore projeté d’intégrer Xen. Ces intégrations risquent d’être ralenties par l’apparition des processeurs avec support des instructions de virtualisation. Ces processeurs vont sûrement devenir de plus en plus courants. Sur ce type de processeur, il n’est pas nécessaire de modifier le noyau du système invité. Références [1] http://www.netbsd.org/ [2] http://www.freebsd.org/ [3] http://www.openbsd.org/ [4] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/xen/ [5] http://lists.xensource.com/archives/html/xen-devel/2004-01/msg00105.html [6] http://www.netbsd.org/Foundation/press/xen.html [7] http://www.netbsd.org/Ports/xen/ [8] http://www.freebsd.org/news/status/report-jan-2006-mar-2006.html#FreeBSD-on-Xen-3.0 [9] http://www.fsmware.com/xenofreebsd/7.0/STATUS [10] http://ropersonline.com/openbsd/xen/ [11] http://www.netbsd-fr.org/guide/fr/netbsd.html [12] http://www.netbsd.org/guide/en/chap-kernel.html [13] http://www.fsmware.com/xenofreebsd/5.3/ [14] http://txrx.org/xen/ [15] http://ropersonline.com/openbsd/xen/openbsd-xen-howto [16] http://anil.recoil.org/blog/articles/2006/08/21/openbsd-xen-boots-multi-user [17] http://www.debian-administration.org/articles/304 [18] http://www.debian-administration.org/articles/320 [19] http://wiki.xensource.com/xenwiki/HowTos [20] http://www.bonz.org/glmf_hs0207/linux_dom0_bsd_domu.tar.gz Remerciements Merci à Bsdmaniak et Raph_ael de m’avoir prêté du temps processeur sous OpenBSD.