Vorsicht - leider veraltet und so nicht nutzbar!
Virtual Workstation - Integration von runvmware-v2¶
Bitte Anpassen und mit Virtualisierung mergen!
"runvmware-v2" hatte zum Ziel das bisherige "runvmware" modularer zu gestallten. Bei der bisherigen Version war es nicht wirklich trivial möglich einzelnen Images z.B. via NAT anzubinden. "runvmware-v2" hat auch die Möglichkeit für verschiedene Umgebungen (wie z.B. Pools an Universitäten) verschiedene, teilweise aber auch gleiche, VMs zur Verfügung zu stellen. Auch wurde Wert auf eine einfache Erweiterbarkeit durch andere Virtuelle Maschinen wie VirtualBox gelegt.
"runvmware-v2" basiert auf einem Parser, der aus den XML Dateien der einzelnen VM's ausführbaren Skripte sowie Konfigurationsteile für das Auswahlmenü sowie bei Bedarf Dateien zur direkten Auswahl einer VM zusammenstellt.
Zur Struktur| ${vmdir}/menulist-creator | Der XML Parser, der mithilfe des Templates die Startskripte und sonstige Konfigurationsteile erstellt. Er muss aus dem Projektverzeichnis virtualization an diese Stelle kopiert werden. | |||
| ${vmdir}/$image.xml | Die Konfigurations des Images, am besten anhand des Beispiels im Unterordner templates (siehe weiter unten) anpassen und so nennen, wie das zugehörige *.vmdk heisst. | |||
| ${vmdir}/$image.vmdk | Das VMware Image selbst (nur IDE-Images verwenden) | |||
| ${vmdir}/$image.vbox | Das VirtualBox Image (noch nicht implementiert, siehe VirtualboxIntegration) | |||
| ${vmdir}/runscripts/$pool/*.vmware | Die einzelnen VMware Startskripte unterhalb der einzelnen Pools. Erstellt durch menulist-creator (Änderungen hierin gehen beim Neuaufruf verloren) | |||
| ${vmdir}/runscripts/$pool/*.vbox | Die einzelnen VirtualBox Startskripte, bisher noch nicht implementiert. Erstellt durch menulist-creator. | |||
| ${vmdir}/xdialog-files/$pool/*.xdialog | XDialog Einträge der einzelnen aktiven Virtuellen Maschinen. Erstellt durch menulist-creator | |||
| ${vmdir}/xdmsession/$pool/*.desktop | desktop Dateie für XDM (xdm muss auf true in der XML Datei sein). Erstellt durch menulist-creator | |||
| ${vmdir}/templates | Dieses Unterverzeichnis muss aus dem Projektverzeichnis virtualization analog zu menulist-creator an diese Stelle kopiert werden. | |||
| ${vmdir}/templates/runvmware-v2 | Template Skript, aus dem mittels menulist-creator und XML Dateien die Startskripte erstellt werden. Es werden nur ein paar wenige Einträge wie die der Netzwerkanbindung (NAT, Bridged) geändert. Hierin sind u.U. Anpassungen für den reinen Diskless-Betrieb notwendig. | |||
| ${vmdir}/templates/client-config.xml.default | Default VMWare Clientkonfiguration für die Windows VMs | |||
| ${vmdir}/templates/dhcpd.conf | DHCPD Konfiguration für VMware, wird beim Booten in Stage3 kopiert. Hierin Anpassungen für den an die Clients verteilten DNS machen. | |||
| ${vmdir}/templates/nat.conf | NAT Configuration für VMware, wird beim Booten des Systems in Stage3 kopiert | |||
| ${vmdir}/templates/nvram.5.0 | Eigenes nvram für unsere VMs, hat zum Ziel das auch noch ein zweites Floppylaufwerk für die Windows VMs verfügbar ist, über den die VM Nutzerdaten etc. erhält. | |||
| ${vmdir}/templates/fd.img | Das Floppy Image B:, nötig für Nutzerdaten (siehe auch nvram.5.0) | |||
| ${vmdir}/templates/xdialog.sh | Wichtigste XDialog Parameter. An diese Datei wird in Stage3 Information aus /usr/share/xsessions/*.desktop sowie die Vorbereiteten Dateien aus ${vmdir}/xdialog-files/$pool/*.xdialog angehängt. |
Ablauf in Stage3¶
0. Clientvmwareconfiguration, welches Devices anlegt etc. Via machine-setup: vmware="yes"
1. Erstellen eines Mountpoints (z.B. /mnt/var/lib/vmware/) und mounten des externe VMware-Pfades ${vmdir}
2. Erstellen von /mnt/var/run/vmware/ mit Permission 1777
3. Alle Einträge aus ${vmdir}/xdmsessions/$pool/*.desktop nach /mnt/etc/X11/sessions/ linken
4. Erstellen des Default desktops in /mnt/etc/X11/sessions/default.desktop, welcher den später erzeugtes xdialog.sh ausführt.
5. Kopieren der angepassten VMware dhcpd.conf und nat.conf nach vmnet8
6. Anlegen der xdialog.sh durch kopieren des Templates, parsen von /usr/share/xsessions/*.desktop und anhängen der ${vmdir}/xdialog-files/$pool/*.xdialog Dateien. Das ganze Serverseitig zu verwirklichen ist wegen /usr/share/xsessions/ nicht trivial.
Ablauf in Stage4¶
In Stage4 erhält man ein Auswahlmenü, via der in Stage3 angelegten xdialog.sh, mit den Linuxdesktops und angebotenen virtuellen Maschinen. Wählt man eine VM aus, so wird das entsprechende Runskript in ${vmdir}/runscripts/$pool ausgeführt. Dieses legt in /tmp/$USER/ sowie in $HOME/.vmware/ jeweils eine Konfigurationsdatei an und kopiert bzw. parst die benötigte Datei wie nvram sowie client-config.xml. Danach wird der vmplayer mit der in /tmp/$USER/ abgelegten Konfigurationsdatei gestartet.
Virtual Workstation - Integration von VMware (ältere Fassung)¶
Ab Version 4 wird davon ausgegangen, dass es auf dem OpenSLX-Server oder einer geeigneten weiteren Maschine ein Export gibt, in dem folgende Verzeichnisse und Dateien existieren (wo dieser Export auf dem Server angelegt wird und auf welche Art - NFS, NBD, ... - es exportiert wird, ist komplett egal):
image-01.vmdk image-02.vmdk image-03.vmdk desc desc/image-01.xml desc/image-02.xml desc/image-03.xml vmsessions vmsessions/inactive/image-03.desktop vmsessions/image-01.desktop vmsessions/image-02.desktop templ templ/preferences templ/licence.ws.5 templ/144-floppy.img templ/runvmware
Im Beispiel gibt es drei VMware-Images image-*.vmdk, wovon die ersten beiden aktiv sind und damit in der Auswahl der Window-Manager "kdm" und "gdm" angezeigt werden. Das image-03.vmdk ist inaktiv und wird deshalb auch nicht in der besagten Auswahl gezeigt. Die Beschreibungsdateien für die Sessionauswahl (*.desktop) haben dabei den folgenden Aufbau:
[Desktop Entry] X-SuSE-translate=true Encoding=UTF-8 Type=XSession Exec=name-ohne-leerzeichen TryExec=/var/X11R6/bin/name-ohne-leerzeichen Name=Max. 20 Zeichen Beschr. Comment=Maximal 80 Zeichen Beschreibung des Images, was dann mit dem Ballon-Tip angezeigt wird
Die ersten vier Zeilen sind fix für alle *.desktop, die anderen müssen entsprechend dynamisch erzeugt werden. Der Benutzer darf dabei Name und Comment festlegen frei festlegen. Der Rest muss fest geregelt sein, da beim Boot-Up der Clients automatisch Links auf die Datei /var/X11R6/bin/desktop-session angelegt werden. Diese müssen ein bestimmtes Format haben. Hierbei muss über die Namenskonvention nachgedacht werden damit neben den klassischen WinXP auch SuSE, Debian, Sonstwas-Images ... möglich werden.
Damit eine Anzeige der aktiven VM-Sessions erfolgen kann, muss natürlich der kdm oder gdm wissen, wo er nachschauen muss. Dieses wird in der Konfigurationsdatei zusätzlich zu den klassischen Pfaden festgelegt.
Siehe auch Ticket #37
Einrichtung der VMware-Umgebung¶
Die Einrichtung der VM-Umgebung erfolgt im wesentlichen in zwei Stufen: Einmal generiert servconfig die Runlevel-Links auf /etc/init.d/vmware. Die Skripten werden in dieser Reihenfolge nacheinander gestartet. Dabei kümmert sich:
- servconfig: um das Anlegen eines Verzeichnisses (im tempfs, da es u.U. sonst nicht erzeugt werden kann): /var/lib/vmware. An dieses Verzeichnis wird vom Server (machine-setup Variable ${imgsrv}) eine Verzeichnisstruktur eingemountet, die auf oberster Ebene oben genannte Verzeichnisse und die *.vmdk Images von VMware enthält. Zusätzlich wird noch dafür gesorgt, dass die X-Session um evtl. VMware-Sessions erweitert werden.
- servconfig: um das saubere Anlegen des Runlevel-Skriptes vmware-prep, welches mit distro-spezifischem Header und Footer versehen wird. Der Body wird aus /etc/vmware-prep kopiert (im InitRamFS).
- hwautocfg: um das Entscheiden, wie das mit dem Scratch-Space aussieht: Platz auf lokaler Platte (Partition-ID 44), NFS-Mount vom NFS-Server, wo dann für jeden Client ein eigenes Unterverzeichnis erzeugt wird. NFS führt aber zu speziellen Problemen, siehe weiter unten.
- vmware: (am Schluss) um das Übliche, was sonst auch auf einer normalen Workstation passieren würde.
Spezielle Probleme¶
Soll VMware/Player auf komplett Diskless Clients laufen, hat man noch ein Problem mit einer Speicherabbilddatei (.vmem).
Es wird im "tmpDirectory" der ~/.vmware/preferences ein Unterverzeichnis vmware-$user angelegt, in dem neben einem Logfile eine (unsichtbare, wenn mainMem.useNamedFile="FALSE") Datei mit der Endung .vmem landet. Diese Datei legt VMware beim Start an dieser Stelle an. Sie konsumiert soviel Speicher, wie für den Gast vorgesehen. Sie sollte deshalb besser nicht im TempFS liegen, da so quasi die doppelte Speichermenge, wie für den Gast zugewiesen, verbraucht wird. Es scheint bis zur Version 5.5.X OK zu sein, diese Datei auf ein NFS-Share zu legen, da IO nur einmal beim Start in nicht unerheblichem Umfang passiert (Startverzögerung gegenüber reinem TempFS oder lokaler Platte liegt bei ca. 10-15 Sekunden). Dieser Bereich kann bei allen Clients einheitlich eingestellt werden (a+rwxt), da wegen der Dateibenennung keine Überschneidungen auftreten. Ein Risiko bleibt bestehen: Wenn sich das NFS verabschiedet, steht der Client.
- Mounten des Containers beim Hochfahren des Clients, da Root-Rechte benötigt
- Umlenken der *.vmem in diesen Bereich, REDO etc. besser direkt ins NFS
- Nach Ende einer User-Session sicherstellen, dass der Container wieder frei ist für die nächste.
Der Container heisst vm-container und liegt auf oberster /tmp-Ebene (bezogen auf Stage4), der Mountpoint /tmp/vmware. Dieses wird derzeit noch nicht von "runvmware-v2" ausgewertet, zählt aber zu den nächsten Schritten. Zur Zeit ist die Größe des Containers mit einem GByte auch noch fest verdrahtet ...
Das Ganze funktioniert soweit getestet stabil, ein Performance-Verlust gegenüber dem reinen Schreiben auf NFS konnte nicht festgestellt werden (der oben genannte Zeitverlust bleibt wegen des notwendigen NFS-Traffics bestehen). Es treten dadurch Hoch-Traffic-Phasen der NFS-Nutzung (schreibend!!) auf, die der Server leisten können sollte.
Die .redo sollten ebenfalls nicht auf dem NFS landen. Sie sind bei gut eingerichteten Images längst nicht so gross und erreichen je nach System zwischen 35 und 200MByte. Sie können deshalb im TempFS liegen (beispielsweise /dev/shm).