Nov 10 05:32:22 yavin kernel: [838380.839883] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
Nov 10 05:32:22 yavin kernel: [838380.839883] Modules linked in: dummy xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_physdev iptable_filter ip_tables x_tables xen_evtchn xenfs bridge stp ext2 w83627hf w83793 hwmon_vid loop snd_pcm snd_timer snd radeon soundcore snd_page_alloc ttm drm_kms_helper parport_pc drm parport pcspkr evdev i2c_i801 i2c_algo_bit rng_core serio_raw i2c_core container shpchp pci_hotplug i3000_edac button processor edac_core acpi_processor ext3 jbd mbcache dm_mod raid1 md_mod sd_mod crc_t10dif ata_generic uhci_hcd ata_piix libata thermal floppy ehci_hcd scsi_mod thermal_sys usbcore nls_base e1000e [last unloaded: dummy]

Le tout saupoudré de quelques stack traces du meilleur effet:

Nov 11 19:52:20 yavin kernel: [976376.042974]    [] ? xen_swiotlb_unmap_page+0x0/0x5
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_force_evtchn_callback+0x9/0xa
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? check_events+0x12/0x20
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_swiotlb_unmap_page+0x0/0x5
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_restore_fl_direct_end+0x0/0x1
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? kfree+0xc6/0xcb
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? skb_release_head_state+0xb4/0xc8
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? __kfree_skb+0x9/0x7d
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_put_txbuf+0x5a/0x6c [e1000e]
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_clean_tx_irq+0x9d/0x21e [e1000e]
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_clean+0x5c/0x235 [e1000e]

Et j’en passe. Bref, ça pue.

Après m’être documenté quelque peu sur les erreurs constatées, deux actions semblent avoir stabilisé la situation. Premièrement, plusieurs posts dans quelques forums indiquent que l’installation de intel-microcode et microcode.ctl permet de “réparer” certains bugs embarqués dans les processeurs Intel. Je m’execute:

# apt-get install intel-microcode microcode.ctl

Deuxièmement, comme le conseille la section Best Practices de Xen.org, il est de bon ton de:

• Fixer la quantité de mémoire du dom0 afin d’éviter le ballooning
• Attacher un core (“cpu pinning”) au dom0

Ainsi, j’ajoute la ligne suivante au fichier /etc/default/grub:

GRUB_CMDLINE_XEN="dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin"

Et précise dans /etc/xen/xend-config.sxp:

(dom0-min-mem 1024)

Ne disposant, sur cette machine, que de deux cores, je n’exclurai pas le CPU0 de la configuration des domU, mais fais confiance à l’hyperviseur pour équilibrer les ressources efficacement, sachant que désormais le CPU0 est “pinné” au dom0. Reste alors à régénérer la configuration de grub:

# update-grub

Et, malheureusement, de rebooter. Pas le choix ici.

Moyennant ces ajustements, mon dom0 ne semble plus souffir, alors que ses domUs compilent à tour de bras.

Ce dom0 accueille des domU NetBSD. Des NetBSD 5.0.2 pour être précis. Et c’est le drame: Le PR 44743 indique en effet:

Subject: Network doesn’t work on DomU NetBSD 5.1 which is run on Debian Squeeze Dom0 (Xen 4)

Ce à quoi Dieu^WManuel Bouyer répond:

No, copy mode support was added to the backend (dom0) before 5.1, but
it was added to the frontend (domU) after 5.1 was released. So you need
something newer from the netbsd-5 branch.

Vous voyez poindre le bordel ? “Mais migre, bigre de couillon” me direz-vous, et vous aurez raison, seulement cette machine construit des packages (via bulk build, voir le post précédent) pour un certain nombre d’autres machines, elles aussi en 5.0.2. Bref, rien n’est simple. J’ai donc adopté une méthode “alternative” (aussi appelée la méthode *rhon* *rhon* *huiiiiii*): patcher le noyau 5.0.2 avec les bits and pieces nécessaires en provenance de netbsd-5. Finalement, cela n’a pas été si compliqué. Il suffit de cvs up -rnetbsd-5 -dP dans src/sys/arch/xen et src/sys/arch/x86 puis de relancer un config, make depend, make pour obtenir un noyau domU 5.0.2 muni du support copy mode.

“All went better than expected”.

Hier matin, alors que je m’apprétais à faire le tour de mes mails avant de partir au boulot, je constate avec effroi que “je ne sors plus”. Comportement plus qu’étrange, ma passerelle récupère bien l’IP publique Free via DHCP, le ping passe quelques secondes, puis s’arrête, plus rien. Inévitablement, je commence à blâmer Free -bien qu’objectivement, je n’ai pas recontré de problèmes majeurs depuis des mois-, puis par acquis de conscience, teste le lien sur une machine differente. Ça passe.

Mon ancienne passerelle était un peu bancale, il faut l’avouer; il s’agissait d’une Sun Netra X1 gracieusement léguée par monsieur ange pendant Solutions Linux 2008, qui faisait tourner un OpenBSD 4.1 qui paniquait environ tous les trois mois.

Il ne m’en fallait pas plus pour plancher sur une nouvelle gateway, sous NetBSD cette fois. M’est alors apparu l’idée de faire fonctionner cette passerelle dans un domU, après tout, en bridgeant l’interface qui reçoit le réseau Free à une interface Xen, et de la même manière, en bridgeant l’interface raccordée à mon LAN, cela devrait fonctionner sans accroc: et bien c’est le cas.

Voici les fichiers impliqués dans ce mic-mac:

Sur le dom0, je déclare mes interfaces comme suit :

$ cat /etc/ifconfig.fxp0 # LAN
inet 192.168.0.10 netmask 255.255.255.0
$ cat /etc/ifconfig.fxp1 # Free
up

Puis je déclare des bridges sur ces interfaces :

$ cat /etc/ifconfig.bridge0 # LAN
create
!brconfig $int add fxp0 up
$ cat /etc/ifconfig.bridge1 # Free
create
!brconfig $int add fxp1 up

Ce qui nous donne, dans la configuration du domU :

$ cat /usr/pkg/etc/xen/exar
#kernel = "/home/imil/xen/netbsd-5.0.2-INSTALL_XEN3_DOMU.gz"
kernel = "/home/imil/xen/netbsd-5.0.2-XEN3_DOMU-pf.gz"
memory = 256
name = "exar"
vcpus = 1
disk = [ 'file:/home/imil/xen/exar.img,0x03,w' ]
disk += [ 'file:/home/imil/iso/amd64cd-5.0.2.iso,0x04,r' ]
vif = [ 'bridge=bridge0' ]
vif += [ 'bridge=bridge1' ]
bootdev = "/dev/xbd0a"

Notez le nom du noyau qui sert à faire booter cette VM, netbsd-5.0.2-XEN3_DOMU-pf.gz. En effet, un modload /usr/lkm/pf.o fait misérablement crasher le domU, il est donc nécessaire de se fendre d’une recompilation du noyau domU en incluant à la configuration :

pseudo-device   pf                      # PF packet filter
pseudo-device   pflog                   # PF log if

Sur le domU-passerelle, on constate la présence des deux interfaces :

$ ifconfig -a
xennet0: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]
xennet1: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]

Leur configuration est triviale :

exar$ cat /etc/ifconfig.xennet0 # LAN
inet 192.168.0.254 netmask 255.255.255.0
exar$ cat /etc/ifconfig.xennet1 # Free
up
!dhclient $int

Et voila !

On active le NAT gràce à pf :

ext_if="xennet1"
int_if="xennet0"

nat on $ext_if from !($ext_if) -> ($ext_if:0)

Et me voila à nouveau en mesure de raconter ma vie trépidante sur l’Intarwebz.

Il faut l’avouer, cette mise à jour fut une promenade de santé en comparaison de sa cauchemardesque installation voila deux ans. Je me propose tout de même de vous raconter les quelques manipulations qui furent nécessaires à sa migration vers 2009.

Rappelez-vous, Zone0 c’était :

• Un quad-core VT-capable
• Une debian etch
• Un noyau Linux 2.6.18 patché en raison d’un bug du driver du controlleur RAID 3ware
• En conséquence du point précedent, un Xen 3.1 roulé sous les aisselles en provenance de Xen.org

Contre toute attente, un simple :%s/etch/lenny/g suivi d’un apt-get update && apt-get dist-upgrade a rectifié la situation bancale d’un Xen et d’un noyau non-issus de debian, ce qui rendait tout upgrade très périlleux.

Il est à noter qu’en raison du passage de lvm1 à lvm2, il a été nécessaire de se refendre d’un apt-get dist-upgrade, alors seulement l’installation d’un nouveau noyau utilisera les nouveaux hooks de lvm2 pour générer un initrd correct. Le noyau installé est en l’occurrence linux-image-2.6.26-2-xen-amd64.

Un reboot plus tard, le dom0 2.6.26 était controllé par Xen 3.2.

Pour être tout à fait honnête, nous avons planché quelques minutes sur un problème lié à l’ancienne installation. En effet, les domUs hvm ne démarraient pas, et nous constations que qemu-dm, l’executable en charge de virtualiser les péripheriques, était en état defunct. La raison était en réalité simplissime, les configurations de nos domUs faisaient appel aux fichiers /usr/lib/xen/boot/hvmloader et /usr/lib/xen/bin/qemu-dm, or c’étaient les anciens binaires qui se trouvaient là, ceux installés par la version 3.2 issue du package debian se trouvent dans /usr/lib/xen-default (qui est un lien logique vers /usr/lib/xen-3.2-1). Rien de bien méchant.

Une fois rebootée, c’en était fini pour notre session au datacenter, et il me revenait de mettre à jour les deux domUs NetBSD. Double (quadruple donc) mise à jour, puisqu’en plus de migrer les deux systèmes vers NetBSD 5.0.1, en raison de l’incroyable gain de performance que j’avais constaté entre le mode HVM et Paravirtualisé de Xen, j’avais prévu de profiter de cet upgrade massif pour basculer les domUs NetBSD en mode paravirtualisé.

Là encore, rien de terrifiant, dans la configuration des domUs, j’ai simplement remplacé :

kernel = '/usr/lib/xen-3.2-1/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen-3.2-1/bin/qemu-dm'

par

kernel = '/home/xen/NetBSD/5.0.1/netbsd-XEN3PAE_DOMU.gz'

Après avoir booté les domUs sur ce kernel domU modifié, il n’a s’agit que d’une procédure d’upgrade des plus classiques, suivie de la mise à jour des packages à l’aide de pkg_comp (recréé pour correspondre au système réel) puis pkg_chk.

Les machines, virtuelles et réelles, semblent bien se comporter, et je suis désormais complètement convaincu par la supériorité du mode paravirtualisé, les temps de réponse sont simplement sidérants.

Je ne souhaitais pas polluer ma machine de développement avec une myriade de librairies et utilitaires graphiques, aussi ai-je installé un domU NetBSD 5.0 prévu à cet effet.
Afin de simuler l’utilisation d’une station de travail sans pour autant installer plusieurs téras de logiciels, j’ai choisi xfce4. Son installation est désormais simplissime (quoi, j’ai le droit de me brosser un peu) :

$ sudo pkgin in xfce4

Il faudra placer les variables suivantes dans le fichier /etc/rc.conf du domU

rpcbind=YES
famd=YES
dbus=YES
hal=YES

pour démarrer l’usine à gaz la machinerie fam,dbus,hal.

Vous connaissez probablement le drapeau -X de ssh(1) permettant de faire transiter du traffic X11 à travers la session ssh. Il conviendra de placer la variable suivante dans le fichier /etc/ssh/sshd_conf du serveur (du domU dans notre cas) afin d’autoriser sshd(8) à forwarder le protocole X11 :

X11Forwarding yes

Moyennant quoi, on se connecte au domU de cette façon :

$ ssh -X mondomu

Nous afficherons alors une session X11 à l’aide du server Xnest(1). Il suffira de renseigner le fichier ~/.xinitrc comme pour un serveur X classique :

xfce4-session

Et de démarrer son environnement de cette façon :

$ xinit -- /usr/X11R7/bin/Xnest

Afin d’obtenir ce résultat :

Voici la compilation des documents utiles :

• Le HOWTO officiell NetBSD/xen (pas à jour)
• Le HOWTO du wiki NetBSD
• Un post sur port-xen qui donne quelques informations supplémentaires

Ce qu’il faut savoir :

• Il n’est plus nécessaire d’utiliser grub pour démarrer le noyau Xen, le bootloader standard fonctionne parfaitement
• En ajout à la doc du wiki NetBSD, j’ai du spécifier le bootdev dans mon /boot.cfg, le cas écheant, le noyau tentait de booter sur sd0a
• De la même manière, dans la conf de mon domU, j’ai du ajouter la directive bootdev = "/dev/xbd0a"
• J’utilise des images et non de vrais disques, la ligne correspondante dans la conf du domU est: disk = [ 'file:/home/imil/xen/slave-1.img,0x03,w', 'file:/home/imil/iso/netbsd-i386.iso,0x04,r' ]

À noter que je suis extremement impressionné par la rapidité d’un domU paravirtualisé, n’ayant jusqu’à présent utilisé que des guests HVM.

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.

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”.

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

. 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.