OpenSLX

h1. Virtualisierung

Virtualisierung auf X86 ist inzwischen ein weit fortgeschrittenes Konzept. Sie erlaubt es verschiedene Betriebssysteme gleichzeitig auf einem SLX-Client ablaufen zu lassen. Einerseits lässt sich so ein Windows-Desktop als alternative grafische Oberfläche anbieten oder andererseits voneinander abgeschottet im Hintergrund Cluster-Rechnen zur Nutzung freier CPU-Ressourcen betreiben.

Es gibt verschiedene Virtualisierungslösungen, deren Integration via [[OpenSLX-Plugins]] erfolgt.

* [[VMware]]-Workstation und -Player (bis Version 7.X)

* [[VirtualBox]] (incl. aktueller Version)

* [[Xen]] (beta, ziemlich komplex wegen spezieller Kernels)

* [[QEMUKVM]] (beta)

h2. Windows-Desktop und andere Systeme auf OpenSLX-Workstations

Die Steuerung erfolgt generell mittels XML-Datei, die im selben Verzeichnis, wie die @*.vmdk@, bei VMware, oder entsprechenden Image-Typen liegt. Die Integration erfolgt in erster Linie mittels [[vmchooser|VM-Chooser-Plugin]]. Hier wird beispielsweise das Floppy-Image zur Weitergabe der Konfiguration (@config.xml@) eingebunden.

Eine vom Image-Administrator (Tool oder Admin) erstellte Datei wird via [[VMchooser]] und [[VMware]]-Plugin zum Windows-Login-Tool weitergeleitet und auf diesem Wege ergänzt. Das Windows-Login-Tool bekommt die modifizierte XML-Datei in einem virtuellen Diskettenlaufwerk bereit gestellt (dieses könnte je nach Virtualisierungsumgebung noch angepasst werden). Diese wird beim Login in der Windowsumgebung ausgewertet um bei Bedarf folgende Aufgaben auszuführen:

* Einbinen des Home-Laufwerks des Benutzers

* Installation und Einbinden der verfügbaren Drucker

* Einbinden der Scannern

* Einbinden von Shared-Laufwerken

Nach dem Login werden folgende Funktionen (abhängig von den Einstellungen in der XML-Datei) zur Verfügung gestellt:

* Anzeige des freien/belegten Speicherplatzes auf dem Homelaufwerk

* Verknüpfungen auf dem Desktop zu allen eingebundenen Laufwerken

* Anzeige des Druckerkontostandes mit einem Direktlink zum Aufladen des Druckerkontos

Die Vorlage-XML-Datei kann auf der Plugin-Seite von [[VMchooser#XML-Datei]] angesehen werden.

h2. Redo-Dateien der Virtualisierer

Da alle Clients auf eine gemeinsame Image-Datei einer bestimmten eingerichteten virtuellen Maschine zugreifen, müssen die während des Laufs entstehenden Differenzdaten (Blöcke des nur lesbaren Images, die sich im Betrieb ändern) irgendwo abgelegt werden. Das passiert bei Diskless-Clients im Hauptspeicher. Da dieser ziemlich endlich ist, stürzt bei Überlauf die Maschine ab oder beschwert sich über zu knappen verfügbaren Restspeicher für die Differenzdaten.

h3. Lokale Festplatte nutzen

Wenn eine lokale Festplatte in der Maschine installiert ist, kann diese durch das Festlegen einer Partition mit einer ID44 nach _/tmp_ eingebunden werden. Das passiert automatisch im Stage3. Diese Partition wird immer beim Hochfahren der Maschine neu formatiert, um zu verhindern, dass sie durch alte Daten überlaufen kann. Sinnvollerweise hat man dazu dann im Vorlagensystem die XFS-Tools installiert, da das Formatieren größerer Partitionen mit Ext2/3/4 länger dauert. Diese Variante sollte eine recht hohe Performance aufweisen, da nur auf lokale Geräte geschrieben wird (die sonst auch nicht weiter genutzt würden) und kein zusätzlicher Traffic auf dem Netzwerk anfällt.

h3. Linear RAID aus lokalem RAM und Remote Blockdevice

Ein komplett festplattenloses System kann seine Daten nur im RAM ablegen oder über das Netz auf Hintergrundspeicher in einem File- oder Blockdevice-Server schreiben. Eine Möglichkeit zu verhindern, dass eine Standardsitzung einer virtuellen Maschine sofort das Netzwerk in Anspruch nimmt, was sich insbesondere bei einem "Massenstart" von virtuellen Maschinen doppelt negativ auswirken würde. Dann würden einerseits gerade alle angeforderten Blöcke der virtuellen Festplatte des startenden VM-Gasts gelesen werden und sich ändernde Blöcke gleichzeitig wieder weggeschrieben. Dieses Problem lässt sich durch ein spezielles Blockdevice umgehen, welches aus einem kleineren lokalen RAM-Teil und einem größeren Hintergrundsteil besteht, wobei letzterer auf einem ausreichend leistungsfähigen Server liegt.

h4. Das lokale RAM-Blockdevice

Das TempFS auf den Clients, welches sich direkt für die Differenzdateien eignet, lässt sich nicht direkt als virtuelles Blockdevice verwenden. Deshalb muss eine leere Datei erzeugt werden, die dann via *losetup* zu einem Blockdevice wird. Dieses lässt sich dann mittels *mdadm* zu einem linearen RAID mit dem Hintergrundspeicher auf dem Server (siehe dazu weiter unten) verbinden.

<pre>

dd if=/dev/zero of=1024MB count=1 seek=1024 bs=1MB

losetup /dev/loopN /tmp/1024MB

mdadm --create /dev/md0 --level=linear --raid-devices=2 /dev/loop0 /dev/XXXXX

mkfs.xfs -f /dev/md0 # mkfs.ext2 -m0 /dev/md0

</pre>

Ein Einsatz von LVM2 anstelle des einfacheren RAIDs verbietet sich, da es deutlich komplexer vom Setup ist (und damit einen höheren Zeitbedarf hat) und deutlich mehr IO auf den Dateien beim Setup generiert. Damit ist auch keine strikte Trennung mehr gegeben, dass kleine Datenmengen keinen Netzwerk-Traffic verursachen.

Als Filesystem bietet sich typischerweise XFS an, da es sehr schnell formatiert. Ext2 geht bei kleineren Gerätetypen auch. Filesysteme sollten so getuned werden, dass sie wenig Inodes anlegen, da die Zahl der Dateien in diesem speziellen Verzeichnis recht überschaubar bleibt. Filesystem-Reserve für den Superuser ist ebenfalls überflüssig.

h4. NBD-COW als Remote Blockdevice

Eine recht performante Möglichkeit ist der Einsatz von NBD (Standardbestandteil des Kernels und einer jeden Distribution). Hier kann einfach eine leere Datei der maximal zugesicherten Größe, beispielsweise 4-8 GByte angelegt werden, die dann im Copy-on-Write-Modus an die angeschlossenen Clients exportiert wird.

<pre>

dd if=/dev/zero of=mdstuff count=1 seek=4095 bs=1MB

nbd-server 5100 /srv/nbd/mdstuff -c

</pre>

Das Elegante der Lösung liegt darin, dass die Datei durch das Seek lediglich ein knappes Megabyte belegt. Die Diff-Dateien, die für jeden sich verbindenden Client angelegt werden, können nur bis zur Größe dieser Datei wachsen, so dass sich der maximale Speicherbedarf auf dem Server leicht kalkulieren lässt. Zudem werden die Diff-Files wieder gelöscht, wenn der Client sich sauber wieder abmeldet. Damit besteht nur ein Bedarf für die tatsächlich von den Clients angeforderte Zusatzspeichermenge, wenn der lokale RAM-Anteil überläuft.

Die Clients binden den NBD-Server wie gewohnt ein und erhalten dann ein lokales Blockdevice _/dev/nbdN_.

h4. Loopback-File-Blockdevice

Eine Alternative wäre die Nutzung eines beschreibbaren NFS, auf dem eine Blockdevice-Datei angelegt wird. Diese könnte ebenso, wie die anderen Beispiele leer angelegt werden und gibt mit ihrer Größe die maximale Größe vor, die ein Client belegen kann. Diese Datei könnte vom Client ad-hoc angelegt und am Ende wieder gelöscht werden.

<pre>

dd if=/dev/zero of=4096MB count=1 seek=4095 bs=1MB

losetup /dev/loopN+1 4096MB

</pre>

Der Overhead und die Feinsteuerung wären vermutlich mit NFS etwas aufwändiger als mit dem NBD. Es müsste überwacht werden, dass man für die Clients ein Quota im Auge behält, da sonst der NFS-Share recht voll werden könnte.

h4. Einsatz auf dem Client

Auf dem Client sollte das Filesystem auf dem RAID für jede VM-Session neu generiert werden, da sonst die Dateien nicht mehr an den Anfang geschrieben werden und damit u.U. sofort wieder Netzwerkverkehr erzeugen. Da die VM durch einen normalen User gestartet wird und die meisten genannten Programme privilegierten Zugang benötigen, sind einige weitergehende Überlegungen notwendig. So liesse sich beispielsweise *sudo* verwenden, um ganz bestimmte Programme zu authentifizieren.