Windows 8: Läuft Hyper-V auf nicht SLAT-fähigen CPUs?

[English version]Windows 8 Pro sowie Enterprise werden in der 64-Bit-Version mit der Hyper-V-Platform zur Virtualisierung ausgeliefert. Unter [2] hatte ich ja ausgeführt, dass eine SLAT-fähige CPU zwingend erforderlich ist, um den Hyper-V-Server (Virtualisierer) unter Windows 8 verwenden zu können. Jetzt kamen im Internet Gerüchte auf [3, 4], dass man mit einem Trick die Hyper-V-Platform unter Windows 8 auch auf nicht-SLAT-fähigen CPUs installieren und nutzen könne. Ich habe natürlich die Probe auf’s Exempel gemacht.


Werbung



Etwas Theorie und eine Aussage

Das in Windows 8 enthaltene Hyper-V 3.0 besteht aus mehreren Teilen. Einmal gibt es den Hyper-V-Manager, ein Tool zur Verwaltung virtueller Hyper-V-Maschinen. Dieser Hyper-V-Manager ist auch in den 32-Bit-Versionen von Windows 8 enthalten und stellt nur eine grafische Umgebung dar, die nicht auf SLAT-Unterstützung angewiesen ist.

Die zweite Komponente (neben den PowerShell-Komponenten) ist der eigentliche Hyper-V-Server – von Microsoft als Hyper-V-Platform bezeichnet. Dieser Server dient zur Virtualisierung von Gastbetriebssystemen und ist auf eine SLAT-Unterstützung durch die CPU angewiesen (die Hintergründe sind unter [1], u. a. in einem Kommentar von WinVistaSide-Webmaster André, erläutert).

Die in [3, 4] aufgestellt Theorie besagt, dass nur der GUI-Teil der Windows-Funktionen die CPU auf Hyper-V-Unterstützung überprüft und dann die Aktivierung des betreffenden Features verweigert. Schafft man es nun, das Feature mittels des Tools DISM zu aktivieren, soll der Hyper-V-Server laufen…

Das müssen wir doch ausprobieren – Teil 1

Als André von WinVistaSide.de mich in einem Kommentar auf die Thematik hinwies, reifte die Idee, das mal auf die Schnelle auszuprobieren. Denn in der Tat habe ich hier keinen Rechner mehr, der eine SLAT-fähige CPU aufweist. Mein Dell Inspiron One 2330 mit Intel iCore i7-CPU, den ich für die ersten Versuche [i bis iv] eingesetzt habe, ist aus der Teststellung an Dell zurück gegangen. Also wurde ein Rechner mit Intel Q8300 QuadCore CPU, der Intel VT-X-Unterstützung bietet, für Tests verwendet.

Da auf dieser Maschine kein Windows 8 installiert war, wollte ich besonders schlau sein, und habe Windows To Go aus einem Windows 8 Release Preview-Build verwendet. Im ersten Test habe ich eine 32-Bit-Version von Windows 8 verwendet, dabei aber übersehen, dass diese Variante keine Hyper-V-Plattform bereitstellt.

Also habe ich in einem neuen Test eine 64-Bit-Windows To Go-Version der Release Preview (Windows 8 Pro) aufgesetzt, und dann das System von einer USB 2.0-Festplatte gebootet. Wie sich eine Windows 8 To Go-Version etwas erstellen lässt, habe ich unter [1] (und in den dort verlinkten Artikeln) beschrieben.

Nach dem Booten dieser 64-Bit-Windows-Variante habe ich die Eingabeaufforderung mit administrativen Berechtigungen aufgerufen (in die linke untere Desktopecke zeigen, die Hover-Schaltfläche “Start” mit der rechten Maustaste anklicken und den betreffenden Menübefehl anwählen). Dann habe ich alle Hyper-V-Funktionen mittels des Befehls:

DISM /online /Enable-Feature:Microsoft-Hyper-V-All

zum System hinzufügen lassen. DISM hat die erfolgreiche Ausführung des Befehls bestätigt und mich dann zum Neustart des Systems aufgefordert.

Nach dem Start der Windows-Version wurden die Funktionen wohl konfiguriert und dann ein zweiter Neustart ausgeführt. Danach blieb Windows aber beim nächsten Booten hängen (direkt nach Anwahl des Bootmenüeintrags blieb der Bildschirm dunkel, nicht mal die Anzeige der NumLock-Taste an der Tastatur reagierte).


Werbung

Also habe ich das System neu gebootet und dann eine auf der Festplatte befindliche 32-Bit-Version der Windows 8 Consumer Preview als Windows To Go gebootet. Dann habe ich die Hyper-V-Funktionen in der administrativen Eingabeaufforderung mittels des Befehls:

DISM /Image:R:\ /Disable-Feature /FeatureName:Microsoft-Hyper-V-All

herausgenommen. Nach einem Neustart konnte ich Windows 8 RP wieder booten. Weil dort einige Updates installiert wurden, habe ich nochmals mit der 32-Bit-Windows 8 CP-Variante gebootet und Hyper-V wieder mit dem Befehl:

DISM /Image:R:\ /Enabable-Feature /FeatureName:Microsoft-Hyper-V-All

aktiviert. Beim nächsten Booten hing die Windows 8-Installation wieder.

Da ich ein textorientiertes Bootmenü eingerichtet hatte, habe ich mittels der Taste F8 die erweiterten Startoptionen aktiviert und dann im abgesicherten Modus booten lassen. Da wird der Dienst für die Hyper-V-Plattform offenbar nicht mit geladen – ich kam in den abgesicherten Desktop.

Dort konnte ich unter Windows-Funktionen sehen, das die Hyper-V-Plattform aktiviert ist. Und der Hyper-V-Manager ließ sich per Startseite bzw. Classic Shell sogar aufrufen. Ich habe dann eine VM mit Windows Server 2008 eingebunden. Aber eine VM ließ sich nicht starten (es kam die Meldung, dass dies im abgesicherten Modus nicht ginge).

Test mit einer Windows 8 RP (64 Bit) Installation

Ich habe dann auf die Schnelle Windows 8 RP (Pro-Version) auf der Maschine installiert. Hier war, wie erwartet, die Hyper-V-Plattform unter Windows-Funktionen zur Aktivierung gesperrt.

Gesperrter Hyper-V-Plattform-Eintrag

Anschließend bin ich zum Windows-Desktop gewechselt und habe die administrative Eingabeaufforderung geöffnet. Dann habe ich den oben aufgeführten DISM-Befehl zum Hinzufügen aller Hyper-V-Komponenten eingegeben.

Eingabeaufforderung

Der Befehl wurde ausgeführt und dann kam die Meldung zum Neustart. Nach zwei Neustarts, bei denen das System konfiguriert wurde, ergab die Kontrolle im Dialogfeld Windows-Funktionen, dass nun alle Hyper-V-Komponenten eingerichtet waren.

Windows-Features mit Hyper-V

Danach konnte ich den Hyper-V-Manager über die Startseite bzw. das Classic-Shell-Startmenü aufrufen und eine virtuelle Maschine einrichten.

Hyper-V-Manager

Sah zuerst auch extrem gut aus – man kann den Hyper-V-Manager zumindest testen. Als ich die Verbinden-Schaltfläche gewählt habe, kam dieses Fenster.

Hyper-V-Gastbetriebssystem-Fenster

Mein Versuch, die VM über die Schaltfläche Starten des Fensters zu booten, endete aber mit dieser Fehlermeldung:

Fehler beim Hyper-V-Start

Und damit war Schicht im Schacht. Ich habe noch in den Diensten nachgeschaut – aber die Hyper-V-Dienste lassen sich (wohl wegen der fehlenden SLAT-Unterstützung) nicht starten.

Hilft ein BCD-Eintrag?

An dieser Stelle gab es vom Webmaster der Website WinVistaSide.de noch einen Tipp in den Kommentaren dieses Artikels. Er verwies auf eine von ihm gemachte Erfahrung zum Hyper-V unter Windows Server 2008, wo ein fehlender BCD-Eintrag einen ähnlichen Fehler auslöste (siehe auch diesen MS-Beitrag).

Also habe ich die administrative Eingabeaufforderung unter Windows 8 geöffnet und im Fenster folgenden Befehl eingegeben:

bcdedit /set {current} hypervisorlaunchtype auto

Danach wurde Windows 8 neu gebootet und dann der Hyper-V-Manager erneut aufgerufen. Mein Versuch, den Hyper-V-Server (Hyper-V-Plattform) zu starten, endete aber mit dem gleichen Fehler. Die gesamte Aktion hat leider also nichts gebracht. Der Fehler, dass der Hypervisor nicht startet, ist immer noch da.

Schade – hätte so schön sein können. Aber zumindest reicht mir die Konfigurationsmöglichkeit des Hyper-V-Managers für Tests. Vielleicht lasse ich auf der Maschine Windows Server 2012 laufen (da braucht die Hyper-V-Platform keine SLAT-Unterstützung) und verwende einen zweiten Windows 8-Rechner mit dem Hyper-V-Manager als Client. Der einfachere Ansatz dürfte aber die Verwendung von VMware Workstation oder Virtualbox sein (bis zur RTM von Windows 8 werden diese eine entsprechende Unterstützung bieten).

Ein Gutes hat die Sache doch!

Im Nachhinein habe ich jedoch einen Vorteil des obigen Ansatzes festgestellt. Ich kann zwar (nach dem Hinzufügen der Hyper-V-Rolle zum Windows 8-Client) weiterhin keine Hyper-V-Plattform auf meinem System betreiben. Aber im Hyper-V-Manager wird jetzt ein Hyper-V-Server erkannt und ich kann virtuelle Maschinen anlegen. Dies ermöglicht mir, die betreffenden Funktionen des Hyper-V-Managers (auch in VMware Workstation oder in Virtualbox) zu testen.

Mal sehen, vielleicht boote ich Windows Server 2008 R2 oder 2012 (beide benötigen keine SLAT-Unterstützung für Hyper-V) zum Ausführen der VMs und verwende einen zweiten Rechner zum Zugriff mittels des Hyper-V-Manager.

Links:
1: Windows To Go mit Windows 8 Release Preview
2: Windows 8: Hyper-V braucht SLAT fähige CPUs
3: Technet-Diskussion zu Hyper-V ohne SLAT
4: Artikel zu Hyper-V auf Windows Server 2012
5: Hyper-V vorübergehend abschalten
6: Technet-Artikel zu Hyper-V

Ähnliche Artikel:
i: Windows 8: Hyper-V im Test – Teil I (Hyper-V einrichten)
ii: Windows 8: Hyper-V im Test – Teil II (Host vorbereiten)
iii: Windows 8: Hyper-V im Test – Teil III (VMs aufsetzen)
iv: Windows 8: Hyper-V im Test – Teil IV (VMs einsetzen)


Werbung

Dieser Beitrag wurde unter Virtualisierung, Windows 8 Beta abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

4 Kommentare zu Windows 8: Läuft Hyper-V auf nicht SLAT-fähigen CPUs?

  1. André sagt:

    komisch das das nicht klappt. Du müsstest mal den Server 2012 installieren und dann die Einstellungen vergleichen.

  2. Thomas Pflüger sagt:

    Hallo,

    ich habe mich nun auch etwas damit beschäftigt.

    Ich habe eine E6600. Kein SLAT
    Hyper-V nach Upgrade von W7 auf w8 funktoniert.
    Hyper-V nach Neuinstallation von W8 Ent. lässt sich über GUI nicht installieren.
    Über DISM noch nicht getestet.

    Hier habe ich einen INtel Pentium G630 und lt. coreinfo kein SLAT.
    Hyper-V funktioniert nach Neuinstallation von W8 Ent.

    Muss also doch gehen.

  3. Günter Born sagt:

    @Tom: Danke für die Infos – werde ich bei Gelegenheit mal mit der Enterprise austesten.

  4. Günter Born sagt:

    Nachtrag: Der DISM-Befehl zum Hinzufügen von Hyper-V bei einem laufenden Windows 8 lautet:

    DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V-All

    Im obigen Befehl ist noch ein Tippfehler drin. Ich habe nun auch Windows 8 PRO 64-Bit in der Final (Build 9200) getestet. Mit einer Intel Q8300 geht es definitiv nicht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.