Seit OS X auf x86 kompatibler Hardware läuft liegt der Schluss nahe es innerhalb einer virtuellen Maschine zu betreiben. So kann man ohne Befürchtungen die verschiedensten Sachen ausprobieren ohne dabei sein Produktivsystem zu gefährden. Da dies jedoch die Lizenz untersagt, hatte bisher kein Hersteller von Virtualisierungssoftware ein Produkt angeboten welches jenes Vorhaben ermöglicht. Mit der Servervariante von OS X 10.5 hat Apple jedoch die Lizenz bezüglich dessen gelockert und erlaubt nun das betreiben des Leopard Servers in einer Virtualisierunglösung die unter OS X installiert ist.
Mit der Version 2 brachte VMware dann ihren Mac Pendant Fusion mit offiziellen Support für die Virtualisierung von OS X 10.5 Server heraus. Jedoch beschränkt sich die Unterstützung auch lediglich auf die Server Variante, der Versuch die Client Version zu installieren wird nach einer Überprüfung abgebrochen.
Leopard Server ist ohne Frage ein wirklich tolles Betriebssystem aber für den Einsatz als Testumgebung innerhalb einer VM absolut überdimensioniert und mit dem Preisen ab 458,99 € für 10 Benutzer bis 929,00 € für eine unlimitierte Benutzerzahl für diesen Anwendungszweck auch nicht gerade günstig. Wer allerdings bereit ist die Apple Lizenz nicht ganz wörtlich zu nehmen kann mit ein paar Handgriffen dennoch die Client Version in Fusion installieren. Um zu wissen wie man das anstellt ist es ganz nützlich ein paar technische Details hierzu zu erfahren.
Als erstes interessiert uns natürlich die Art und Weise wie Fusion prüft ob das zur Installation benutze Medium eine Server oder Client Variante beherbergt. Hierzu schaut das Programm sowohl auf der Installations DVD als auch unter der späteren installierten Version nach ob die Datei ServerVersion.plist unter /System/Library/CoreServices/ existiert. Größe und Inhalt spielen dabei keine Rolle. Also können wir einfach von unserer Leopard DVD ein ISO Abbild erzeugen und selbiges mounten.
Mit dem Befehl touch “/Volumes/Mac OS X Install DVD/System/Library/CoreServices/ServerVersion.plist” erzeugen wir die benötigte Datei da wo sie hingehört. Nun das Image wieder unmounten und in Fusion als Installationsmedium angeben.
Jetzt müsste die Installation ohne Probleme durch schnurren, bevor wir jedoch in die frische Leopard Version booten können werden wir nochmals in das Installationsmedium booten und dort das Terminal ausführen. Hier erstellen wir die gleiche Datei auf dem eben installierte OS X: touch “/Volumes/Macintosh HD/System/Library/CoreServices/ServerVersion.plist” (Macintosh HD ggf. durch Name der Festplatte korrigieren)
Nun können wir uns über ein frisch installiertes Leopard freuen werden aber recht bald ein merkwürdiges Detail bemerken. Nicht nur Fusion denkt nun das er eine Server Variante ausführt sondern auch der Apple Software Updater. Er bietet nun die passenden Updates für diese Variante an mit denen wir natürlich nichts anfangen können. Dieses Fehlverhalten lässt sich zwar beheben indem wir die ServerVersion.plist löschen aber dann haben wir wieder den Salat mit dem Start der VM. Wir brauchen also die Datei bevor wir booten wollen sie aber löschen bevor wir uns einloggen. Ein Ausweg aus diesem Dilemma wäre es einen Daemon für launchd zu schreiben der uns diese Arbeit automatisiert abnimmt.
Erstellen wir also eine neue XML unter dem Pfad /Library/LaunchDaemons/me.giz.vmware.plist mit folgendem Inhalt:
<?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”> <plist version=”1.0″> <dict> <key>Label</key> <string>com.rectalogic.vmware</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>-c</string> <string>/bin/rm -f /System/Library/CoreServices/ServerVersion.plist; trap “/usr/bin/touch /System/Library/CoreServices/ServerVersion.plist; exit” SIGINT SIGTERM SIGHUP; sleep 999999 &amp; wait $!</string> </array> <key>KeepAlive</key> <true/> <key>RunAtLoad</key> <true/> </dict> </plist>
Mit sudo launchctl load /Library/LaunchDaemons/me.giz.vmware.plist registrieren wir die PLIST im LaunchDeamon. So wird nun dafür gesorgt das die Datei automatisch beim Login gelöscht und bei einem shutdown oder reboot neu angelegt wird. Ein wenig gefrickelt mag das schon wirken aber ich habe mir sagen lassen das dieses Vorgehen auch unter Parallels funktioniert.
Wer dem eigentlichen übel auf den Grund gehen will, nämlich der Überprüfung der Datei durch Fusion, dem zeige ich einen zweiten, etwas eleganteren Weg zum Ziel. Da sich ein Mac beim bootet vor allem durch ein EFI von den BIOS betriebenen PC’s unterscheidet setzt VMware, wenn es erkennt es soll ein OS X starten, einen speziellen Bootloader auf der Basis von Darwin ein. Mit der gleichen Methodik wie schon die Hacker vom OSX86project bzw. Insanelymac vorgehen wird hier dem Kernel die benötigten Informationen die normalerweise das EFI bereitstellt untergejubelt. Zusätzlich bindet VMware über eine RAM-Disk zwei Kernel Extensions ein die dafür sorgen das sich OS X in der virtuellen Umgebung wohl fühlt.
Dieser Bootloader befindet sich im Verzeichnis /Library/Application Support/VMware Fusion/isoimages/
Dumm ist nur das die ISO digital signiert ist, was bedeutet das jede Änderung sofort auffällt. Genial wiederum ist das die zur Überprüfung verwendete Signierung im selben Verzeichnis liegt. Das bedeutet das wir nachdem wir den Bootloader gepatcht haben einfach unser eigenes Zertifikat erstellen und sich VMware nicht beschweren kann. Unser Ziel ist nun die Überprüfung der ServerVersion.plist auf SystemVersion.plist ab zu ändern da diese Datei auf beiden Versionen vorkommt.
Mit den folgenden Befehlen sichern wir erst die Originaldateien, ersetzen die Vorkommen von ServerVersion.plist durch SystemVersion.plist und signieren die gepatche ISO mit unserem eigenen Schlüssel:
sudo bash cd "/Library/Application Support/VMware Fusion/isoimages" mkdir original mv darwin.iso tools-key.pub *.sig original perl -n -p -e "s/ServerVersion.plist/SystemVersion.plist/g"&lt; original/darwin.iso &gt; darwin.iso openssl genrsa -out tools-priv.pem 2048 openssl rsa -in tools-priv.pem -pubout -out tools-key.pub openssl dgst -sha1 -sign tools-priv.pem &lt; darwin.iso &gt; darwin.iso.sig for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem &lt; $A &gt; $A.sig ; done exit
Nun sollte Fusion auch eine Leopard Client DVD installieren können ohne das man irgendwelche zusätzlichen Hacks anwendet. Hierbei muss man aber noch beachten das sich nur eine separat gekaufte Leopard Retail DVD eignet da die mitgelieferten Versionen speziell auf das beiliegende Gerät zugeschnitten sind und nicht mit der virtuellen Hardware zurecht kommt. VMware bezeichnet außerdem die Unterstützung von OS X als experimentell, so funktioniert z. B. die Soundausgabe nicht und auch der Versuch Dateien per Drag’n'Drop auszutauschen scheitert. Hier muss man auf die Gemeinsamen Ordner zurück greifen die man in Fusion aktivieren kann. Wer die Energiesparoptionen komplett ausschaltet vermeidet die Gefahr das das Gast-OS X gelegentlich einfrieren könnte.
Ansonsten verhält sich der Leopard vorzüglich in seinem virtuellen Käfig. Das Netzwerk funktioniert einwandfrei und Systemanimation laufen flüssig ab, selbst die offiziellen Updates werden tadellos eingespielt. Wer sein Fusion updatet und feststellt das OS X nicht mehr bootet muss eventuell den Patch erneut anwenden da unter Umständen der gepatchte Bootloader überschrieben wird.
