Windows 8-Virtualisierung: Quo vadis?

Microsoft plant, in bestimmten Versionen von Windows 8, Hyper-V 3.0 als Client zur Virtualisierung einzuführen. Zwischenzeitlich sind auch einige Informationen bekannt geworden. Befasst man sich aber mit dem Thema Virtualisierung, stellen sich aus meiner Sicht einige Fragen, auf die ich bei Microsoft noch keine Antworten gefunden habe.

In meinem Blog hatte ich ja bereits an mehreren Stellen (z. B. hier) darüber berichtet, dass Microsoft Hyper-V 3.0 in den Windows 8-Clients integrieren will. Steve Sinofsky hat hier einen entsprechenden Artikel im Entwickler-Blog veröffentlicht. Im ersten Augenblick veranlasste mich dies zu einem Freudenschrei. Je länger ich aber über die Geschichte nachdenke, um so mehr Fragezeichen tauchen auf.

Geht Microsoft in die richtige Richtung?

Momentan ist noch unklar, welche Windows 8-Clients mit Hyper-V 3.0 ausgestattet werden. Aus der Vergangenheit darf man aber davon ausgehen, dass dies nur die Clients für den Business-Bereich sind. Die Home-Anwender werden leer ausgehen. Das wäre ja noch kein Problem, kann man auf diesen Clients doch alternative Virtualisierungslösungen a la Virtualbox oder VMware Player einsetzen. Aber man könnte sich ja schon die Frage stellen, welche Strategie ist bei Microsoft im Hinblick auf Virtualisierung bei Business-Kunden zu erkennen.

Wieviele SLAT-fähige Systeme werden wir demnächst haben?

Hier hatte ich darüber gebloggt, dass Hyper-V nur auf Systemen läuft, die eine SLAT-fähige Hardware besitzen. Neben entsprechenden CPUs, die gerade erst ausgeliefert werden, muss auch das BIOS dieses Feature freischalten.

Microsoft führt zwar in diesem Beitrag die technischen Hintergründe an, warum man auf SLAT setzt. Dies ist jedoch einer speziellen Implementierung des Hypervisors geschuldet, die zu einem Performance-Problem bei der Grafikausgabe führt. Alternative Virtualisierungslösungen haben dieses Problem durch eine andere Virtualisierung nicht.

Während man also unter Windows 2008 Server R2 problemlos Hyper-V auf CPUs fahren kann, die lediglich eine Virtualisierungsunterstützung aufweisen müssen, zieht Microsoft bei Windows 8-Clients eine zusätzliche Hürde ein. Da ist SLAT ein Muss. Könnte man mit einer gemeinsamen Code-Basis begründen, was aber auch nicht verfängt. Denn interessanter Weise setzt Windows 8 Server in Hyper-V 3.0 keine SLAT-Unterstützung voraus. Argumentation ist dort, dass in diesem Szenario keine grafiklastigen Anwendungen laufen.

Und damit kommen wir zur ersten Gretchenfrage: Wie viele SLAT-fähige Systeme werden in Firmen bei Auslieferung von Windows 8 vorhanden sein? Es wird zwar immer kolportiert, dass Rechner alle 3 Jahre abgeschrieben werden. Aber Microsoft wirbt doch geradezu damit, dass Windows 8 auch auf Hardware läuft, die für Windows 7 geeignet ist. Und bei mir sind durchaus auch 4 oder 5 Jahre alte PCs im Einsatz, auf denen Windows 8 noch läuft. Ich mag mich täuschen, aber so wie es ausschaut, wird ein Großteil der in 2012 eingesetzten PCs kein SLAT unterstützen. Kommt es dann also wie bei Windows Virtual PC, wo zuerst auch eine Virtualisierungsunterstützung durch die CPU Voraussetzung für den Einsatz war? Und kaum hatte ich mir ein neues System mit entsprechendem Prozessor zugelegt, veröffentlichte Microsoft einen Patch, der Windows Virtual PC für CPUs, die nur eine Softwarevirtualisierung unterstützen, freischaltete.

Was wollen wir 2012 eigentlich noch virtualisieren?

Im Entwicklerblog führt Sinofsky aus, dass man mit Hyper-V 32- und 64-Bit-Betriebssysteme ausführen kann, um so z. B. "alte Browserversionen" für Webentwickler bereitstellen zu können. Na ja, in Firmen ist es im Wesentlichen interessant, alte Anwendungen, die unter Windows 7/Windows 8 nicht mehr laufen, in einer entsprechenden Betriebssystemumgebung zu virtualisieren. Auch Scanner, die nicht durch Windows 7 WIA-Treiber unterstützt werden, sind durch Virtualisierung zum Leben zu erwecken. Aber selbst wenn man nun voraussetzt, dass Hyper-V auf vielen Systemen läuft, stellt sich mir die Frage, was man eigentlich noch virtualisieren will.

Vielleicht werden Sie als Mitleser spontan sagen "Windows XP-Mode ist doch die Basis, um alte Anwendungen zu virtualisieren". Das ist zwar richtig, beantwortet aber die Frage nur zum Teil. Denn auch hier vermisse ich Antworten seitens Microsoft. Denn wenn ich es nicht ganz verpeilt habe, läuft auch der extended Support für Windows XP im Sommer 2014 aus. Wenn Windows 8 im Sommer 2012 auf den Markt kommt, hat man noch knapp 2 Jahre Support für den Windows XP-Mode vor sich. Danach ist (zumindest nach den bisherigen Verlautbarungen) Schicht im Schacht. Wer in Unternehmen also mit der Virtualisierung von Altanwendungen liebäugelt, läuft in ein dickes Problem. Die Migration auf Windows 8 wird in Firmen wohl nicht vor 2013 erfolgen – also kurz bevor Windows XP im Support den "End of Life"-Status erhält.

Eigentlich hätte ich ja erwartet, dass Microsoft da so etwas wie ein "Runtime-System" für Windows XP bereitstellt, unter dem Altanwendungen laufen können, ohne gleich den Ballast eines virtualisierten Windows XP mitschleppen zu müssen. Was bei Linux mit Wine bereitsteht, ist bei Windows 8 auf weiter Flur nicht in Sicht. Irgendwie Murks, das Ganze.

Und wie hält man es mit ARM?

Und noch eine Baustelle tut sich auf, zu denen Antworten seitens Microsoft ausstehen: Wie sieht es mit der Lauffähigkeit von x86-Altanwendungen auf der ARM-Plattform von Windows 8 aus? Momentan scheint es so zu sein, dass Microsoft da einfach nichts anbieten wird.

Aber auch hier wären Lösungen möglich bzw. vorstellbar. Allerdings greifen die alten Virtualisierungskonzepte, ein komplettes Betriebssytem in einer virtuellen Maschine ablaufen zu lassen, nicht mehr. Denn neben der Virtualisierung des Betriebssystems müsste im Hypervisor noch ein ARM-Interpreter für x86-Maschinencode stecken. QUEMU leistet zwar so etwas. In Hyper-V und den gängigen Virtualisierungslösungen ist das aber nicht vorgesehen.

Microsoft besitzt zwar mit dem Windows Phone Emulator entsprechendes Know How. Aber bei der Android Entwicklungsumgebung sehe ich, dass die Interpretation von ARM-Android-Code selbst unter einer QuadCore-CPU und einem Windows 7 Host quälend langsam abläuft. Da ist kein Ansatz für eine produktive Verwendung (und Android ist eigentlich noch als schlank zu bezeichnen).

In diesem Beitrag hatte ich zwar bereits über diese Frage spekuliert und die Microsoft- eigene XAX-Technologie – ein Browser Plugin-Modell, welches das Ausführen von x86-Code ermöglicht, erwähnt. Dies hätte eine interessante Variante sein können, denn die von XAX verwendeten PicoProzesse nutzen dabei eine Art Micro-Virtualisierungs-Framework, so dass die Anwendung in einer Sandbox läuft. Dies ließe sich natürlich auch zur Mikrovirtualisierung einer x86-Umgebung unter ARM implementieren. So wie es momentan aber ausschaut, hat Microsoft auch hier keine Pläne, so was in Windows 8 umzusetzen.

Mein Fazit: Microsoft hat zwar kräftig auf der BUILD 2011 getrommelt und Steven Sinofsky erzeugt auch viel "Rauschen" im Entwicklerblog. Aber im Hinblick auf das Thema Virtualisierung drängt sich mir der Schluss auf, dass:

a) Microsoft entweder keinen richtigen Plan hat, wie es weitergehen soll, oder

b) Microsoft noch kräftig hinter dem Berg hält, was da gerade in den Entwicklerlabors zusammengerührt wird, oder

c) ich einfach den Überblick verloren habe, was Microsoft momentan da genau treibt.

Sucht Euch was aus – morgen werfen wir eh wieder alles über den Haufen.

[Update: Koinzidenz oder nicht, heute bin ich auf diesen Artikel im Guardian gestoßen. Interessant ist der Abschnitt ab "Let's turn to the ARM version of Windows", der ähnliche Fragen stellt, wie ich sie im ARM-Teil dieses Blog-Beitrags angerissen habe.]