Es ergab sich, dass ich ein System zu virtualisieren hatte. Ein passender Hypervisor war schnell gefunden: Xen
Nun sollte das Host-System natürlich absolut stabil laufen, es reisst bei einem Absturz alle Gäste mit sich. Die Distribution der Wahl war also Debian, welches ich auch im ersten Test-Gast installierte. Debian hat einen Ruf als sehr stabile Distribution - stabil muss hier aber auch mit veraltet gleichgesetzt werden. Was folgen sollte, erinnert mich etwas an Wikipedia-Exklusionismus, über den ich so gerne berichte.
Ein Xen 3.2.1 findet sich in den Stable-Repositories, ebenso ein für Xen gepatchter Kernel 2.6.26-2. Diese waren flugs installiert und der erste Test-Gast aufgesetzt. Um das Netzwerk ein wenig zu testen, versuchte ich (mit entsprechendem Empfänger auf der Hostseite):
dd bs=1M count=1024 if=/dev/zero > /dev/tcp/192.168.23.1/1337
Unter einer normalen Bash kopiert dieser Befehl 1 GiB an Nullen an 192.168.23.1, Port 1337. Nicht so unter Debian:
-bash: /dev/tcp/192.168.23.1/1337: Datei oder Verzeichnis nicht gefunden
Ein wenig Recherche förderte Bug #146464 zu Tage. Frei interpretierrte Kurzfassung dieses Bugs, der 2002 eröffnet wurde und seit 2006 auf “wontfix” steht: Dafür gibts andere Tools, braucht bash nicht zu können. Dass die Bash-Entwickler und einige User das anders sehen, es Skripte gibt, die dieses Feature nutzen und keine Sicherheitslücken geöffnet werden, die nicht eh schon durch “andere Tools” da sind, ändert nichts daran. Erinnert an Wikipedia-Löschdiskussionen. Nun gut, das alleine wäre für mich kein Grund Debian zu verdammen - ich habe mir das Paket neu gebaut - es braucht schon etwas mehr.
Und es kam mehr. Der Xen-Hypervisor war mir zu alt und ich baute mir aus den Quellen einen neuen, 3.4.2. Der verträgt sich nicht ganz perfekt mit dem Debian-Kernel, also wurde auch noch Kernel 2.6.18.8 aus dem offiziellen Xen-Source gebaut. Obwohl ich es doch noch schaffte, Xen 3.4.2 mit dem Debian-Kernel zum laufen zu bringen, setzte ich mir ein Ziel: Backport von Xen 3.4.2 aus Debian Testing.
Auch wenn das nicht klappte, wie es sollte, so würde ich dieses Paket auch niemals einsetzen wollen. Wie in Bug #536175 nachzulesen ist, hat der Package Maintainer keine Lust, das security-hog called qemu für das nächste Stable-Release vorzubereiten. Das heisst: Keine vollvirtualisierten Maschinen, also kein Windows oder andere proprietäre Betriebssysteme. Warum ist er Maintainer, wenn er keine Lust hat? Der Bug ist wohlbemerkt nur eine Aufforderung zur deutlichen Kennzeichung, dass das halbe System fehlt.
Ich werde den Tip, den dieser Maintainer von sich gab, zwar nicht wörtlich befolgen, aber meinen Erst- und Letzteindruck von Debian hat er geprägt: