Xen

Enable iSCSI support in NetBSD domU

Dynamic module loading via modload has a couple of issues with a NetBSD domU kernel, so it is not possible to modload iscsi.kmod. In order to enable in-kernel iSCSI support, you’ll have to add the following lines to your kernel configuration and rebuild it: dmesg should show this line: You’ll then be able to start iscsid and manage your targets using iscsictl.

Install NetBSD (or any PV-capable system) on IBM's SoftLayer

At ${DAYWORK}, I happen to use IBM’s cloud: SoftLayer. It has all the features you’d expect from such a platform, and can instantiate pretty much any major GNU/Linux distribution you’d think of; but here’s the thing, we also use NetBSD for some infrastructure services, and as you’d guess, there’s no NetBSD support at all on SoftLayer. I had to reverse some bits of their provisioning system to understand how to achieve NetBSD installation, but most of all, automatic provisioning.

Tu te CALMES le dom0

Voici ce que crachait l’un de mes dom0 Debian/Squeeze sous Xen 4.0: Le tout saupoudré de quelques stack traces du meilleur effet: 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: Deuxièmement, comme le conseille la section Best Practices de Xen.

MIX ALL THE SOURCES!!!

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.

Crassshhhh

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.

Les migrations de la rentrée

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.

Xen, ssh et Xnest, segmenter pour travailler proprement

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) :

Xen et NetBSD 5, la compil

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 :

rtl8139, la carte des winners

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 : 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 : à la conf kernel permet de résoudre le problème.

NetBSD hvm et rtl8139

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