Kapitel 10
VMware - Windows Diskless

VMware-Workstation, bzw. VMPlayer ist auf der Basis von SLX-Clients interessant, da es erlaubt weitere Betriebssysteme, besonders welche aus dem Hause Microsoft, diskless zu betreiben, die dieses eigentlich nicht vorsehen. Jedoch stellen SLX-Clients besondere Anforderungen an die Installation von VMware, da einige Grundannahmen von denen VMware ausgeht, sich auf Diskless Maschinen anders darstellen und entsprechend anders behandelt werden müssen.

Im ersten Teil des Kapitels wird VMware als Software-Komponente unter Linux vorgestellt und kurz erklärt, wie es sich als Emulator eines PC verhält. Im zweiten Teil erfolgen zwei Anwendungsbeispiele für Microsoft-Betriebssysteme: Windows 98 und Windows XP.

10.1 VMware auf Diskless Clients

VMware kann in einer ganzen Reihe Szenarien benutzt werden, welche keine exorbitanten Anforderungen an die Grafik-, Festplatten- und Speicher-IO-Leistung stellen. Generell kann man davon ausgehen, dass die Leistungseinbußen der reinen CPU-Power zwischen 10-30 % liegen. Die Festplattenperformance kann nicht mit der realen Hardware mithalten und nicht alle Geräte, wie z.B. DVD oder Sound können exakt abgebildet werden. Für festplattenlose Umgebungen kommen in erster Linie virtuelle Disks in Frage, die (non)persistent oder rückgängig-machbar betrieben werden. Nonpersistente Festplatten sind für eine Reihe der nachfolgend beschriebenen Szenarien geeignet. Man kann auf diese Weise die Virtuelle Maschine immer auf ein definiertes Niveau bringen und im gleichen Status starten. Beispiele für den Einsatz von undoable Festplatten, sind unter anderem die Installation von Software oder das Ausführen von Verwaltungsaufgaben, die eventuell später, wenn Probleme auftreten, rückgängig gemacht werden müssen.

10.1.1 Einsatzbereiche mit OpenSLX

Folgende Szenarien sind vorstellbar, wovon einige sich aus der besonderen Konstellation der SLX-Clients heraus ergeben:

• Kursarbeitsplätze und Schulungsrechner
• Ergänzung des eingesetzten Host-OS durch externe Applikationen
• Ausstattung von vielen gleichartigen Arbeitsplätzen, wie im Hotline-, Callcenter- oder Beratungsbereich üblich
• ”Stabilisierung” von in der Administration aufwändigen OS
• Schaffung einer ”transportablen” Arbeitsumgebung auch zwischen räumlich sehr weit auseinanderliegenden Einheiten

Ein wichtiges Einsatzfeld sind Schulungsräume in denen für verschiedene Kurse unterschiedliche Betriebssysteme präsentiert und vielleicht nur mit sehr kurzen Zwischenpausen genutzt werden sollen. Hier kommt es selten auf die reine Performance an, sondern mehr auf das generelle ”Gefühl” im Umgang mit einem spezifischen OS. Arbeitet man mit virtuellen Festplatten kann ein einziges geeignet vorbereitetes Image zentral zur Verfügung gestellt oder an die einzelnen Clients verteilt werden. Im besten Falle gelingt es ein einziges nonpersistentes Image für alle Systeme gleichzeitig z.B. über NFS einzubinden. So wird sichergestellt, dass alle TeilnehmerInnen eines Kurses von den gleichen Startbedingungen ausgehen. Für diesen aus Sicht des Autors optimalen Fall sind jedoch eventuelle Spezialanpassungen des Gastbetriebssystems notwendig. Das betrifft insbesondere die Microsoft-Produkte. Ein Beispiel für Windows XP wird im folgenden Abschnitt beispielhaft erläutert. Eine besondere Kurssituation bietet sicherlich das ”nicht-kooperative” Benutzerumfeld in Schulen: Zwar sind diese inzwischen weitgehend mit Rechnern ausgestattet, jedoch bietet eine klassische Consumer-Windowsinstallation kaum die optimale Arbeitsgrundlage. Häufig sind die Maschinen verstellt, die Softwareinstallationen nicht einheitlich oder vollständig oder die Geräte so manipuliert, dass wenig funktioniert.

In einem nächsten Schritt können Kursleiter ihre Arbeitsumgebungen bei der Vorbereitung, z.B. zu Hause, in einer eigenen VMware-Installation anpassen und notwendige Software installieren. Das fertige Image wird im Kurs an alle Teilnehmer verteilt oder diesen zentral zur Verfügung gestellt. Aufwändige Koordination zwischen Technikern und Kursleitern wird unnötig, nachträgliche Anpassungen der einzelnen Arbeitsplätze kann entfallen. Neue Modelle eines Kursbetriebes werden möglich. Dadurch erhält man eine transportable Umgebung in der ein mit allen wichtigen Daten vorkonfigurierter Arbeitsplatz rechnerunabhängig benutzt werden kann. So könnte z.B. der eigene Desktop auf dem Leih-Laptop zu einem Kongress mitgenommen werden, ohne dass spezielle Anpassungen des OS an die neue Hardware notwendig wären. Der Transport solcher speziellen VM-Images stellt heute keine größeren Probleme mehr dar: CD-Brenner sind weitverbreitet und die Verwendung von CD-RW Rohlingen bietet Platz für bis zu 700 MByte große Images, die für viele Szenarien ausreichen. Weiterhin denkbar sind USB-Sticks, CompactFlash-Memory-Karten oder DVD-RW-Lösungen. Diese sind inzwischen erschwinglich und bieten mehrere GByte an Platz.

Stehen bestimmte Applikationen unter einem OS nicht zur Verfügung kann VMware Abhilfe schaffen. Solche Programme werden dann unter dem passenden Betriebssystem in einer VM-Box aufgerufen. Jedoch ist der Datenaustausch nicht so komfortabel wie unter einer einheitlichen Plattform oder Benutzeroberfläche. Er muss über den Umweg der Netzwerkspeicherung oder Diskettenimages geführt werden.

Ein anderes Einsatzgebiet ist die Langzeitarchivierung von Software und Dokumenten. Mit VMware können Betriebssysteme in einer bestimmten Konfiguration ”eingefroren” werden ohne dass hierfür separate Hardware vorgehalten werden muss. Stellt man eine solche Umgebung wiederum auf nonpersistent können keine ungewollten Änderungen am Archivsystem erfolgen. Auf diese Weise kann ältere Software, für die es keine Portierungen auf aktuelle Betriebssysteme gibt, weitergenutzt werden ohne dass man auf die Vorteile aktueller Betriebssysteme verzichten muss. Diese Applikationen werden in der VM-Box ausgeführt; die geschilderten Performancenachteile gegenüber einer nativen Benutzung fallen aufgrund des Alters der Software nicht ins Gewicht.

DOS, Windows 3.1 oder 95, alte Linux-Installationen können auf einer einzigen Maschine zusammengefasst werden und so Software-Beratern oder Hotlines bequemen Zugriff auf vergangene Welten verschaffen. Diese Betriebssysteme sollten allein aus Sicherheitsgründen nicht stand-alone in einem Netzwerk laufen, da wichtige Sicherheitspatches und Updates nicht verfügbar sind. Gleichzeitig war die Netzeinbindung zumindest einiger genannter Kandidaten eher rudimentär, welches sich über den Umweg von VMware in Verbindung mit dem X11- oder VNC-Protokoll aufheben lässt.

Ein ähnliches Szenario bietet die Migration von Arbeitsplätzen von einem Betriebssystem in ein anderes. Möchte man aufgrund der Lizenzkostenentwicklung von Microsoft-Betriebssystemen am Arbeitsplatz wegkommen, kann ein schrittweiser Umstieg mittels Umweg über VMware geführt werden. Das vormals installierte OS wird weiterhin auf der Maschine ausgeführt, nun jedoch als Gastbetriebssystem. Der Anpassungsaufwand wird nicht in die Migration von z.B. Windows 98 auf Windows XP investiert, sondern fließt in die Realisierung eines Linux-Desktop. Wesentliche Kosteneinsparungen ergeben sich auf die Lizenz des Betriebssystems nicht sofort, können jedoch bezogen auf die Applikationen und spätere Updates erheblich werden.

Betriebssysteme, welche einen sehr hohen Betreuungsaufwand erfordern, wie Windows 95, 98, ME, lassen sich durch VMware absichern. Bootet der Benutzer, der auf diesen Consumer-OS automatisch Systemadministrator ist, von einem nonpersistenten Image, sind fatale Modifikationen nur für eine Sitzung gültig. Dieses betrifft das versehentliche Löschen wichtiger Systemdateien, die ”Installationen” von Viren und Backdoors, oder die Performance ruinierende, bzw. das Netzwerk belastende Gimmicks wie aufwändige Bildschirmschoner.

Weitere Beispiele sind konstante Umgebungen für Software-Tester und technische Unterstützung als auch Software-Demonstrationen. Wenn eine Softwareentwicklung auf mehreren Plattformen erfolgt, müssen diese nun nicht getrennt vorgehalten werden, fatale Abstürze wirken sich nicht negativ auf nonpersistente Betriebssysteme aus. Ähnliches gilt für Webentwicklunger, die verschiedene Browser in unterschiedlichen Umgebungen testen wollen.

Die SLX-Client-Installation bringt eine weitere Anwendung für eine VM-Box mit sich: Für eine bequeme Einrichtung der Software für die Clients bei getrennten Dateisystemen bietet sich die Benutzung von VMware an. So kann die Installation und das Software-Update weiterhin bequem auf dem Server erfolgen ohne dafür eine eigene Hardware für einen Speziel-Client aufzustellen.

10.1.2 VMware diskless - spezielle Probleme

Zur Virtualisierung eines Rechners benötigt VMware einige, teilweise auch weniger offensichtliche, Ressourcen. So wird neben dem Speicher, der dem Client zur Verfügung steht, RAM für die Applikation selbst angefordert. Zusätzlich legt VMware wärend des Betriebes eine Reihe Verzeichnisse und Dateien an. Dazu gehören nicht nur die Unterverzeichnisse für Gastinstallationen und .vmware im Home-Verzeichnis des Benutzers, sondern auch Platz für spezielle VMware Dateien, welche nur während des VMware-Betriebs existieren, bzw. zu Beginn angelegt werden. Diese werden ohne besondere Anpassung von VMware in /tmp gesichert. Es existiert eine Möglichkeit ein anderes Verzeichnis zu definieren, und damit zumindest einen Großteil der Dateien, in einem anderen Verzeichnis zu speichern. Zurück bleiben lediglich einige Log-Dateien. Einer der Gründe wieso man eventuell nicht möchte, dass Dateien unter /tmp gespeichert werden ist z.B., dass auf SLX-Clients mit einiger Wahrscheinlichkeit dieses Verzeichnis in der Ramdisk liegt. Bei SLX-Clients gibt es drei Möglichkeiten auf welchem Medium das Verzeichnis /tmp liegen kann¹. Problematisch ist hierbei die Datei *.vmem. Diese Datei wird beim Start von VMware angelegt und hat die Größe, die dem RAM der Virtuellen Maschine entspricht. Allerdings wird diese nur als Auslagerungsdatei verwendet. Wird also diese Datei auch noch im RAM gespeichert, bleibt eventuell kaum Speicher mehr für andere Anwendungen übrig. Das Gast-OS ist daher instabil, und endet abrupt mit der Fehlermeldung, dass zu wenig RAM verfügbar ist. Die Auslagerungsdatei wird aber nur in bestimmten Fällen verwendet und liegt ansonsten brach herum. Ein solcher Fall ist Suspend. Da ein Suspend in einem Diskless-System unwahrscheinlich, bzw. auch nicht wirklich wünschenswert ist, wird die Datei nicht wirklich gebraucht. Leider kann man sie, soweit die Autoren wissen, nicht deaktivieren. Man kann aber über die Variable tmpDirectory in der Datei preferences steuern, wo die Datei *.vmem angelegt werden soll.

Es gibt einige Variablen, mit denen sich steuern läßt, wo temporäre oder andere teilweise sehr große Dateien angelegt werden:

Die Lage der verschiedenen Dateien legt man soweit möglich per Skript fest, wenn VMware automatisch gestartet werden soll.

10.1.3 VMware diskless einrichten

Wie dargestellt erfordert der Betrieb von VMware auf Linux Diskless Clients einige Anpassungen, die vom klassischen Normalbetrieb abweichen. Einige Einstellungen können nur durch den Systemadministrator vorgenommen werden, andere Vorgänge führt üblicherweise der Benutzer mit normalen Privilegien aus.

In der Initial Ramdisk sorgen die Skripten servconfig bzw. vmware-prep für die erforderlichen Anpassungen und Einstellungen die privilegierten Zugriff benötigen, alles andere erledigt runvmware ”on demand”.

Vorgänge in der Stage3 servconfig

Im InitialRamFS ist servconfig für die Einbindung und Konfiguration der Clients zuständig. Hier erfolgt auch das eventuelle Einbinden des VMware-Verzeichnisses mit den Virtuellen Maschinen, den verschiedenen Konfigurationsdateien und runvmware. Falls die Virtuellen Maschinen direkt unter /usr/share/vmware im Client-Betreibssystem liegen, wird nur ein Link angelegt. Damit ist dann auch die Kompatibilität mit der alten Version 3 gewährleistet.

Derzeit ist ein NFS-Mount nach /var/lib/vmware Standard. Die Information, woher die Daten eingebunden werden sollen, also Server-IP und Unterverzeichnis (angegeben als URI), werden aus der Datei machine-setup² ausgelesen.

Da nun alle externen Ordner und Dateien verfügbar sind, müssen noch ein paar Anpassungen getroffen werden. Zum einen muss das Skript runvmware nach /var/X11R6/bin kopiert werden, damit es direkt, also ohne die Angabe des vollen Pfades, ausgeführt werden kann. Zum anderen müssen noch Verzeichnisse angelegt und Rechte angepasst werden, da z.B. das /var Verzeichnis bei einem SLX-Client nur zum Teil übertragen wird.

Ist auch dies erfolgt, generiert servconfig ein Skript namens desktop-sessions in /var/X11R/bin, welches dazu dient Virtuelle Maschinen direkt aus KDM / GDM zu starten. Hierzu werden alle Virtuellen Maschinen auf dieses Skript verlinkt. Das Skript erkennt dadurch wie es aufgerufen wurde und kann dann die entsprechende Virtuelle Maschine über runvmware starten. Das Problem besteht aber oft darin, dass die Benutzer sehr selten das Sessions-Menü verwenden. Es wird leicht übersehen und hat wenig Aussagekraft, besonders für einen Normalbenutzer der zudem aus der Windows-Welt kommt. Hier kommen die Schwächen von KDM / GDM zutage, die nicht für Szenarien mit großem Session-Angebot geeignet sind. Deshalb gibt es in der neuen OpenSLX-Version eine Standard-Session, welche eine Auswahl mit Linux Desktop-Umgebungen und Virtuellen Maschinen anzeigt. Jeder Benutzer wird, wenn er keine Sitzung auswählt, zu diesem Menü geführt, wo er dann seine Auswahl treffen kann. Diese Konfigurationsdatei wird ebanfalls in servconfig geschrieben und ein Link auf desktop-sessions angelegt. Eine weiteres Menü welches auf diese Weise erstellt wird ist das Virtuelle-Maschinen-Menü. Es wird nur dann angelegt, wenn nicht alle Virtuellen Maschinen direkt unter KDM / GDM angezeigt werden sollen. Wird diese Sitzung ausgewählt, wird ein Auswahlmenü mit allen verfügbaren Virtuellen Maschinen angezeigt. Wenn viele Virtuelle Maschinen existieren, ist es für die Übersichtlichkeit nicht sinnvoll alle Virtuellen Maschinen in das Sessions-Menü zu packen.

Wie dies gesteuert werden kann ist im Abschnitt runvmwarebla beschrieben.

vmware-prep

Nachdem servconfig schon einige Vorarbeit geleistet hat, kümmert sich vmware-prep sozusagen nur noch um den Feinschliff. Eine seiner Aufgaben besteht aus dem Anlegen der VMware-Network-Devices /dev/vmnet* (wobei * für 0-9 steht). Eine andere aus dem Einbinden des USBFS, da dieses oft erst beim Auslösen eines entsprechenden Ereignisses eingebunden wird. Da VMware kein solches Ereignis auslöst, ist dieses Vorgehen nötig. Damit wird gewährleistet, dass der USB-Anschluss auch innerhalb einer Virtuellen Maschine funktioniert.

Eine für den Betrieb von VMware nicht zwingend notwendige, aber sehr nützliche Funktion, ist das virtuelle Floppy B. Es wird über dieses Skript generiert und kann über runvmware mit Daten befüllt werden. Hierzu wird ein 1,44 MB großes, FAT-formatiertes Image nach /etc/vmware/loopimg kopiert und dort als /etc/vmware/fd-loop eingebunden. Das hat den Vorteil, dass man über dieses Floppy-Image leicht Konfigurationsdateien an eine Virtuelle Maschine übergeben kann, bevor noch das Netzwerk Verfügbar ist. Das ist dann nötig, wenn variable Daten übertragen werden müssen, die während des Betriebssystemstarts benötigt werden.

runvmware

runvmware ist ein Shell-Skript welches mit normalen Userprivilegien aufgerufen werden kann. Es generiert eine gültige VMware-Startdatei, die VMware-Benutzer auch unter der Endung .vmx kennen, und führt diese zum Schluss aus. Davor muss aber diese Datei mit gültigen Werten befüllt werden. Diese richten sich nach der jeweiligen Hardware. runvmware kann die nötigen Hardware-Informationen automatisch herausfinden, das ist der Standard-Fall, oder einige Informationen über die Kommadozeile übermittelt bekommen. Die einzige Inforamtion die immer übergeben werden muss ist die, welche Virtuelle Maschine gestartet werden muss. Dazu aber später mehr.

Zuerst aber muss noch geklärt werden wie runvmware funktioniert. Zu Beginn liest runvmware die über die Kommandozeile übermittelten Werte und gibt einen Fehler aus, falls es eine Option nicht kennt. Diese Werte werden in Variablen gespeichert und ersetzen Standardwerte, oder von runvmware später ermittelte Werte. Auf die Kommandozeilenoptionen wird später eingegangen, zunächst wird der generelle Ablauf erklärt. Sind die Kommandozeilenoptionen gesichert, werden zwei wichtige Ordner erstellt, welche für den weiteren Betrieb notwendig sind. Zum einen ist dies der Ordner .vmware im Home-Verzeichnis des Benutzers. Hier landen später die Datei preferences, dazu aber später mehr, und das Bios der Virtuellen Maschine, sowie eventuell eine Lizenz, welche zum Starten einer virtuellen Maschine über VMware Workstation benötigt wird. Da der VMPlayer keine Lizenz benötigt, entfällt dieser Schritt hier. Zum anderen den Ordner /tmp/userid, wobei userid für die von System vergebenen Benutzernamen steht. In diesen Ordner wird später die VMware-Startdatei runvmware.conf gespeichert, sowie diverse Log-Dateien und die Speicher-Auslagerungsdatei *.vmem. Ersteres erfolgt durch runvmware, die Log-Dateien und *.vmem werden durch VMware generiert.

Ist dies Erfolgt fängt das Skript mit der Hardwareerkennung an. Zunächst liest runvmware die Client-MAC-Adresse. Damit die Virtuelle Maschine im Bridged-Modus eine IP-Adresse, z.B. über DHCP, zugewiesen bekommen kann, muss die virtuelle Netzwerkkarte eine MAC-Adresse, die sich zu der der Client-Netzwerkkarte unterscheidet, bekommen. Dazu werden die ersten vier Doppelstellen der MAC-Adresse vorgegeben, nur die letzten zwei Dopppelstellen werden von der echten Netzwerkkarte übernommen. Ein Beispiel für den vorgegebenen Teil wäre: 01:23:45:67, für den aus der Netzwerkkarte bezogenen Teil: 89:ab. Zusammengesetzt ergibt es eine MAC-Adresse die mit großer Wahrscheinlichkeit noch nicht verwendet wird: 01:23:45:67:89:ab. Der nächste Schritt ist die Zuteilung von Hauptspeicher an die Virtuelle Maschine. Damit wird aber nur die Obergrenze für die Virtuelle Maschine festgelegt. Der Speicher ist auch nicht fest reserviert, das Wirtssystem kann also den gesamten Speicher verwenden, während der Virtuellen Maschine nur bis zur angegebenen Menge Speicher zusteht. Somit läuft der Wirt auch noch stabil, wenn die Virtuelle Maschine ihren gesamten Speicher verwendet. Wird der Hauptspeicher nicht über die Kommandozeile angegeben, wird er von runvmware auf 66% des gesamten Speichers eingestellt. Sind CD-/DVD-ROM-Laufwerke vorhanden, werden sie auch von runvmware eingebunden. Es werden aber maximal zwei Laufwerke eingebunden. Bei Floppies sieht es anders aus. Floppy B ist ein FAT-formatiertes Floppy-Image welches zum Austausch von Daten zwischen Wirt und Virtuelle Maschine dient³. Floppy A wird erkannt sobald der Floppy-Controller aktiviert ist. Das kann zur folge haben, dass ein Floppy erkannt wird, ohne dass wirklich eins eingebaut ist. Um dies zu verhindern, wird geraten im Bios den Floppy-Controller zu deaktivieren. Es kann maximal ein echtes Floppy eingebunden werden. Beide Floppies werden nie automatisch eingebunden, dies muss über die Kommandozeile von runvmware passieren. Als letztes wird die Auflösung der Virtuellen Maschine eingestellt. Dies ist vor allem dann erforderlich, wenn diese in inhomogenen Umfeldern, eingesetzt werden. Dann kann schonmal vorkommen, dass die in der Virtuellen Maschine gespeicherte Auflösung, auf dem einen oder anderen Wirt nicht angezeigt werden kann, da dieser in einer kleineren Auflösung betrieben wird. VMware verlässt dann den Vollbildmodus und bringt eine Nachricht, dass die Auflösung manuell heruntergesetzt werden muss. Das ist natürlich nicht wünschenswert und verunsichert die Anwender. Deshalb überprüft runvmware die Auflösung eines Wirts und speichert diese als Maximum. Wird hier keine Information über die Kommandozeile übermittelt, wird sie Virtuelle Maschine mit der als Maximum gespeicherten Auflösung gestartet.

Ist die Hardwareerkennung abgeschlossen, wird die Virtuelle Maschine ausgewählt, welche gestartet werden soll. Dies ist die einzige Information, die über die Kommandozeile übergeben werden muss. Wenn die Virtuelle Maschine bekannt ist, wird sie auf die richtigen Lese- und Schreibrechte hin überprüft. Es wird der Titel des Fensters und der Bertiebssystemtyp gesetzt. Der Betriebssystemtyp wird entweder über die Kommandozeile übergeben, oder er kann aus der Datei /var/lib/vmware/templ/ostype ausgelesen werden. Diese muss vorher eventuell angepasst werden. Wenn keine passenden Informatioen gefunden werden können, wird der Typ auf ”other” gesetzt. Die Datei könnte folgendermaßen aussehen:

Genaueres kann nicht über diese Variable gesagt werden, das sich die Firma die hinter VMware steht, dazu nicht äußern möchte. Es wurde nur mitgeteilt, dass es zu einem instabilen System führen kann, wenn diese Variable falsch belegt wird. Die Variable ist für bestimmte Anpassungen verantwortlich, die der Meinung der Autoren nach, besonders bei speziellen Betriebsysstemen relevant sein dürften. Bei einem Start von Windows XP mit dem Typ ”other”, konnten keine Besonderheiten festgestellt werden. Wahrscheinlich wird diese Variable auch für die Installation der VMware-Tools⁴ erforderlich sein. Als letzter Punkt wird noch die Lautstärke angepasst, damit die Virtuelle Maschine über Ton verfügt.

preferences: Nun müssen nur noch die Konfigurationsdateien geschrieben werden. Dazu werden sie aber noch vorher mit den ermittelten Informationen bestückt. Die Datei preferences wird in den Ordner .vmware im Home-Verzeichnis des Benutzers gespeichert, da sich hier von VMware erwartet wird.

Wie man in diesem Beispiel sieht, müssen nur die Pfade der Konfigurationsdateien angepasst werden, bzw. die Variable tmpDirectory. Diese Variable ist besonders wichtig, da sie den Speicherort für die Speicherauslagerungsdatei *.vmem bestimmt. Die Variablen hints.hideAll und pref.tip.startup deaktivieren zum Beispiel lästige VMware-Pop-Up-Informationen. Mit pref.vmplayer.fullscreen.autohide verschwindet die Menüleiste des VMPlayer im Vollbildmodus und erscheint erst wieder, wenn die Maus an den oberen Bildrand gefahren wird. Diese Option gilt aber nur für den VMPlayer, wie man auch am Namen *.vmplayer.* erkennen kann. Mit pref.hotkey.shift wird die Taste ”Shift” zu den Hotkeys hinzugefügt. Um jetzt den Vollbildmodus verlassen zu können, muss man die Tasten ”Alt” + ” Strg” + ”Shift” drücken, bzw. die Tasten ”Alt” + ” Strg” + ”Shift” + ”Enter” um wieder in den Vollbildmodus zu gelangen. Alternativ kann die Taste ”F11” für den Vollbildmodus verwendet werden, vorher muss aber das Fenster ausgewählt werden. Die Variablen pref.eula.* sind hingegen recht neu. Hier ermittelt runvmware jeweils die build-number von VMware und VMPlayer und speichert diese in die entsprechenden Variablen. Dieses Vorgehen war nötig geworden, nachdem in der neuesten VMware-Version die build-number in die preferences eingertagen und immer beim Start überprüft wird. Stimmt diese nicht mit der build-number von VMware, bzw. VMPlayer überein, wird der EULA-Text angezeigt und die Virtuelle Maschine verlässt den Vollbildmodus.

runvmware.conf: Die Startdatei der Virtuellen Maschine heisst im Projekt runvmware.conf und wird in /tmp/userid gespeichert. Sie entspricht den von VMware .vmx benannten Startdateien. Aufgrund ihrer automatischen Generierung durch runvmware, wurde sie vom Projekt runvmware.conf genannt.

In der Datei finden alle hardwarespezifischen Einstellungen statt. Die Reihenfolge der Einträge ist nicht vorgeschrieben, jedoch erhält man einen besseren Überblick bei geeigneter Gruppierung der Einträge. Im ersten Abschnitt identity werden die VMware-spezifischen Variablen *.version definiert, sowie der Name und Typ des Gastbetriebssystems⁵. Für dieses System wird dann noch die RAM-Grenze und die Anzahl der CPU angegeben. Im zweiten Abschnitt ide-disks, wird das Gastbetreibssystem-Image und maximal 2 CD-, DVD-ROM-Laufwerke definiert. Diese werden über einen virtuellen IDE-Bus angesteuert. Diese Lösung wäre auch mit einem virtuellen SCSI-Bus denkbar, aber das Projekt hat sich für die IDE-Lösung entschieden. Hierzu müsste aber auch das Gastbetriebssystem-Image auf einer virtuellen SCSI-Platte gesichert werden. Deswegen wird im nachfolgendem Abschnitt scsi-disks die Verwendung eines virtuellen SCSI-Controllers deaktiviert. Wie schon erwähnt ist Floppy A das reale Diskettenlaufwerk und Floppy B das FAT-formatierte Floppy-Image. Im Abschnitt floppies werden diese Einstellungen festgelegt. Im Abschnit nics wird die virtuelle Netzwerkkarte eingestellt. Das Projekt verwendet den Bridge-Modus. Der Netzwerkkarte wird dann noch die von runvmware definierte MAC-Adresse zugewiesen. Die folgenden drei Abschnitte sound, usb, ports, aktivieren den USB-Controller und die Soundausgabe, bzw. deaktivieren den seriellen und parallelen Port. Die Variable usb.generic.autoconnect bewirkt das automatische Einbinden von USB-Geräten. In nächsten Abschnitt shared folders wird das Home-Verzeichnis der Virtuellen Maschine zur Verfügung gestellt. Über die VMware-Tools kann dann dieses Verzeichnis über das Netzwerk eingebunden werden.⁶. Der letzte Abschnitt misc deaktiviert zum Beispiel die Anzeige der *.vmem-Dateien indem die Variable mainMem.useNamedFile auf ”FALSE” gesetzt wird. Auch werden Snapshots deaktiviert, diese sind auf einem SLX-Client nicht sinvoll. Die Variablen svga.* begrenzen die maximale Auflösung der Virtuellen Maschine. Wie bereits erwähnt ist dies wichtig bei inhomogenen Umgebungen, in denen nicht alle Wirte die gleiche Grafik-Auflösung besitzen. Mit diesen Variablen kann runvmware die Auflösung des Gastes herunter setzen, wenn es bemerkt, dass ein Client nicht die in der Virtuellen Maschine gespeicherte Auflösung darstellen kann.

Sind die Dateien an ihrem Platz, kopiert runvmware noch ein einheitliches VMware-Bios nach .vmware im Benuter-Home-Verzeichnis. Sind VMware Workstation und VMPlayer installiert, wird, wenn nicht anders über die Kommandozeile angegeben, VMPlayer gestartet. Ansonsten wird die jeweils installierte Applikation gestartet.

Kommandozeilenoptionen: Nachdem ein grober Einblick über die Funktionsweise von runvmware gegeben wurde, widmet sich dieser Abschnitt den Einflussmöglichkeiten der Benutzer, Administratoren sowie Endnutzer, auf das Skript. Die Einflussnahme erfolgt entweder direkt über die Kommandozeile, oder über ASCII-Dateien. Wenn man die Hilfe von runvmware mit

aufruft, wird eine kurze Hilfe angezeigt.

Der Endnutzer wird sich voraussichtlich nie mit diesen Optionen beschäftigen müssen, da die Virtuellen Maschinen auch bequem über KDM gestartet werden können. Wenn dies jedoch nicht der Fall sein sollte, wäre die Option

als eine der Wichtigsten zu nennen. Diese ruft ein interaktives Menü mit allen Virtuellen Maschinen als Auswahl auf. Hierzu wird das Programm Xdialog benötigt, welches meist erst installiert werden muss. Damit eine Virtuelle Maschine in diesem Menü auftaucht, bedarf es noch einer Informationsdatei. Diese wurde den *.desktop-Dateien nachempfunden, welche auch Desktopmanagern als Sessiondateien dienen. Diese Entscheidung wurde getroffen, um auch Virtuelle Maschinen in einem Desktopmanager-Auswahlmenü anbieten zu können. Diese Datei könnte folgendermaßen aussehen:

Hierbei ist vmware-image der Name einer Virtuellen Maschine ohne die Endung ’.vmdk’, z.B. ’winxppro-office’. Über die Variable Name wird der Name des Menüpunkts definiert, über Comment der zusätzliche Info-Text.

Wird die Virtuelle Maschine nicht über diese Option gewählt, muss dies über

erfolgen. Wenn die Virtuelle Maschine nicht über KDM gestartet wird, muss sie über eine dieser beiden Optionen gewählt werden. Diese Optionen sind die Einzigen, welche immer angegeben werden müssen, der Rest wird dann automatisch über runvmware erledigt. Wiederum ist image-name der Namen der Virtuellen Maschine ohne Endung.

Ein weiterer weg eine Virtuelle Maschine zu starten ist über

Diese Option ist eigentlich nur für Starts über einen Desktopmanager interessant. Wird vm angegeben, werden alle Virtuellen Maschinen zur Auswahl angeboten. Diese Option entspricht eigentlich der Option -i für den interaktiven Modus, es werden lediglich Hintergrund und Fensterdekoration angepasst. Über all werden zusätzlich zu den Virtuellen Maschinen, noch alle Fenstermanager zur Auswahl angeboten. Diese Option startet die bereits erwähnte Standard-Session, falls der Benutzer nicht eine Sitzung im Sessions-Menü auswählt. Wird dann eine Virtuelle Maschine gewählt, wird das Skript desktop-sessions über einen Link gestartet⁷. Das Skript erkennt dadurch wie es aufgerufen wurde, und kann dann runvmware mit den erforderlichen Optionen starten.

Falls aus bestimmten Gründen der Name der Virtuellen Maschine zu lang ist, bzw. nicht als Kommandozeilenparameter übergeben, oder nicht in einer *.desktop-Datei verwendet werden kann, können Aliase verwendet werden.

Über diese Option, gepaart mit dem Alias, kann dann die eigentliche Virtuelle Maschine gestartet werden. Eine Alias-Datei kann wie folgt aussehen.

Ein Aufruf von

würde in diesem Beispiel die Virtuelle Maschine winxppro-kursversion.vmdk starten. Mit

können zudem die definierten Aliase ausgegeben werden.

Das reale Diskettenlaufwerk A und Floppy B, das FAT-formatierte Floppy-Image, können über die Optionen

eingebunden werden. Das Floppy-Image wird unter /etc/vmware/fd-loop eingebunden. Konfigurationsdateinen müssen in dieses Verzeichnis geschrieben werden.

Mit

kann die maximale Auflösung des Gastbetriebssystems, in der Form 1024x768, festgelegt werden. Dieser Wert muss aber zwischen der aktuellen Auflösung des Wirts und 640x480 liegen. Ist dies nicht der Fall gibt runvmware eine Fehlermeldung aus. Wird diese Option ausgelassen, wählt runvmware automatisch die Auflösung des Wirts.

Ähnlich verhält es sich mit dem RAM. Über

kann der RAM der Virtuellen Maschine justiert werden. Wird nur eine Zahl angegeben, behandelt runvmware diese als Prozentangabe. Mögliche Werte wären dann 0 - 100. Die Buchstaben ’m’, ’M’, bzw. ’g’, ’G’, stehen für Megabyte, bzw. Gigabyte. Hier muss darauf geachtet werden, dass die Angaben nicht den tatsächlich verfügbaren RAM übersteigen. Zusätzlich kann über ’h’, ’H’ der RAM dem Wirt zugewiesen werden. runvmware subtrahiert in diesem Fall den übermittelten Wert vom insgesamt verfügbaren RAM. Sollte der Wert nicht durch vier teilbar sein, korrigiert runvmware dies, ausserdem muss noch mindestens 128 MB RAM für Wirt und Virtuelle Maschine übrig bleiben. Wird die Option ausgelassen, wird der Virtuellen Maschine, die Obergrenze von 66% des RAM, von runvmware zugewiesen.

Befindet sich die Virtuelle Maschine nicht unter /var/lib/vmware kann über den Parameter

der Ordner angegeben werden. In diesem Zusammenhang ist vielleicht noch die Option

von Interesse. Wenn die Virtuelle Maschine an einem Ort liegt, an dem der Benutzer Schreibrechte besitzt, und die Virtuelle Maschine auch nicht schreibgeschützt ist, kann sie mit dieser Option auf independent-persistent gesetzt werden. In diesem Fall werden alle Einstellungen die vorgenommen werden in der Virtuellen Maschine gespeichert. Dies ist vor allem dann interessant, wenn mal eine Virtuelle Maschine angepasst werden muss.

Muss ein Betriebssystemtyp angegeben werden, z.B. zum Testen, kann dies auch ohne die Anpassung der Datei ostype erfolgen. Die Option hierzu lautet:

Hierzu muss erst einmal der Name des Betriebssystemtyps herausgefunden werden.

Müssen noch zusätzliche Konfigurationen erfolgen, wie zum Beispiel eine Windows XP Startkonfiguration, kann mit dem Parameter

ein zusätzliches Teil-Skript hinzugefügt werden. Dieses wird kurz vor Ende von runvmware ausgeführt, kann also auch die von runvmware gespeicherten Variablen verwenden. Hierzu muss noch beachtet werden, dass der Code nur hinzugefügt und nicht ausgeführt wird. Es darf also nicht noch einmal ’#!/bin/sh’ oder ähnliches auftreten. Im Abschnitt wird ein solcher Vorgehen erklärt.

Wie bereits erwähnt wir im Falle einer Installation von VMware Workstation mit VMPlayer, der VMPlayer von runvmware gestartet, da hierzu keine Lizenz notwendig ist. Möchte man jedoch VMware Workstation startet übergibt man dies mit

an runvmware. program bezeichnet hier den Namen der ausführbaren Datei, z.B. vmware, vmplayer.

Um die Endbenutzer nicht zu verwirren werden die Virtuellen Maschinen immer automatisch im Vollbild gestartet. Auch wird VMware beendet, wenn eine Virtuelle Maschine beendet wird. Doch manchmal möchte man die Virtuelle Maschine danach bearbeiten, oder man möchte noch andere Fenster geöffnet haben. Dazu wurden folgende Optionen eingeführt:

Die letzten beiden Optionen funktionieren nur mit VMware Workstation. Mit --edit kann die Virtuelle Maschine zur weiteren Konfiguration geöffnet werden, zum Starten muss dann noch ein Knopf gedrückt werden.

Funktioniert runvmware mal nicht wie gewünscht, kann noch der Debug-Modus aktiviert werden. Der Level 1 schreibt nur die Ausgaben zusätzlich in eine Datei. Dies kann vor allem dann wichtig sein, wenn runvmware über einen Displaymanager gestartet wird, da hier keine Ausgabe erfolgt. Derzeit existiert noch ein Level 2 der zusätzlich noch ein wenig mehr Information liefert. Diese Option aktiviert man jeweils mit:

Die Log-Dateien werden unterhalb von /tmp/userid geschrieben.

Die restlichen Optionen sprechen für sich und benötigen keines zusätzlichen Kommentars.

Da manchmal bestimmte Optionen obligatorisch sind, und keinem Endnutzer zugemutet werden darf diese jedes mal einzutippen, wurde die Datei defaults eingeführt. Diese Datei sollte alle obligatorischen Parameter enthalten. Optionen die über die Kommandozeile übergeben werden, überschreiben die Optionen in dieser Datei. Ein Beispiel:

Auf dieses Beispiel wird im Abschnitt noch eingegangen.

10.1.4 Windows 98 im OpenSLX-Umfeld

Legt man nicht besonderen Wert auf bestimmte Features von Windows XP kann man mit geeigneten Einschränkungen mit Windows 98 noch sehr gut arbeiten. Aus einem Betriebssytem, welches als Admins-Horror unter den Gesichtspunkten einer Stand-Alone-Installation zu bezeichnen ist, wird ein benutzbarer Desktop. Dieses gelingt, indem Windows 98 innerhalb VMware auf Basis von SLX-Clients betrieben wird. Optimalerweise verwenden alle Clients mit einem recht ähnlichen Anwendungsprofil, wie Kursräume oder Verwaltungen, ein einziges gemeinsames Image, welches über einen leistungsfähigen NFS-Server bereitgestellt wird.

Damit sich die Clients dabei nicht ins Gehege kommen, sind einige Schritte notwendig: Zum einen darf kein Client das gemeinsame Image verändern dürfen, also wird es nonpersistent in einem ReadOnly-Bereich des Dateisystems bereitgestellt. Zum anderen müssen sich die Client-Images in einigen zentralen Parametern zwingend Unterscheiden: Der Windows-Name der Maschine und die IP-Konfiguration zählen hierzu. Dieses geschieht entweder über das Laden von Registry-Einträgen beim Bootvorgang oder dynamische IP-Zuweisung per DHCP. Damit keine Locking-Probleme für das gemeinsam genutzte Image entstehen, legt jeder Client für sich einen Link auf das Image an. Im gemeinsamen Verzeichnis mit diesem Link wird das Lockfile generiert.

Das Einlesen der Registry-Einträge muss zu einem frühen Zeitpunkt geschehen und wird deshalb aus der autoexec.bat über den Umweg der run.bat angestossen. Auf diese Weise muss im gemeinsam genutzten Festplattenimage eine einzige Zeile in die autoexec.bat eingetragen werden, alles evtl. zwischen den verschiedenen virtuellen Hosts Variable geschieht über die run.bat. Es gibt drei Gruppen von Registry-Einträgen, die aus letzterer heraus erfolgen:

• home.reg sorgt dafür, dass das Homeverzeichnis des sich anmeldenden Benutzers automatisch (nach Eingabe seines Passworts bei der Anmeldung) eingebunden wird. Damit steht dem Benutzer nichtflüchtiger Speicherplatz im virtuellen Windows 98-Rechner über ein Netzlaufwerk zur Verfügung. ”SMBSERVER”, ”USER” und der Laufwerksbuchstabe können mittels dieser Datei festgelegt werden:

  SLX-Client:~$ cat /var/lib/vmware/templ/win98config   # this is an include file for runvmware   #   # create Windows 98 config files     # sync is needed to ensure that data is really written to virtual disk   sync   echo -e "\tREGEDIT4\r     [HKEY_CURRENT_USER\Networ\Persistent\H]\r   \"RemotePath\"=\"\\\\192.168.1.2\\${USER}\"\r   \"UserName\"=\"${USER}\"\r   \"ProviderName\"=\"Microsoft Network\"\r" \   > /etc/vmware/fd-loop/home.reg

• logon.reg trägt den Benutzer in die Windows-Anmeldemaske ein, der gerade die virtuelle Maschine ausführt. Diese Information wird der USER-Variablen entnommen.

  echo -e "\tREGEDIT4\r     [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]\r   \"ComputerName\"=\"${hostname}\"\r   \"Workgroup\"=\"${workgroup}\"\r   \"Comment\"=\"${comment}\"\r   \"StaticVxD\"=\"vnetsup.vxd\"\r   \"Start\"=hex:00\r   \"NetClean\"=hex:01\r     [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\\\   ComputerName]\r   \"ComputerName\"=\"${hostname}\"\r" \   > /etc/vmware/fd-loop/rechner.reg

• rechner.reg konfiguriert das ”Windows-Netzwerk”: Festgelegt werden kann der Windows-Name der virtuellen Maschine, der Name der Arbeitsgruppe und ein Kommentar.

  echo -e "\tREGEDIT4\r     [HKEY_LOCAL_MACHINE\Network\Logon]\r   \"username\"=\"${USER}\"\r   \"PrimaryProvider\"=\"Microsoft Network\"\r   \"LMLogon\"=hex:00,00,00,00\r" \   > /etc/vmware/fd-loop/logon.reg   sync

10.1.5 Windows XP im OpenSLX-Umfeld

Leider entfällt diese einfache und elegante Möglichkeit für die ”professionellen” Windowsversionen der NT- und XP-Linie. Hier sind einige Anstrengungen notwendig, um die Registry rechtzeitig mit den benötigten Einträgen zu befüllen.

Die IP-Konfiguration geschieht am besten mittels DHCP, das bereits zur Einrichtung der Diskless Clients eingesetzt wird. Um jede virtuelle Maschine eindeutig benennen zu können, sorgt das runvmware-Skript dafür, dass jede Maschine einige eindeutige MAC-Adresse erhält, die sich aus vier Stellen für VMware und den zwei letzten Stellen der realen MAC-Adresse des Clients zusammensetzt. Zur Abgrenzung von der realen Hardware bekommt der Windowsname an den Client-Hostnamen noch ein ”-vm” angehängt.

Alle persönlichen Einstellungen müssen die Benutzer dieser Lösung in ihrem Netzlaufwerk oder auf Diskette vornehmen. Weitergehende Konfigurationen wären durch das Managen von Profilen auf dem Samba-Server möglich, somit entfällt auch hier der Eingriffsgrund für Administratoren.

Gegenüber Windows 98 ist die Einrichtung des Windows Hostnamens unter XP deutlich schwieriger: Die DOS-Plattform zum einfachen Patchen der Registry, wie im letzten Abschnitt gezeigt, steht nicht zur Verfügung. Stattdessen muss in einer noch sehr eingeschränkten Umgebung ein Programm ausgeführt werden.

Das Rechenzentrum der Universität Freiburg verwendet deshalb bei Windows-XP-Installation kleines Programm welches das Problem eindeutiger Maschinennamen löst. Dieses liest aus einer beliebigen ASCII-Datei den Computernamen aus und trägt diesen in die Registry ein. Der Eintrag landet dann in

in den Attributen ComputerName und ActiveComputerName. Der Aufruf des Programms erfolgt durch einen Registry-Eintrag in

in das Attribut Boot Execute. Der Eintrag hierzu muss lauten:

Wobei bootpgm der Name des Programms ist und Datei_* die ASCII-Dateien in denen nach dem Computernamen gesucht werden soll. Vorher muss noch das Programm bootpgm.exe nach system32 im Windows-Root kopiert werden. Die Dateinamen sind Case Sensitive. Auch werden nur die ersten 500 Zeichen einer Datei eingelesen. Dies ist aber vollkommen ausreichend, auch reicht meist die Angabe nur einer Datei. Wenn ein DOS-Dateiname angegeben werden soll, muss es im Format

erfolgen. Das Format der Zeichenkette nach der gesucht wird muss folgende Struktur besitzen:

Hierbei bezeichnet ’w+’ den Computernamen.

Der weitere Maschinenstart des Windows XP erfolgt mit diesem Namen. Ein sonst fälliger Neustart nach einem Namenswechsel ist mit diesem Verfahren nicht notwendig. Für Einzelinstallationen, wie am Rechenzentrum für Kurs- und Schulungszwecke, ist dies kein Problem. Alle Rechner im Netz verwenden einen anderen Namen und kommen sich daher nicht in die Quere. Problematisch bis unmöglich ist in dieser Konstellation hingegen ein Domänenbeitritt oder die Mitgliedschaft in einem zentralen Active Directory.

10.1.6 Beispiel: Windows XP am RZ der Universität Freiburg

Um die Informationen, die in den letzen Abschnitten vermittelt wurden, besser zu verstehen, wird der Konfigurationsablauf eines Windows XP-Images am Rechenzentrum der Universität Freiburg erläutert. Im diesem Beispiel wird davon ausgegangen, dass bereits ein VMware Windows XP-Image existiert. Ist dies nicht der Fall muss dieser Schritt zuerst erfolgen.

Als erstes muss zunächst das Windows XP-Image gestartet werden und zwar im ’independent-persistent’-Modus. Hierzu kann auch runvmware mit der Option ’--persistent’ aufgerufen werden. Achtung, das Image sollte dafür an einem beschreibbaren Ort liegen! Ist das Image gestartet, sollte, falls nicht bereits geschehen, eine Administrator-Sitzung geöffnet werden. Unter ’Start’ –> ’Ausführen’, bzw. über die Konsole, startet man das Programm regedit. Unter

muss zum Attribut Boot Execute der Eintrag

hinzugefügt werden. Nach erfolgter Änderung speichert man und beendet das Programm. Anschliessend kopiert man das Programm bootpgm nach /windows/system32 und fährt dann das Gastsystem herunter.

Im zweiten Schritt erstellt man eine passende Textdatei, die von dem Programm bootpgm bei jedem Windows-Systemstart ausgelesen werden soll. Eine Beispieldatei, die auch im Rechenzentrum Anwendung findet ist winconfig. Diese kann überall gespeichert werden, es wird jedoch das Verzeichnis /var/lib/vmware/templ empfohlen, da es keine Eingriffe im Client-Betriebssystem erfordert. Damit diese Datei im SLX-Client unter /var/lib/vmware/templ auftaucht, sollte sie jedoch auf dem Server unter .../vmware/templ liegen.

Wie man sieht ist diese unabhängig von den Variablen die runvmware verwendet. Das muss nicht unbedingt sein, erfordert aber Kenntnis über die verwendeten Variablen innerhalb runvmware. In diesem Beispiel gibt es zusätzlich die Variable $USER. Sie ist nicht wirklich nötig, kann aber später für spezielle Dienste, wie Drucker-Login, etc..., verwendet werden. Diese Konfiguration wird auf das virtuelle Floppy-Image /etc/vmware/fd-loop geschrieben.

Im letzten Schritt muss runvmware nur noch diese Include-Datei einlesen und das virtuelle Floppy-Image einbinden, damit die Konfigurationdatei config.xml geschrieben werden kann. Damit dies auch für alle Benutzer gilt, empfiehlt es sich diese Parameter in der Datei defaults in /lib/vmware/templ zu sichern. Wie auch bei der Konfigurationsdatei winconfig, muss die Änderung auf dem Server passieren. Parameter die in dieser Datei eingetragen sind, werden bei jedem Start von runvmware ausgeführt.