Seit dieser Woche ist ein neuer Player in der Virtualisierungsbranche im Spiel und hat gleich mal mit einem Paukenschlag aufgewartet: Die Firma InnoTek aus Weinstadt (Remstal?) hat ihr Produkt in Version 1.3.2 für Windows und Linux herausgebracht und hat die Sourcen dazu unter der GPL releast. Fuer Home User und zur Evaluation kann man sich von http://www.virtualbox.org ein 11MB großes msi für lau herunterladen und installieren. Ich habe das mal auf ein paar Rechnern gemacht und wollte sehen, wie sich das Produkt so macht, was Performance und Stabilität angeht, und wie es sich so im Vergleich zu Konkurrenzprodukten schlägt. Für die Performancetests und Vergleiche habe ich einen Pentium 4 mit Hyperthreading und 1.5 GB RAM und Windows XP als Host-OS verwendet, für die Funktionstests einen AMD64 X2 3800 mit 3 GB RAM und Windows XP Media Center Edition (x86) als Host OS.

Performance
Für die Performancetests wurden auf dem P4 besagte Version von VirtualBox installiert, dazu der aktuelle Release Candidate von Virtual PC 2007 und die aktuelle Version von VMWare Server (1.01). Installiert wurde für jedes Produkt eine identische Version von Windows XP SP2, und zwar jeweils mit 256 MB Speicher, einer 10 GB Harddisk und den zum jeweiligen Produkt zugehörigen Tools oder Addons, die jeweils noch irgendwelche Grafiktreiber und ähnliches mitbringen. Die Installation von XP lief jeweils problemlos, auffällig war aber, daß die Trägheit des Mauszeigers in VirtualBox am absolut geringsten war. In diesem Modus beansprucht das Gast-OS noch jeweils die Maus und das Keyboard exklusiv, sobald man einmal in das Fenster der virtuellen Maschine geklickt hat, und gibt beides erst wieder zurück, wenn man den "Host-Key" gedrückt hat (eine je nach Produkt unterschiedliche Tastenkombination). Nachdem dann die jeweiligen Additions und Tools installiert waren bestand der Performancetest darin, die Zeitdauer zu messen, die vom Start des Betriebssystems vergeht bis die Startleiste von XP sichtbar und bedienbar wird. Hier die Zahlen:

• Virtual PC 2007: 46s
• VMWare Server 1.01: 34s
• VirtualBox 1.3.2: 19s

Wie man sieht, outperformt VirtualBox hier den Rest der Konkurrenz deutlich.

Funktionalität und Stabilität
Für die Funktionstests von VirtualBox habe ich W2K Professional SP4 und XP auf dem x64 Host installiert. Die Installation von XP verlief klaglos und ohne Probleme. Bei Windows 2000 hingegen gab es kurz nach der Phase der "Component Installation" einen immer wieder perfekt reproduzierbaren unvermittelten Reboot. Daß sich Windows 2000 dann dennoch installieren ließ, ist darauf zurückzuführen, daß ich schließlich die Prozessoraffinität des Prozesses virtualbox.exe auf einen der beiden Cores des Hosts beschränkt habe, woraufhin der unvermittelte Reboot nicht mehr auftrat und das Setup zu Ende laufen konnte.

Insgesamt tritt VirtualBox mit einigen Claims an, deren Erfüllungsgrad ich überprüfen wollte:

• Multiple Snapshots
• Networking Support
• RDP Support für Gastsysteme
• USB Support lokal und über RDP

Multiple Snapshots: Tatsächlich kann man in VirtualBox mehrfache Snapshots für ein Gastsystem anlegen. Das Problem bei VirtualBox ist aber, daß man dabei eine Kette von Snapshots aufbaut anstatt einen Baum wie bei VMWare. Bei VMWare kann man zu jeder Zeit zu einem beliebigen Snapshot zurückkehren und beliebig zwischen einzelnen Snapshots wechseln. Nicht so bei VirtualBox: Hat man beispielsweise eine Folge von 3 Snapshots A, B und C erzeugt und will von Snapshot C auf Snapshot A wechseln, muß man Snapshot B und Snapshot C löschen, was nun mal wirklich richtig Panne ist. Eine Merkwürdigkeit habe ich dabei auch festgestellt: So konnte ich im laufenden Betrieb (anders als dokumentiert) einen Snapshot erzeugen, habe ihn gelöscht und daraufhin den aktuellen Snapshot gestartet. Die virtuelle Maschine wurde aber dabei im gerade gelöschten Snapshot fortgesetzt (!?!) anstatt in dem eigentlich angewählten Snapshot. Hhhm, merkwürdig...

Networking Support: Unmittelbar nach Installation hat jede virtuelle Maschine einen "AMD PCNET Family PCI Ethernet Adapter" und eine vom Host ge-NAT-ete Netzwerkverbindung. Diese NAT des Host reicht aus, um von einer virtuellen Maschine Verbindungen nach draußen zu machen, also beispielsweise Laufwerke auf dem Host zu mounten oder im Web zu surfen. Serverdienste der virtuellen Maschine sind jedoch in dieser Betriebsart vom Host aus nicht zu erreichen. Man kann also keine Shares der virtuellen Maschine vom Host aus erreichen, was IMHO die Funktionalität doch stark einschränkt. Neben NAT kann man auch "Internal Networking" einstellen, was ähnlich wie das "Host-only" Network von VMWare ein privates Netzwerk auf dem Host ist, aber nur zwischen einzelnen virtuellen Maschinen funktioniert, nicht aber zwischen Host und Gast. Der dritte Modus, "Host Interface Networking" hat zwei Betriebsarten, "TCP/IP Routing" und "Ethernet Bridging". Für ersteres muß man sich seine Routingtabellen auf dem Host selbst erstellen, das Handbuch geht darauf nicht näher ein und fordert den geneigten Benutzer dazu auf, den Hersteller zu kontaktieren für weitergehende Unterstützung. Bei "Ethernet Bridging", das auch kaum weniger stiefmütterlich im Handbuch beschrieben ist, muß man sich zuerst mit Hilfe der Tools von VirtualBox eine neue Netzwerkverbindung aufbauen, der man dann einen mehr oder minder sprechenden Namen gibt. Wenn man das tut, erscheint dann die Warnung des User Mode Pnp-Managers, daß man nun einen unsignierten Treiber installiert (die Treiber von VirtualBox sind samt und sonders unsigniert) und hat damit ein neues Netzwerkdevice, den "VirtualBox TAP Adapter", als root-enumerated device, der für eine neue Netzwerkverbindung zuständig ist. Die Netzwerkverbindung hat dann den Namen, den man ihr mit den VirtualBox Tools gegeben hat, in meinem Fall ein schlichtes "hello":

Um diese Netzwerkverbindung vergleichbar dem "Bridged Networking" von VMWare zum Rennen zu bringen, muß man es nun mit dem eigentlichen Ethernet-Adapter des Hosts zu einer Bridge verschalten, und das geht so:

Man wählt also beide Netzwerkverbindungen an, und wählt im Kontextmenü "Verbindungen überbrücken". Das Ergebnis schaut dann folgendermaßen aus:

Nun muß man nur noch eventuell (bei einer vormals statischen IP-Adresse des Etnernet-Adapters) die IP Adresse der Bridge korrigieren und los geht's, man hat nun bridged networking für die virtuelle Maschine. Doch die Freude währt nicht lang: Will man nun zwei virtuelle Maschinen mit bridged networking betreiben, so können diese sich beileibe nicht die Netzwerkverbindung teilen. Vielmehr muss man einen weiteren "VirtualBox TAP Adapter" mit Hilfe der VirtualBox Tools erzeugen, diesen der Netzwerkbrücke auf dem Host hinzufügen, so daß die Bridge nun aus drei Geräten besteht, und schließlich die zweite virtuelle Maschine mit dem neuen TAP Adapter betreiben. Umständlicher geht's nun wirklich nicht! Die Linuxvariante von VirtualBox hat laut Handbuch hier den Vorteil, daß sie diese TAP Adapter on-the-fly und je nach Bedarf automatisch erzeugen und wieder abbauen kann.

RDP Support für Gastsysteme: Der RDP-Support für Gastsysteme hört sich im ersten Moment sehr vielversprechend an, verheißt er doch nichts Geringeres, als daß virtuelle Maschinen, die keinen eingebauten Terminalserver haben, wie etwa W2K Professional, auf wunderbare Weise von einer anderen Maschine aus über einen Terminal Services Client bedienbar werden. Scharf geschaltet und gestartet wird dieser RDP-Support über ein Kommandozeilentool (vmboxmanage), das aber bei mir nur zu einem Aufflackern eines weiteren Prozesses in der Prozessliste führte. Kurz im Handbuch geblättert und gefunden, daß man dieses andere Programm (vboxvrdp) auch von Hand starten kann. Dieses lieferte dann einen kryptischen Access Denied zurück. Dann ist mir eingefallen, daß mein Host ja Zugriff per Remote Desktop gestattet. Diesen dann abgeschaltet und - oh Wunder - plötzlich startete im Hintergrunnd die virtuelle Maschine im nun lauffähigen Prozess vboxvrdp. Man muß also von Hand auf der Hostmaschine den vboxvrdp starten, damit man per Terminal Services Client auf die so gestartete virtuelle Maschine draufkommt. Man kann aber natürlich den vboxvrdp nicht remote über Remote Desktop starten, weil dann startet er ja nicht, weil ja gerade der Remote Desktop läuft weswegen er nicht starten kann, denn da beißt sich ja die Katze in den Schwanz. Vielleicht geht das allenfalls noch über eine Telnet Session auf den Host. Ja geht's eigentlich noch?? Und so wenig durchdacht dieses Feature implementiert ist, so stabil läuft es dann auch. Auf besagte virtuelle W2K-Maschine konnte ich über einen Terminal Services Client immer nur exakt bis zum Login zugreifen, ab da stürzte die virtuelle Maschine reproduzierbar sang- und klanglos ab. Also mal davon abgesehen, daß man den Start der Maschine vielleicht über ein remotefähiges Interface machen sollte, wo dann die virtuelle Maschine dann als Kindprozess eines Service läuft, kann man mit diesem Verfahren pro Host immer nur eine (!) virtuelle Maschine über RDP fernsteuern. Can you say "This won't scale"?

USB Support lokal und über RDP: Nach dem Fiasko mit dem RDP-Zugriff war natürlich an einen USB-Zugriff über RDP gleich gar nicht zu denken, also habe ich mich auf den Test des lokalen USB-Zugriffs beschränkt. Anders als bei VMWare findet aber der Zugriff der virtuellen Maschine auf USB-Hardware des Hosts nicht automatisch statt, wenn man USB-Hardware einsteckt während die virtuelle Maschine im Fokus ist. Denn die Zugriffe auf die USB-Hardware des Hosts wird durch sogenannte Filter geregelt, bei denen man die Vendor ID und Product ID des Herstellers angeben soll, um USB-Devices, die diesen IDs entsprechen, zur virtuellen Maschine durchzureichen. Als ob ein Normalsterblicher wüßte was die Vendor-ID seines USB-Geräts ist!?! Nein, um mal eben ein beliebiges USB-Gerät zur virtuellen Maschine durchzureichen, muß man auf die glorreiche Idee kommen und erstmal einen leeren Filter ohne Filterregeln anzulegen, dann geht das. Es wird dann ähnlich dem "VMWare USB Device" ein Gerät namens "VirtualBox USB" auf dem Host angelegt und in die virtuelle Maschine durchgereicht. Aber wenn man nun wie ich einen leeren Filter angelegt hat, dann wird ab sofort jedes USB-Gerät durchgereicht und das auch dann, wenn man die virtuelle Maschine gerade im Hintergrund laufen hat und eigentlich erwartet, daß das USB-Gerät vom Host verwendet wird. Aaaargghhhh! Hhm, was wohl passiert, wenn man mehrere virtuelle Maschinen mit diesem Filter laufen läßt und ein USB device anstöpselt? Ich will's gar nicht wissen....

Was sonst noch so auffiel: Hier eine lose Liste mit Dingen die mir beim Umgang mit VirtualBox bisher so auffielen:

• Clipboard: Es gibt keine Möglichkeit, Strings über die Zwischenablage zwischen Host und Gast auszutauschen. Daß so etwas Banales nicht implementiert zu sein scheint, aber stattdessen so exotische Dinge wie USB via RDP, ist in meinen Augen ein absolutes Unding
• Virtuelle Maschinen in Virtual PC sind legacy-free: Das bedeutet, dass die Legacy-Schnittstellen (seriell und parallel) nicht virtualisiert sind. Merkwürdigerweise gibt es aber noch eine PCI-to-ISA bridge, duh!?! Zudem werden (auch ohne die VirtualBox-Addons) aber Treiber geladen, die kein vollständiges Power Management gestatten, weswegen man beispielsweise eine virtuelle Maschine in VirtualBox nicht in den Sleep Modus versetzen kann. Aufgrund der fehlenden seriellen Schnittstelle frage ich mich da, wie die Entwickler bei Innotek eigentlich ihre Kernel-Mode Treiber debuggen und aufgrund des fehlenden Sleep-Modus frage ich mich, wie sie ihren Power-Management-Code debuggen würden, so sie einen Kernel-Mode-Debugger an das System attachen könnten. Aber bestimmt bin das nur ich, der sich das fragt.
• Insbesondere meine virtuelle W2K Maschine hing des öfteren scheinbar für lange Zeit während des Bootvorgangs (sie startete zwar zuverässig, hat sich aber mitunter minutenlang im Boot festgefressen). Nagelte man die Prozessoraffinität des die VMs startenden Prozesses VBoxSvc.exe dagegen auf einen einzelnen Core des Hosts fest, traten derartige Hänger nie auf.
• Der Prozess virtualbox.exe, in dem je eine virtuelle Maschine läuft, crasht ganz gern einmal wenn man die betreffende virtuelle Maschine gerade heruntergefahren hat, also wenn er sich eigentlich auch ansonsten ordnungsgemäß terminiert hätte. Sieht nicht schön aus...
• Sind die VirtualBox Guest Additions einmal installiert, so hängt da immer so ein Icon in der System Notification Area (vulgo: "Tray") herum. Man kann mit dem nichts anfangen, es reagiert auf keine Mausklicks, gar nix. Es verbraucht nur Platz in dieser knappen Ressource und zieht nachweislich die Aufmerksamkeit neugieriger Benutzer wie meiner bescheidenen Wenigkeit auf sich. Weg mit diesem Mist, man kann auch einen Prozess im Kontext des interaktiv eingeloggten Users mit einem hidden window ohne ein nutzloses Icon im System tray starten!
• Umziehen von VMs auf einen anderen Host: In diesem Punkt existiert überhaupt keine Dokumentation. Etwas so alltägliches wie austauschen von VMs zwischen Kollegen scheint als use case für Virtual Box überhaupt nicht vorgesehen zu sein. Jedenfalls ist mir nicht klar, wie ich außer den Files fuer die Harddisks einer VM auch noch die Konfigurationsdaten einer VM von einem Host auf den nächsten zu transportieren habe.

Mein Fazit:
VirtualBox ist ein Produkt, das aus dem Stand in Punkto Performance den Rest der Welt ganz, ganz alt aussehen läßt. Bei den meisten Features des Produkts ist aber immer noch ein bißchen Handarbeit angesagt, was das Produkt für den unbedarften Anwender untauglich erscheinen läßt. Der ist nämlich mit dem VMWare Server oder dem VMWare Player, die's ja beide auch für lau gibt, besser bedient. Beide VMWare-Produkte können zwar keine Snapshots, und der VMWare Server ist USB-agnostisch, aber ihre Einbindung in die Umgebung, besonders was Networking angeht, sind einfach intuitiver und besser gelöst. Wenn ich beim Hersteller InnoTek Product Manager wäre, würde ich diesen Mist mit RDP-Support sofort stoppen. Das ist ein Feature, das vermutlich zu Unsummen an Entwicklungskosten führt, einen Nullinger skaliert und so was von flaky ist, daß es dem bis dahin ohnehin schon frustrierten Benutzer vollends graust. Toll an VirtualBox ist, daß es mit seinem USB-Support etwas vorweisen kann, was Virtual PC auch in seiner 2007er Inkarnation noch nicht mal ansatzweise hat. Nur ist die Verwendung dieses Features leider spektakulär technokratisch gelöst und weit entfernt von der Intuition von VMWare. Bestimmt argumentiert der zuständige Entwickler bei InnoTek, daß man sich ja nicht wie bei VMWare Workstation auf den Fokus verlassen darf, um USB devices fallweise durchzureichen oder nicht. Schließlich gibt es ja dieses Kriterium des Fokus nicht gibt, wenn man die Maschine per RDP bedient. Lieber Entwickler: Dieses RDP-Feature ist bullshit und gehört gestrichen, deswegen kannst Du das dann auch mit dem Fokus locker implementieren. Und hey, lieber Entwickler, was glaubst Du, warum es von VMWare die Workstation gibt, die USB kann, und den Server, der USB nicht kann?

Alles in allem ist es zwar einerseits gut, dieses Produkt der Öffentlichkeit zugänglich zu machen, weil vielleicht mit dem Feedback der User das Produkt an vielen Stellen glattgezogen werden kann, an anderer Stelle hätte man dem Produkt jedoch noch ein wenig mehr Reife oder weniger Verspieltheit gewünscht, wei etwa beim Thema RDP oder USB. Wenn diese paar Dinge noch verbessert werden, dann hat das Produkt ernsthafte Chancen, Virtual PC auf Platz drei zu drängen.