Premiers pas vers un environnement de test NetBSD/Xen

2009-12-20T15:50:01+01:00

Loin des préoccupations über-théoriques de bluestorm, ces temps-ci, moi, j’ai essayé de bosser un peu, pour la Junior Entreprise locale. Autant dire que ça ne se passe pas tellement bien : on manque de main d’œuvre compétente et sérieuse, et honnêtement, ça m’irrite au plus haut point que le client soit perpétuellement déçu de notre travail ; c’est comme si je faisais du mauvais travail, mais franchement, si je savais que je me taperais autant de glands à gérer et autant de boulot pour lequel je n’ai pas signé, je n’aurais jamais accepté ce job. Bref, paraît qu’il y a des années avec et des années sans, bah là c’est clairement une année sans.

Tout ceci me mène à une petite anecdote : au cours de mon travail, je suis amené à tester le produit que je développe (la nature duquel est un secret…) dans une perspective de déploiement sur serveur. Récemment, je me suis heurté à des bugs que je n’arrive pas à reproduire sur ma machine de développement, pour une raison ou pour une autre (je n’ai pas encore réglé le souci), qui semble être liée au déploiement lui-même, du moins la configuration employée. Du coup, pour bien faire, je me suis dit que j’allais monter un petit serveur de test… un petit serveur virtuel !

Et ça tombe bien, j’ai toujours trouvé que Xen, ça avait l’air sympa ! Et en plus, chez NetBSD, on semble accorder une certaine importance au support Xen, ce qui est plutôt cool. Je me suis donc mis en tête de configurer un joli petit environnement NetBSD+Xen, le but étant d’avoir un serveur virtuel tournant sur une NetBSD vanilla, avec le minimum de paquetages nécessaires au déploiement de mon application. Bref, un truc propre.^α

α : Le véritable serveur tourne sous Linux, mais pour du test rapide, il est beaucoup plus simple pour moi de virtualiser du NetBSD ; j’écrirai peut-être un autre billet, si je me fais un test Linux+Xen.

Xen pour les innocents

Pour me la jouer à la blueblue, je vais dire deux mots pour ceux qui ne connaîtraient pas le principe. Ahem, donc pour ceux qui ne connaîtraient pas, Xen est une solution de virtualisation,^β comme VirtualBox… mais pas tellement en fait.

β : … principalement destinée aux serveurs, mais hey !

Avec VirtualBox, vous avez votre système normal et par-dessus, un petit logiciel qui fait tourner en son sein un autre système d’exploitation.

Xen est un peu différent. Vous ne pouvez pas simplement lancer Xen depuis votre système préféré, comme vous lanceriez un programme quelconque… c’est en fait plutôt l’inverse : Xen est une espèce de méta-système (un hyperviseur) qui va se charger de lancer vos systèmes d’exploitation un à un ! Si donc avant vous aviez, disons une Ubuntu avec une NetBSD dans votre VirtualBox, vous auriez maintenant l’hyperviseur Xen, et deux domaines (c’est comme ça que ça s’appelle dans Xen) : votre Ubuntu, et votre NetBSD.^γ

γ : Pour tout vous dire, ce n’est probablement pas le meilleur choix… Ubuntu ne semble pas intégrer, dans sa ligne de développement centrale le support de Xen. Voyez la documentation communautaire d'Ubuntu sur Xen pour plus de détails.

Tous les domaines ne sont pas égaux pour autant : il y a toujours un système principal, appelé dom0 (domaine 0) ; les autres sont les domaines U (domU). Le dom0, c’est un peu le root de tous vos domaines : il a tous les pouvoirs, tandis que les autres ont des droits restreints, notamment concernant l’accès au réseau et au matériel. Au démarrage, Xen lance le dom0, qui a à sa charge de créer les domU qu’il désire (ou plutôt d’ordonner à Xen de les créer). Dans notre exemple, Ubuntu est le dom0, et NetBSD, le seul domU.

La dernière chose à savoir est que pour pouvoir être géré par Xen, il faut que le noyau soit conçu pour dialoguer avec l’hyperviseur, qui fait office d’abstraction entre la machine et le système. Il y a des noyaux dom0 et des noyaux domU. NetBSD propose dans sa distribution officielle des noyaux dom0 et domU ; sous Gentoo, compiler un noyau Xen est juste une histoire de changer de paquetage sources ; je ne sais pas trop ce qu’il en est des autres distributions Linux…

Bref, si vous ne connaissiez pas Xen, voilà qui est réglé. Il est temps de passer aux choses sérieuses…

Notes d’installation

Peut-être parce que c’est destiné à des mecs un peu underground, des sysadmins et tout, il n’y a pas beaucoup de tutos sur Xen… du moins, il y en a, mais beaucoup ne sont plus à jour et offrent des informations périmées. Notamment, le howto officiel de NetBSD/xen est, en l’état, incorrect.^δ C’est fort dommage car mettre en place un environnement Xen avec NetBSD est en réalité très simple… pour peu que l’on sache comment s’y prendre.

J’offre ici mes humbles notes d’installation. Sait-on jamais, peut-être mon expérience servira-t-elle à quelqu’un.

δ : Si je mets la main sur ces permissions de commit un jour, je devrais ptet y faire quelque chose… Normalement, je fais signer ma clef GPG ce lundi !

Si NetBSD est livré avec tout ce qu’il faut pour le faire tourner comme domaine Xen, Xen lui-même (l’hyperviseur et les outils pour le contrôler depuis le dom0) est à installer via pkgsrc. Il y a un jeu de paquetages par version majeure de Xen. Dans mon cas, j’ai pris la 3 :
```
# cd /usr/pkgsrc/xenkernel3 && make install
# cd /usr/pkgsrc/xentools3 && make install
```
Le noyau Xen s’installe très logiquement dans la hiérarchie /usr/pkg. À l’heure où j’écris ces lignes, le fichier en question est /usr/pkg/xen3-kernel/xen.gz.
On aura aussi besoin de scripts de démarrage pour les démons Xen xend et xenbackendd. J’ai simplement recopié ceux fournis à l’endroit habituel :
```
# ln -s /usr/pkg/share/examples/rc.d/xend /etc/rc.d/
# ln -s /usr/pkg/share/examples/rc.d/xenbackendd /etc/rc.d/
```
Pour l’instant, ces démons ne font rien ; ils ne peuvent même être lancés (mais on peut déjà les ajouter dans le rc.conf, histoire de ne pas oublier). Il nous manque un dom0…
Concernant le dom0, la bonne nouvelle, c’est que seul le noyau a besoin d’être modifié : juste en changeant de noyau au démarrage, on peut décider d’utiliser Xen ou pas, tout ça avec le même jeu de programmes, les mêmes disques et systèmes de fichiers, etc.
Pour se faire un noyau dom0, rien de plus simple : un noyau dom0 est fourni avec NetBSD (XEN3_DOM0) ; en partant de sa configuration, j’ai simplement modifié le fichier à ma convenance (comme j’ai fait pour le noyau GENERIC, pour obtenir ma configuration non Xen), puis config et make ont fait le reste, comme d’habitude :
```
# cd /usr/src/sys/arch/conf/
# cp XEN3_DOM0 ELHAYM_DOM0
# emacs ELHAYM_DOM0
# config ELHAYM_DOM0
# cd ../compile/ELHAYM_DOM0
# make depend && make
# cp netbsd /netbsd-dom0
```
Pour avoir testé, il est sensiblement plus difficile de partir de la configuraiton personnalisée (dérivée de GENERIC) pour la rendre compatible avec Xen, que de partir de la configuration Xen pour l’adapter à la machine…
Quelques défauts remarquables du noyau compatible Xen par rapport à un noyau NetBSD normal :
- pas de SMP ;
- pas de changement de fréquence SpeedStep du processeur (corrigé dans NetBSD-current, il me semble) ;
- l’ACPI a quelques soucis chez moi (le poweroff ne fonctionne pas et la machine s’arrête simplement, sans s’éteindre)…
Une fois le nouveau noyau fraîchement compilé, il suffit d’ajouter la ligne correspondante dans le boot.cfg. Autrefois, il fallait passer par Grub, à la place du bootloader NetBSD ; ce n’est plus le cas aujourd’hui, et tant mieux ! Les manips sont d’autant plus simple.
À noter que la ligne à ajouter ne lance pas le nouveau noyau directement ; elle doit lancer l’hyperviseur, en lui indiquant le chemin du dom0. Quelque chose comme ceci (dans boot.cfg, il faut placer les instructions sur une seule ligne en les séparant par des points-virgules, bien sûr) :
```
load /netbsd-dom0 console=pc
multiboot /usr/pkg/xen3-kernel/xen.gz dom0_mem=max:1536M
```
Limiter la mémoire pouvant être allouée au dom0 permet d’être sûr de pouvoir créer les domU quand on en a besoin. Je n’ai pas trouvé d’autre moyen de réduire la mémoire consommée par un domaine.
Vient ensuite le domU, la configuration duquel est contrôlée par un fichier, que j’ai, pour ma part, simplement emprunté aux exemples fournis avec le paquetage :
```
# cp /usr/pkg/share/examples/xen/netbsd1 /usr/pkg/etc/xen/test
```
Le fichier est commenté, et c’est plutôt explicite. Cependant, quand on débute dans ce vaste monde, comme moi, ce n’est pas forcément évident pour autant…
1. Tout d’abord, ça paraît stupide, mais domU, au départ, correspond à une machine vierge, sans système d’exploitation. Cela ne sert donc pas à grand chose de charger un noyau domU (par exemple le noyau XEN3_DOMU standard de NetBSD) vu qu’il ne trouvera rien sur le disque… Il faut en fait charger un noyau d’installation (INSTALL_XEN3_DOMU), qui contient un ramdisk avec sysinst.
```
#kernel = '/netbsd-domu'
kernel = '/netbsd-install-domu'
```
2. La seconde variable d’intérêt s’appelle disk. Elle décrit les disques virtuels disponibles à l’intérieur du domU. Créer un disque virtuel vivant dans un fichier est le plus simple :
```
vif = ['file:/var/xen/images/test.img,0x01,w']
```
  Pour l’installation du domU (avec le noyau d’installation), il ne faut pas non plus oublier de configurer le disque virtuel correspondant au CD-ROM contenant les sets d’installation NetBSD (les gros fichiers .tgz contenant l’userland précompilé) :
```
vif = ['file:/var/xen/images/test.img,0x01,w',
       'file:/var/xen/images/install.iso,0x02,r']
```
  L’ISO se télécharge simplement sur un miroir NetBSD, dans le dossier iso/ (séparé des autres dossiers de fichiers d’installation).
  Ces disques apparaîtront dans le domU NetBSD sous la forme de périphériques xbd (le premier étant xbd0, le second xbd1, etc.). D’autres systèmes interprètent cela différemment.^ε
  ε : Sous Linux, le second paramètre de la description du disque virtuel spécifie le périphérique à créer dans le domU.
  Le seul point délicat sur lequel je suis tombé est que pour utiliser un fichier en guise de disque virtuel (file:), il faut absolument que ce fichier ne soit pas creux (sparse), sans quoi vnd(4), le périphérique virtuel permettant de monter un fichier comme un disque, est incapable de fonctionner correctement.
  En pratique, cela signifie utiliser dd count=N plutôt que dd seek=N pour créer le fichier.
3. Enfin, la configuration du réseau mérite un point à elle toute seule. Le principe est que Xen expose deux interfaces réseau (type Ethernet) connectées : une du côté domU (qui s’appelle xennet sous NetBSD) et une du côté dom0 (xvif sous NetBSD).
  Ce qui est fait de ces interfaces est laissé libre à l’administrateur, et est typiquement contrôlé par des scripts. Il y a deux scripts fournis avec le paquetage, vif-bridge et vif-ip, permettant respectivement d’obtenir un pont (bridge(4)) ou une simple IP statique privée associée au domU.^ζ
  Pour ma part, j’ai choisi la seconde solution, car elle me convient mieux. Je n’ai pas besoin d’accéder à Internet depuis mon domU, et si cela devait se présenter, je pense que j’essaierai de mettre en place de la redirection, et du NAT. Pour utiliser par défaut vif-ip, il suffit de modifier le fichier de configuration de xend (/usr/pkg/etc/xen/xend-config.sxp, syntaxe s-exp, d’où le nom) :
```
(vif-script vif-ip)
```
  Avec une telle configuration, la ligne de configuration du vif ressemble à :
```
vif = ['ip=192.168.127.2 netmask 255.255.255.0']
```
  La valeur du sous-paramètre ip est simplement passée à ifconfig(8) pour configurer l’interface xvif (côté dom0). Le script ajoute automatiquement le sous-réseau mentionné (ici 192.168.127/24) dans la table de routage afin de diriger le trafic en direction de celui-ci à travers la bonne interface xvif. Cela signifie, en bref, qu’il suffit de donner une adresse IP appartenant au même sous-réseau à l’interface xennet, du côté du domU, et tout marche comme si les deux domaines étaient sur un même réseau !
  ζ : Le script proposé dans le howto NetBSD/xen est périmé. Celui fourni avec le paquetage semble très bien marcher.
Une fois le fichier de configuration écrit, il suffit de faire appel à xm create, et tak.
L’installation se passe comme une installation classique, par CD-ROM (à part que le périphérique CD est ici xbd1). Une fois terminée, il suffit de changer de noyau (dans le fichier de configuration du domU), et hop ! Une fois les briques de base en place, on peut passer à l’installation des paquetages que l’on veut.
Pour ça, j’ai utilisé la solution cheap : un chroot(8) dans le vnd(4), en réutilisant les paquetages précompilés par pkgsrc pour ma NetBSD principale (avec un petit mount_union(8)).
```
# vnconfig vnd0 /var/xen/images/test.img
# mount /dev/vnd0a /mnt/
# mkdir /mnt/usr/pkgsrc/
# mount -t union -o -b /usr/pkgsrc/ /mnt/usr/pkgsrc/
# chroot /mnt/ /bin/sh
# export PKG_PATH=/usr/pkgsrc/packages/All/
# pkg_add ...
```
Et voilà ! Un joli environnement de test. :)

Impressions

Avec tout ça, j’ai un truc qui tourne. Je peux même tout simplement copier le disque en l’état, pour produire des environnements de test en masse.

Ceci dit, même si je considère Xen comme une technologie « cool », tout n’est pas rose. Au-delà des défauts que possède la version dom0 de NetBSD (principalement l’absence de SMP), j’ai eu du mal à trouver de la doc pertinente, et c’est un gros problème pour l’adoption de Xen par un public moins gurutique, à mon avis.

Cela mis à part, comme dit plus haut, je trouve, à titre personnel, que Xen avec NetBSD, c’est plutôt facile à mettre en place une fois que l’on a compris le truc ; et même si la doc comporte quelques erreurs, à l’heure actuelle, cela donne une bonne base sur laquelle partir.

Je ne sais pas ce qu’il en est des distributions Linux. J’entends souvent les gens opposer KVM à Xen. Je ne connais pas KVM donc je ne saurais pas trop dire ce qu’il en est. Mais du coup, il semblerait que l’adoption de Xen dans le monde Linux soit moindre… dommage ? Je ne saurais pas dire.

Ours & Hippy — le blog

Premiers pas vers un environnement de test NetBSD/Xen

Xen pour les innocents

Notes d’installation

Impressions