Pünktlich zum Erscheinen des aktuellen Ubuntu 12.04 erfolgte ein Update des OpenSLX-Basissystems. Damit kann auf dem gewohnten Weg des Clonens und Exportierens die neue Distribution bereitgestellt werden. Wie üblich gab es einige Änderungen im Startprozess von Ubuntu, die entsprechende Anpassungen erforderten. Das Bootsplash-Plugin kann ohne Probleme direkt übernommen werden.

Mit der Änderung bei den neueren Linux-Kernels und den Distributionen (Ubuntu und andere haben beispielsweise auf Plymouth umgestellt, SuSE macht immer noch ein eigenes Ding, was zwar am besten aussieht, aber einen aufwändigen Kernel-Patch erfordert) wurde es notwendig den alten Splashy-basierten Bootsplash abzulösen. Das Bootsplash-Plugin setzt nun auch Plymouth ein, da dieses der derzeitige Standard zu sein scheint. Für Theme-Anpassungen, die dann im nächsten Schritt für den Login-Manager eine Rolle spielen, sind folgende Dinge zu beachten:

• In der Vorlage kdm installieren, da gdm nicht mehr unterstützt wird. Dieser muss nun über gconf konfiguriert werden und nicht mehr über eine einfache Konfigurationsdatei, wie bei den früheren Versionen.
• Das Vorlagensystem muss erneut geclont werden, damit die entsprechenden Ergänzungen übernommen werden.
• Aus den vorgenannten Gründen muss nun die Variable desktop::manager auf kdm gesetzt werden.
• Am Ende müssen wie gewohnt noch der Export und der slxconfig-demuxer ablaufen.

Der Pool Video Switch (PVS) ist ein Werkzeug zur Display- und Tastatur/Maussteuerung von Linux-Rechnern zum Einsatz in Schulungsumgebungen, die beispielsweise auf einer OpenSLX-Basis laufen. Mit der aktuellen Version geht nun auch eine sinnvolle Nutzung von Tablet-Devices (beispielsweise ein angepasstes WeTab mit Linux als Basis) als PVS-Steuerkonsole. Mit einem solchen Gerät ist ein mobiler Einsatz möglich, setzt aber eine ausreichende WLAN-Anbindung in das Netz des Rechner-Pools voraus.

Nach dem die Überlegung wegen des relativ hohen Aufwands verworfen wurde, die VMware VMDKs per NBD/SquashFS gemeinsam zu exportieren – hier müsste nach jeder Änderung das SquashFS neu generiert und das Blockdevice neu exportiert werden – wurde nochmal ein Blick auf die Container selbst gerichtet. Das Tool vmware-vdiskmanager kennt den VMDK-Typ 5 (optimized for streaming), welches deutlich kleinere (d.h. komprimiertere) Images erstellt. So wurde aus einem 14 GByte Windows 7 Image eine 7 GByte Datei nach der Konvertierung (Reduktion auf 50%, müsste mit weiteren Images überprüft werden). Der Aufruf hierfür lautet:
vmware-vdiskmanager -r source-image.vmdk -t 5 compressed-image.vmdk
Der Vorgang brauchte jedoch seine Zeit, im Beispiel übers Netz zehn Minuten.

Ein Streaming-Image brauchte zum Starten geringfügig weniger Zeit und transferierte dabei ca. 1/4 bis 1/3 weniger Daten. Nach zehn Minuten waren dieses 1.2 GByte vom Server für das komprimierte und 1.8 GByte für das unkomprimierte Windows 7 Image. Der Upstream lag im Testbeispiel mit ca. 30-50 MByte deutlich darunter.

Bisher werden die Virtuellen Maschinen Images üblicherweise via NFS in einem gemeinsamen Ordner bereitgestellt. Es gab mal die Überlegung diesen Export via SquashFS/NBD zu machen, aber der Aufwand das SquashFS nach jeder Änderung neu zu generieren, schien nicht sehr attraktiv und zudem wenig praktikabel. Stattdessen wurde nun das Ganze via Network Blockdevice ohne den Umweg via Filesystem realisiert: Dabei wird die Blockdevice-Datei wie eine normale Filesystemimage-Datei angesprochen, dabei ist es völlig egal, wie die Datei intern aufgebaut ist.

Im getesteten Setup erfolgt der NBD-Export (via nbd-server) einfach auf jedes einzelne VMDK, das damit als Blockdevice-Datei interpretiert wird. Auf der Client-Seite wird ein NBD-Device ganz normal per nbd-client erzeugt, was eine typische Device-Datei (/dev/nbdN) ergibt. Dieses Block-Device wird dann aber eben nicht gemountet, sondern direkt angesprochen. Am einfachsten zeigt ein Link, der das VMDK (, VDI, …) repräsentiert, einfach auf die Datei des Blockdevices, z.B. /dev/nbd7/ … Andere Blockdevices (DNBD2, iSCSI) sollten sich ebenso eignen, wurden aber noch nicht getestet.

In einem generellen, weiteren Schritt, könnte dann auch überlegt werden, dass “Diffing” (Wegschreiben der Session-Unterschiede) über dieses Blockdevice (zumindest NBD kennt ein COW) zu realisieren, statt es beispielsweise in einen RW-NFS-Share zu machen. Das sollte insbesondere bei Maschinen mit relativ wenig RAM und dem Redo auf NFS die Sache deutlich vereinfachen. Dann würde man aber das Image nicht non-persistent sondern persistent nutzen.

Die ganze Aktion sollte das NFS erheblich entlasten. Der Netzwerktraffic wird sich nicht wesentlich verändern, auch wenn das Caching auf dem Client bei wiederholten Blöcken was ausmachen sollte. Die Performance scheint sich zu verbessern, wie folgende sehr grobe Messungen zeigten. Diese erfolgten später am Abend, damit das Netz schon relativ leer war. Eine Geschwindigkeitsmessung wurde mit drei verschiedenen Servern gemacht:

• NBD A: Neuere Dell-Servermaschine mit 24 GByte RAM, 10 Gbit/s Netz, Hardware-Raid auf zwei SAS (nicht super fix), OS: Scientific Linux 5.4 (2.6.18er Kernel)
• NBD B: Sechs Jahre alte SUN V20z mit 8 GByte RAM, 2 Gbit/s Netz, Software-Raid über zwei ältere SCSI-320-Platten, OS: Debian 6 (2.6.32 Kernel)
• SUN-Server (24+GByte, …, 10 GBit/s Netz), OS: Aktuelles Solaris auf ZFS

Im ersten Test war kein Server direkt im Netz des Clients, im zweiten Fall nur der NBD B. Dabei ging es dann aber trotzdem noch über einen Stapel von Switches.

Die Messung erfolgte immer beim dritten Start in der gleichen Konfiguration zum Ausschluss von Caching-Unterschieden auf einem Dual-AMD-Turion, der 3+ Jahre alt ist, 4 GByte RAM hatte und via Gigabit ans Netz angeschlossen ist:

NBD A – 1.15 Min
NBD B – 1.35 Min
NFS – 1.46 Min

Die Messungen wurden auf einer neueren Maschine (ca. 1 Jahr alt, Intel E5300 CPU, 4 GByte RAM, Gigabit Netzwerkanschluss) wiederholt:

NBD A – 1.02 Min
NBD B – 1.05 Min
NFS – 2.02 Min

Im ersten (optimalen) Fall wurden 30 Sekunden (~70% der Standardstartzeit) Einsparung erreicht. Interessant im zweiten Setup war, dass hier NFS und NBD fast um den Faktor zwei auseinanderliegen, sich NBD auf dem alten und dem neuen Server aber kaum unterschieden. Schwer zu bestimmen ist hier der Einfluss von Netzwerk und Maschinenperformance. Die beiden Rechner standen in verschiedenen Teilnetzen mit etwas unterschiedlicher dahinterliegender Infrastruktur, die aber mindestens 1 Gigabit bereitstellt.