Emile “iMil” Heitor ‘s home

Voici ce que crachait l’un de mes dom0 Debian/Squeeze sous Xen 4.0:

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 matin, j’ai mis à jour le dom0 Debian d’une de mes machines. Passionnant me direz-vous. L’opération a consisté en la migration de Lenny vers Squeeze. De plus en plus interessant hein ? L’upgrade s’est effectué sans trop de peine, après quelques apt-get -f install et autres réinstallations de packages ayant sauté dans la bataille, rien de palpitant. Me voici donc avec un kernel 2.6.35-2 sur un Xen 4 flambant neuf.

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

C’est remarquable cette propension des petits lutins bleus de la nuit à aller bousiller les seules machines qui ne sont pas backupées, ils savent tout, ils voient tout, et ce sont de sacrés petits pervers de merde.

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.

On peut lire sur GCU que nous avons passé une partie du week end, après un bafr bien arrosé, à mettre à jour Zone0.GCU-Squad.org, machine qui héberge le site, et moult services du groupe.

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.

Pkgin utilisable, je me suis engagé à l’intégrer dans PackageKit afin que NetBSD dispose rapidement d’une interface graphique permettant de manipuler des packages.

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 :

Pour tester “en vrai” mon fameux pkg_dry (work in progress, pas du tout utilisable, pas d’affolement), je devais posséder une VM NetBSD 5 “poubelle”. Seulement, depuis quelques temps déjà, je sais que cette version panic‘e sur KVM, VirtualBox et Xen HVM. Aussi me suis-je décidé à Xenifier ma machine de developpement NetBSD qui n’a pas d’instructions VT, afin d’y faire tourner un domU en paravirtualisation.

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.