Xen sous NetBSD: Comment, pourquoi, où ?
Préambule
Ceci est notre (doxin, monsieurp, zecrazytux, kimelto) install de NetBSD 4.0 sur nos (re-doxin, re-monsieurp, re-zecrazytux, re-kimelto) serveurs en dom0.
Ce n'est donc pas un manuel générique clicka-loutre à suivre bêtement sans réflêchir, et même si nous (monsieurp, doxin, zecraytux et kimelto) essaierons de le faire aussi générique que possible, il y aura sûrement des particularités liées au matériel et/ou config.
Ceci précisé (et maintenant qu'on passe bien pour des tyrans sataniques mangeurs de chèvres), on peut commencer.
Le but de cette configuration est donc un simple petit ‘laboratoire’ sur xen, et non pas forcément une plateforme complète ni optimisée pour tourner 5 ans en production.
Il semble bon de préciser dans un premier temps la config matérielle de la machine :
(Doxin)
Celeron 766Mhz et des brouettes.
256M de SDRAM (pour xen, ca va être léger, mais je suis pas un mec préssé)
2x10Go de DD, le tout bruyant comme un avion (enfin, comme deux, pour le coup).
(Zecrazytux)
2* PIII 1ghz
1,5Go SDRAM
500Go
=> ça tourne au poil !
(kimelto)
Mon lappy (je suis pas riche moi...)
Asus Z92J
(monsieurp)
En train de se palucher, ne file pas sa config...
L'installation de NetBSD
Le but de ce wiki n'est pas d'expliquer en détail comment installer NetBSD. L'installation de NetBSD n'est pas très compliquée en soit mais reste minimaliste, assez déroutante pour les débutants. L'assistant (sysinst) vous guide pas à pas pour ce qui est du partitionnement de votre disque à la sélection des paquets à installer. Comme tout bon wizard qui se respecte.
Petit concept à comprendre tout de même: NetBSD (comme tout les *BSD) fonctionne selon le principe des tranches de disques; ainsi, sysinst va découper votre disque non pas en partition mais en “disk slices” iqui contiendront les différents systèmes de fichiers nécessaires (/, /home, swap…).
Pour ce qui est du partitionnement, l'idée principale est : utiliser un disque pour le système et l'autre pour les vm. Cela me laisse donc 10Go pour le systeme (c'est a dire : plein!).
# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/wd0a 17G 7.6G 8.6G 46% /
kernfs 1.0K 1.0K 0B 100% /kern
Configuration post-installation
- SSHd
Premièrement, ce beau CRT 14” qui doit tourner à pas plus de 60Hz, vient dejà de me faire perdre 2 dixièmes à chaque oeil et j'aimerai bien utiliser SSH. Mais il n'est pas activé par défaut (le fourbe !).
Un petit tour dans /etc/rc.conf pour ajouter la ligne :
sshd=YES
puis
/etc/rc.d/sshd start
Pour information, le fichier rc.conf prévaut sur le fichier /etc/defaults/rc.conf, et il est bon de consulter /etc/defaults/rc.conf pour les options utiles (par contre, on est des gens propres, on met les modifications dans /etc/rc.conf !! teution hein !!).
SSH est maintenant activé, et c'est beau.
- Utilisateur SSH
Alors là, ouai, on est des gens sympas, mais faut pas trop rigoler non plus avec nous. Les plus malins d'entre nous auront réussi a lire entre les lignes quand le système nous susure lors du login root :
We recommend creating a non-root account and using su(1) for root access.
Il fallait bien sur comprendre :
Salut mon bon ami, tu ferais mieux de te créer un compte utilisateur et utiliser su, ou même sudo, et je te ferai des bisous.
Alors on s'attelle à la dure tâche de création des utilisateurs grâce a des commandes barbares telles que useradd(8) et groupadd(8) (attention, message subliminal : RTFM). Ce qui donne pour moi (ou nous, mais t'auras compris, ô visiteur) :
# groupadd doxin
# useradd -m -g doxin -G wheel doxin
# passwd doxin
- Installation des logiciels tierce-partie
Avant de commencer, “tierce partie” nan mais ca claque pas ca ? Si ca c'est pas du bling-bling, je sais pas ce que c'est.
Alors pour installer des trucs sur NetBSD, on utilise pkg_add. Je ne vais pas vous faire l'affront d'adapter ma prose pour les gens qui n'ont pas lu le man, je sais que vous venez de le faire parceque vous êtes des gens beaux et intelligents.
Donc on commence par configurer le PKG_PATH :
# export PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD-<RELEASE-NUMBER>/<PORT>/All"
Là encore, on aime pas être sale, alors on utilise les mirroirs qui sont le plus près possibles de la chambre ! Et on peut géolocaliser à la main les mirrors à cette URL : http://www.netbsd.org/mirrors/#ftp
Il ne nous reste plus qu'à installer ce qui nous plait :
# pkg_add -v sudo
# pkg_add -v vim
Une petite difference entre Linux et BSD : sous BSD, on sépare les applications installées par l'utilisateur de celles installés par le système. On ne retrouvera donc pas les bin dans /usr/bin, mais dans /usr/local/bin (FreeBSD, OpenBSD) ou /usr/pkg/bin (NetBSD) .
Par exemple, apres installation de zsh, en utilisant chsh, je lui spécifierai comme adresse de shell : /usr/pkg/bin/zsh
Installation de Xen en dom0
Pour commencer, nous allons installer les paquets nécessaires pour pouvoir acceuillir Xen en dom0 sur notre machine. On utilise pkg_add pour pouvoir installer les paquets grub, xenkernel et xentools.
# pkg_add -v grub
# pkg_add -v xenkernel3-3.1
# pkg_add -v xentools3-3.1
Une fois que pkg_add a fini d'installer les paquets et ses dépendances (notamment python pour Xen) (ça prend un peu de temps), on récupère le noyau NetBSD domaine 0 prévu pour s'éxecuter en parallèle avec Xen. Je reviendrais plus tard sur comment tout cela fonctionne. Du calme, du calme…
# cd / && ftp ftp://ftp.epitech.net/mirrors/ftp.netbsd.org/pub/NetBSD/NetBSD-4.0/i386/binary/kernel/netbsd-XEN3_DOM0.gz
# gunzip /netbsd-XEN3\_DOM0.gz
Puisqu'on y est, on peut se permettre de renommer le noyau générique (si ce n'est pas déjà fait) pour plus de clarté dans les noms de nos noyaux.
# mv /netbsd /netbsd-GENERIC
On doit donc se retrouver avec 2 noyaux.
# ls /netbsd-*
netbsd-GENERIC netbsd-XEN3_DOM0
Copions ensuite les init scripts tout prêts pour que xend et xenbackendd démarrent seuls comme des grands au démarrage du dom0.
# cp /usr/pkg/share/examples/rc.d/xend /etc/rc.d/
# cp /usr/pkg/share/examples/rc.d/xenbackendd /etc/rc.d/
# cp /usr/pkg/share/examples/rc.d/xendomains /etc/rc.d
On édite /etc/rc.conf pour y ajouter
xend=YES
xenbackendd=YES
xendomains="xen-dom1"
Les 2 premières lignes permettent de lancer au démarrage les 2 démons Xen, le dernier spécifie le domU qui a été configuré et qui sera démarré automatiquement au démarrage du dom0. Adaptez en fonction de vos besoins.
Dernière chose; il faut copier le noyau Xen sur la partition / et l'extraire. Celui-ci se trouve dans /usr/pkg/xen-kernel3/xen.gz.
# cp /usr/pkg/xen-kernel3/xen.gz / && gunzip /xen.gz
Nous avons tout ce qu'il faut pour pouvoir démarrer notre dom0. Passons à la configuration de GRUB. On vérifie quel est le nom du disque qui est monté en tant que partition racine /. Ici, un mount me renvoit:
/dev/wd0a on / type ffs (local)
Ce qui nous permet donc de taper gaiement:
# grub-install --no-floppy /dev/wd0a
Rendez-vous ensuite dans le répertoire /grub que GRUB vient de créer pour y éditer le menu.lst
# cd /grub && vi menu.lst
Comme je suis royal, je vous sors une config toute prête. C'est ça la classe.
GRUB [menu.lst](class:filename)
# La 1ère entrée est chargée automatiquement
default=0
# 10 secondes de temps d'attente avant que GRUB ne démarre automatiquement (sur default=0)
timeout=10
# Entrée 0 : Xen + NetBSD
title Xen 3.1.3 / NetBSD 4.0
root (hd0,0,a)
kernel (hd0,0,a)/xen dom0_mem=64M console=vga vga=keep
module (hd0,0,a)/netbsd-XEN3_DOM0 root=/dev/wd0a ro console=ttyS0
# Entrée 1 : NetBSD "normal" au cas où
title NetBSD 4.0
root (hd0,0,a)
kernel /netbsd-GENERIC
dom0_mem permet de spécifier la quantité de mémoire utilisée par le domaine 0. Sur les conseils de zecrazytux, 64m suffisent.
Si vous avez besoin de plus, adapter la valeur à vos besoins. J'ai eut quelques petits soucis avant de pouvoir démarrer correctement sur le domaine 0, notamment i“Xen is relinquishing VGA console” puis un freeze de la machine. “console=vga vga=keep” permet de donner une console VGA au noyau Xen pour qu'il affiche divers messages. Sinon pour le reste, c'est du classique.
On sauvegarde et on redémarre la machine. Normalement , le menu de GRUB doit faire son apparition et vous devriez pouvoir démarrer sur le noyau Xen. Lorsque vous redémarrez, vérifier en tapant uname -a que vous êtes bien dans votre domaine 0.
Installation d'un domU GNU/Linux
On y est, nous allons enfin pouvoir mettre en place notre domaine non-privilégié. C'est une partie que j'ai mit pas mal de temps à comprendre et à mettre en place. (à comprendre surtout)(doxin :D)
Comment Xen fonctionne ?
Je vous ait fait télécharger, dans la partie du dessus, un noyau Linux “xenifié”: il a été modifié de manière à mettre au courant l'OS invité (le domU) qu'il est train d'être virtualisé.
Dans ce noyau, on aussi rajouté une API pour que l'accès aux ressources matérielles se fasse plus rapidement.
C'est la paravirtualisation: cette technique permet de gagner en performance (contrairement à la full-virtualisation) et permet entre autre de pouvoir allouer des ressources (de la mémoire, des cpus, …) en plus aux machines virtuelles “on the fly” (à la volée).
Dans le domaine 0, le processus qui gère les domaines virtualisés est xend (celui que je vous ait fait ajouté dans /etc/rc.d) ou plus communément appellé l'hyperviseur, c'est grace à lui vous aurez accés à vos machines virtuelles. Les communications entre les machines virtuelles et le matériel se font via cet hyperviseur.
« Ok, elle est super ta vie mais comment je démarre une machine virtuelle là maintenant stp ? Moi j'attends ça depuis taleur namého !! »
Suivez le guide.
Nous allons commencer par démarrer un domU GNU/Linux Debian. (distribution facile à prendre en main, propre et efficace ).
Nous avons 2 solutions pour stocker nos machines virtuelles qui sont:
On partitionne son disque dur en fonction de l'espace disque que l'on veut allouer aux différentes machines que nous créerons.
On partitionne l'intégralité de son disque dur (ex: une grosse partition pour les machines virtuelles de 20 Go) pour y créer les images disques qui serviront à nos machines virtuelles.
J'utiliserais la 2ème solution car je la trouve plus flexible et moins contraignante. Tout d'abord, hiérarchisons nos répertoires pour pouvoir s'y retrouver facilement. Dans /, nous créons un repertoire xen: Créons ensuite un répertoire debian dans lequel nous mettrons nos 2 images disques (une pour le système de fichier, l'autre pour la swap).
# mkdir /xen/debian -p && cd /xen/debian
Jai ensuite créé un répertoire cfg dans le repertoire xen, pour y stocker les fichiers de configuration.
# mkdir /xen/cfg
Donnons les droits d'écriture au groupe wheel sur le répertoire xen et ses sous-répertoires (normalement, vous êtes dedans) (c'est pour plus tard)
# chmod -R 775 /xen
Note de zecrazytux: J'ai pour ma part cette arbo dédiée à xen:
/serv/ # exportée NFS
vm/
domains/
domU_1/
domU_1.cfg
domu_1.img
kernels/
BSD/
netbsd-INSTALL_xen3_domU
netbsd-xen3_domU
Linux/
vmlinuz-domU
organisé, ça permet de s'y retrouver ;) (surtout lorsqu'il y aura du opensolaris, autres bsd…)
C'est parti.
A partir de maintenant, les opérations s'effectueront sur une machine où GNU/Linux est en fonctionnement (avec comme distribution Debian, c'est mieux). En effet, l'utilitaire debootstrap n'existe pas sur les systèmes BSD. Cet utilitaire est un script écrit en shell qui permet d'installer, dans un répertoire, un système minimal Debian; j'ai essayé tant bien que mal de le modifier mais beaucoup d'options sont spécifiques à Linux, j'aurais bien aimé le porté sous *BSD mais en ce moment, je n'ai pas trop le temps de me pencher sur la question.
Le but est de créer une image contenant un système minimal Debian ainsi qu'une image swap. Une fois l'opératoire terminé, nous copierons tout ça (via scp) sur notre machine NetBSD pour pouvoir démarrer notre DomU.
Donc, depuis votre distribution favorite (si ce n'est pas Debian, voici un lien pour télécharger les sources de debootstrap et le compiler sur votre distribution Linux favorite: ftp://ftp.fr.debian.org/debian/pool/main/d/debootstrap/debootstrap_0.3.3.2.tar.gz), nous allons nous placer dans le répertoire personnel de root puis créer 2 images: une de 2 Go qui contiendra le strict minimum pour pouvoir démarrer notre DomU ainsi qu'une autre de 512 Mo pour la swap:
$ su
Password:
# cd
# dd if=/dev/zero of=/root/debian-disk.img bs=1024k seek=2000 count=1
# dd if=/dev/zero of=/root/debian-swap.img bs=1024k seek=512 count=1
Nous allons ensuite les formater. Je choisis ext2 pour l'image disque
# mke2fs debian-disk.img
mke2fs 1.40.7 (28-Feb-2008)
debian-disk.img is not a block special device.
Proceed anyway? (y,n)
tappez y
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
128256 inodes, 512256 blocks
25612 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=528482304
16 block groups
32768 blocks per group, 32768 fragments per group
8016 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 29491
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 27 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# mkswap debian-swap.img
Setting up swapspace version 1, size = 537915 kB
no label, UUID=6ef73a3a-ab7c-42eb-8cad-e4
Après avoir créé nos 2 images, nous montons l'image qui contiendra notre système minimal.
# mkdir /root/debian-install
# mount -o loop -t ext2 /root/debian-disk.img /root/debian-install
Debootstrapons !
# debootstrap --arch=i386 etch /root/debian-install http://ftp.fr.debian.org/debian
debootstrap va alors télécharger tout ce dont a besoin un système Debian (etch) (j'ai mis etch mais vous pouvez changer); ça prend environ 5 minutes, le temps de se faire un pti' café. Une fois revenu, on regarde si notre répertoire install est peuplé:
# ls /root/debian-install
bin boot dev etc home initrd lib lost+found media mnt opt proc root sbin srv sys tmp usr var
Parfait ! Avant de continuer, téléchargeons l'archive Xen contenant le noyau Xen pour un domU ainsi que les modules; ici, nous nous en servirons seulement pour les modules qui seront chargés au démarrage du noyau, lorsque notre domU démarrera. Je vous la ferais télécharger à nouveau une fois que nous retournerons sur notre cher et tendre NetBSD. Le lien est ici: http://bits.xensource.com/oss-xen/release/3.1.0/bin.tgz/xen-3.1.0-install-x86_32.tgz
Le domU fonctionnera en tant que système 32 bits sans PAE.
# wget -c http://bits.xensource.com/oss-xen/release/3.1.0/bin.tgz/xen-3.1.0-install-x86_32.tgz
# tar xzf xen-3.1.0-install-x86\_32.tgz
# mv /root/dist/install/lib/modules/2.6.18-xen /root/debian-install/lib/modules/
Nous allons ensuite nous chrooter à l'intérieur de l'image; il faut configurer l'adresse IP de la future machine, son hostname, toussa.
# chroot /root/debian-install /bin/bash
# vi /etc/network/interfaces
# L'interface réseau loopback
auto lo
iface lo inet loopback
# L'interface réseau primaire eth0
auto eth0
iface eth0 inet static
address 192.168.0.4
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
dns-nameservers 192.168.0.1
Ce sont les IPs de chez moi hein donc n'oubliez pas de mettre les votres ! (le C/C est nuisible pour la santé)
Ou utilisez le DHCP
# vi /etc/hostname
SuperDomU
# vi /etc/fstab
/dev/hda1 / ext2 defaults 0 1
/dev/hda2 swap swap defaults 0 0
proc /proc proc defaults 0 0
# vi /etc/apt/sources.list__
deb http://ftp.fr.debian.org/debian/ etch main
deb http://security.debian.org/ etch/updates main contrib
# mv /lib/tls /lib/tls.dis
# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Nous y sommes presque, courage ! Encore pti' effort..
# cd /lib/modules/2.6.18-xen/ && depmod
Et voilà ! Notre image est fin prête. Sortons de celle-ci et démontons là proprement.
# exit
# umount /root/debian-install
Envoyons le tout sur notre machine NetBSD pour pouvoir enfin lancer la sauce.
# scp /root/debian-disk.img doxin@1.2.4.5:/xen/debian/
# scp /root/debian-swap.img doxin@1.2.4.5/xen/debian/
Nous n'avons plus besoin de notre machine Debian, repassons des à présent sur NetBSD. Une fois que scp a fini de copier, comme je vous l'ai dit tout à l'heure (tu vois doxin, tu n'écoutes pas.. après tu vas encore poser la question !!), re-téléchargeons l'archive Xen. Cette fois-ci, nous aurons simplement besoin de prendre le noyau contenu dans l'archive au format binaire.
$ su
Password:
# cd /tmp
# wget -c http://bits.xensource.com/oss-xen/release/3.1.0/bin.tgz/xen-3.1.0-install-x86_32.tgz
# tar xzf xen-3.1.0-install-x86\_32.tgz
# mv /boot/dist/install/boot/vmlinuz-2.6.18-xen /vmlinuz-XEN3_DOMU
On termine par la création du fichier de configuration Xen pour amorcer le domU.
# cd /xen/cfg
# vi debian.cfg
Je vois que vous tirez la langue, vous transpirez, vous en avez marre de me lire, donc je suis gentil, je vous file le fichier de conf. J'ai connu un mec de droite une fois, il avait 10 fois plus de classe.
# Le noyau qu'on passe en argument au domU
kernel = "/vmlinuz-XEN3\_DOMU"
# La mémoire qu'on alloue au domU
memory = 128
# Le nom du domU
name = "SuperDomU"
cpu = "^1"
vif = [ 'bridge=bridge0' ]
# Le systeme de fichier que va charger le domU en tant que disque hda (hda1 = /, hda2 = swap). La lettre (w/r) correspond à écriture/lecture
disk = [ 'file:/xen/debian/debian-disk.img,hda1,w','file:/xen/debian/debian-swap.img,hda2,w' ]
# Sur quel disque démarre-t-on ?
root = "/dev/hda1"
Le moment tant attendu est enfin arrivé… Nous allons démarrer notre domU. La commande magique est la suivante:
# xm create -c /xen/cfg/debian.cfg
(-c permet de rattacher la console du domU à la console existante, sur laquelle vous êtes en train de travailler)
Using config file "./debian.cfg".
Started domain SuperDomU
(pas mal d'output sur la detection du hardware) ...
ect
Debian GNU/Linux 4.0 SuperDomU tty1
SuperDomU login: root
Password:
Last login: Thu Jun 12 15:39:23 2008 from 192.168.0.3 on pts/0
Linux debian-xen 2.6.18-xen #1 SMP Fri May 18 16:11:33 BST 2007 i686
SuperDomU:~# uname -a
Linux debian-xen 2.6.18-xen #1 SMP Fri May 18 16:11:33 BST 2007 i686 GNU/Linux
Et voilà, votre domU est fin prêt.
Autres distributions:
les outils urpmi de Mandriva permettent de faire une image minimale de Mandriva, un peu à la manière de debootstrap de Debian. A mon humble avis, on est loin de l'éfficacité de debootstrap, mais on peut s'en sortir.
Il est également possible d'utiliser toute sortes d'images de distros GNU/Linux. Ces images peuvent être réalisées directement avec Xen (en utilisant le CD d'install, mais cela nécessite de plus en plus souvent l'interface graphique (Xen implémente vnc), ce dont, nous utilisateurs de NetBSD, aimons nous passer dans ce genre d'utilisations.
Une solution facile à mettre en oeuvre mais quelque peu « bricolage », est d'utiliser qemu sur un desktop puis de transférer l'image sur le serveur via scp, par exemple.
Enfin, il existe des images prêtes à l'emploi téléchargeable sur ce site: JailTime
Installation d'un domU NetBSD
La création d'un domU GNU/Linux vous a certainement semblé quelque peu hasardeuse.
Avec NetBSD, voici venir la simplicité et l'efficacité !
Un kernel domU contenant sysinstall, l'installateur NetBSD, est disponible sur les FTP de notre BSD favoris :)
L'installateur permettant de choisir des sources locales, amovibles, mais aussi internet, rien d'autres que ce kernel et un accès internet n'est nécessaire à la création d'un domU NetBSD !
Créons le fichier de configuration: /serv/vm/domains/mon_supayr_domU_netbsd/supayr_domu.cfg
# Le kernel contenant sysinstall
kernel = "/serv/vm/kernels/bsd/netbsd-INSTALL_XEN3_DOMU"
memory = 256
name = "supayr_domu"
# j'aime bien assigner une ip fixe à mes domU, donc je fixe une mac :)
vif = [ 'mac=aa:00:00:00:00:04, bridge=bridge0' ]
# l'image est vide
disk = [ 'file:/serv/vm/domains/astaroth/astaroth.img,xbd0a,w' ]
# changement du « root », ce n'est pas « wd » dans un domU mais « xd »
root = "/dev/xbd0a"
Téléchargeons notre kernel génial, et son homologue sans sysintall
# ftp ftp://ftp2.fr.netbsd.org/pub/NetBSD/NetBSD-4.0/i386/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
# ftp ftp://ftp2.fr.netbsd.org/pub/NetBSD/NetBSD-4.0/i386/binary/kernel/netbsd-XEN3\_OMU.gz
Et hophophop, installons ce nouveau domU:
# xm create -c supayr_domu.cfg
Le kernel devrait booter correctement, et lancer l'isntallateur que vous connaissez déjà. Installez via internet (ftp)
Lorsque l'installation est terminée, il faut détruire/relancer le domU après avoir modifié le « kernel= » dans le fichier de configuration afin d'utiliser le kernel sans sysinstall :)
Enjoy :)
Problèmes et limitations:
BSD
Nous aurions aimés utiliser d'autres BSD, en particulier OpenBSD et FreeBSD. Or, à ce jour il n'existe aucun port viable (en paravirtualisation bien sur).
- OpenBSD
Un port OpenBSD est en cours, et est plus stable sur x86_64 (ce que nous n'utilisons pas). Le serveur était down aux dernières nouvelles.
- FreeBSD
Un port est en cours, prévu pour la release 8 si le code se stabilise à temps.
Le support de base a été commité tout recemment dans la branche CURRENT (http://marc.info/?l=freebsd-hackers&m=121944268810471&w=2).
Ce n'est donc pas aussi stable que son dévleppeur le voudrait, mais comme vous êtes impatients, je vous dit comment se compiler une image FreeBSD.
On récupère les sources de la version CURRENT (dans un dossier séparé)
svn co http://svn.freebsd.org/base/head/ /usr/srcCURRENT
Puis on lance la compilation du noyau avec la configuration “XEN” par défaut.
cd /usr/srcCURRENT && make buildkernel KERNCONF=XEN
NB: pour compiler avec le support de XEN, l'option PAE doit être activée, ce qui peux poser problème si le dom0 ne le supporte pas (ce qui est notre cas)…
- Conclusion
Autant NetBSD est vraiment utilisable en production, autant pour les autres *BSD, il va faloir s'armer de patience :)
Opensolaris / Solaris
D'après mes tests (nombreux), acune version de solaris/opensolaris (incluant les domU « ready to use » de sun et la toute dernière 2008.5) ne fonctionnent sur un dom0 NetBSD 4.0.
D'après mes lectures de mailing lists, cela serait corrigé sur NetBSD-current. N'ayant pas envie de tout péter alors que j'ai mon serveur en mini-prod-perso, je remet ces tests à plus tard.
J'obtiens un crash d'un domU au boot, avec des erreurs dans les logs de xen qui parlent de vbd… comment faire ?
Le problème survient généralement lorsqu'on tente de lancer un 3eme ou 4eme domU, ou un domU utilisant beaucoup de VBD…
Tout comme GNU/Linux ou le nombre de loop_devices est limité, sous NetBSD, les special devices utilisées pour les VBDs, n'existent qu'au nombre de 4 par défaut.
Il faut donc se rendre dans /dev et les créer:
# cd /dev && ./MAKEDEV vnd4 (5,6,... selon le nombre de VBD utilisés)