Ce midi, le domU GCU était injoignable. Une connexion VNC nous permet de voir que le noyau vomissait depuis quelques minutes une floppée de :
rtk0: unable to allocate Tx cluster
Une rapide recherche nous amène sur ce post qui, comme on pouvait le soupçonner, explique que les cartes de type rtl8139 sont moisies, mais que dans l’urgence, l’ajout de la directive :
options NMBCLUSTERS=4096
à la conf kernel permet de résoudre le problème.
"re0: watchdog timeout"
Voila tout ce que nous obtenions lorsque nous choisissions le driver NIC rtl8139 pour un domU NetBSD ou OpenBSD.
Finalement, c’est une réponse de Manuel Bouyer sur port-xen qui donne la solution: Désactiver re* ! C’est alors rtk* qui prend la main, et là, point de timeout, de latences ou autres dysfonctionnement, “juste ça marche”.
alors moi je dis: y.e.s.
Upgrade de Xen en 3.1 sur mon lappy boulot, juste pour voir, et YES, enfin ce !@#!@# de module b44 (BCM4401-B0) fonctionne out-of-the-box !
Il s’agit d’une debian testing, pour laquelle j’ai suivi ce tuto, excepté pour la partie mkinitrd qui pedalait dans le vide, je lui ai donc préféré mkinitramfs, utilisé de cette façon :
# mkinitramfs -o /boot/initrd.img-2.6.18-xen 2.6.18-xen
Décidemment, le “choix” de l’OS d’un domU n’est pas si large qu’il n’y parait…
Nous avions statué l’archi suivante pour zone0 :
. dom0: debian stable amd64 + Xen 3.1
. domU services: OpenBSD 4.1 amd64
. domU shells: OpenBSD 4.1 amd64
. domU www1: NetBSD 3.1 x86
. domU www2: NetBSD 3.1 x86
Le choix de NetBSD x86 avait été dicté par le fait que l’installation même de la version 64 bits s’avérait impossible, cette dernière ne trouvant jamais le media cd0.
Du fait de l’architecture de services un peu particulière que nous avions à l’esprit, nous avons du compiler certains ports OpenBSD… et là, mauvaise surprise, un bête ./configure faisait loader la machine à 3 et prenait en moyenne un quart d’heure, à raison de 3 secondes par ligne ! Après quelques recherches, nous trouvons quelques threads sur des problèmes similaires, mais toutes les pistes évoquées -même un vilain patch du cpu.c du noyau- ne donnent aucun résultat.
Hier soir, nous nous sommes donc rabattus sur la version x86 d’OpenBSD, et comme on pouvait s’y attendre: plus de soucis. Les deux domUs carburent, les ./configure et autres compilations sont rapides, et les machines virtuelles semblent stables, mêmes soumises à quelques stress tests de forking et de memoire.
Il semble que le problème concerne l’utilisation de fork() -qu’un ./configure utilise evidemment massivement-.
L’archi finale est donc :
. dom0: debian stable amd64 + Xen 3.1
. domU services: OpenBSD 4.1 x86
. domU shells: OpenBSD 4.1 x86
. domU www1: NetBSD 3.1 x86
. domU www2: NetBSD 3.1 x86
Une dernière astuce, pour une raison que j’ignore, une de plus, le boot cd cd41.iso fait paniquer le domU dès le chargement du noyau, aussi, pour installer OpenBSD 4.1, j’ai utilisé l’image cdemu qui n’a posé aucune complication.
Rackage imminent.
tu sais ce que c’est que ça lutin ?
ça, c’est le nombre de CDs / UNICes / Linux que j’ai du tester avant de tomber sur une configuration adéquate pour :
. Faire tourner un dom0 Xen en 64 bits
. Faire tourner autre chose que du Linux en domU 64 bits
Le magic combo, c’est Debian Stable (Etch) amd64 + Xen 3.1
Pour le moment je fais tourner un domU OpenBSD amd64 et un domU NetBSD amd64 en hvm (CPU VT capable evidemment)
Pour le setup debian/Xen 3.1, je me suis calé la dessus: http://bderzhavets.blogspot.com/2007/08/xen-3_27.html
Ma conf de bridging ressemble à ça :
auto eth0
iface eth0 inet manual
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0
Et un domU classique à ça :
kernel = '/usr/lib/xen-default/boot/hvmloader' builder = 'hvm' memory = '1024' name = 'services' device_model = '/usr/lib/xen-default/bin/qemu-dm' nic=1 vif = [ 'type=ioemu, bridge=xenbr0' ] sdl=0 # L'output sera visible sur un serveur vnc sur son display 1 vnc=1 vnclisten='192.168.10.20' vncunused=0 vncdisplay=1 vncpasswd='' disk = [ 'phy:/dev/mapper/pwepwetvg-jolilv,ioemu:hda,w', 'file:/home/imil/iso/ i386cd.iso,hdc:cdrom,r' ] boot = 'd'
Petit hint, l’export vnc ne fonctionne par “out of the box”, une rapide recherche nous indique qu’il faut installer ceci :
aptitude install libsdl1.2debian-all
Je posterai la conf complète de zone0, la future machine GCU que je setupe de cette façon, sur le wiki GCU dès qu’on aura atteint un état définitif.
Recent Comments