Hier hatte ich über die Detaillierung im Microsoft-Entwicklerblog zum Hyper-V-Client für Windows 8 berichtet. Klang alles gut, nur leider hatte ich die Aussage, dass Hyper-V (V3) eine SLAT-Unterstützung durch die CPU erfordert, nicht wirklich richtig zur Kenntnis genommen.
Anzeige
André von WinVistaSide.de hat mich in einem Kommentar darauf hingewiesen. Also habe ich nochmals die Passage im Entwicklerblog nachgelesen.
Hyper-V requires a 64-bit system that has Second Level Address Translation (SLAT). SLAT is a feature present in the current generation of 64-bit processors by Intel & AMD. You'll also need a 64-bit version of Windows 8, and at least 4GB of RAM. Hyper-V does support creation of both 32-bit and 64-bit operating systems in the VMs.
Klingt erst mal ganz harmlos, die aktuellen 64-Bit-Prozessoren von Intel und AMD sollen dieses SLAT-Feature ja haben. André gibt im Kommentar an, dass AMD seit dem K10 Prozessor mit SLAT-Unterstützung dabei ist. Bei den Intel-Prozessoren ist SLAT-Support aber erst ab der iCore-Baureihe vorhanden.
Was steckt hinter SLAT?
Zur Verbesserung des Memory Management wurde in Windows Server 2008 R2 bei Hyper-V eine optionale Unterstützung für Second Level Address Translation (SLAT) eingeführt. SLAT reduziert bei Prozessoren, die das AMD-V Rapid Virtualization Indexing (RVI) oder die Intel VT Extended Page Tables (EPT)-Technologie unterstützen den Overhead beim Virtual zu Physical Address Mapping, so dass virtuelle Maschinen performanter laufen. Nachfolgend findet sich ein Video von Intel, welches die Vorteile demonstriert.
Anzeige
(Quelle: TheIntelMSAlliance
Windows Server 2008 R2 Hyper-V supports a new feature called Second Level Address Translation (SLAT). SLAT effectively lowers the processor and memory overhead incurred during virtual to physical address mapping for virtual machines, which increases the number of virtual machines that can be concurrently executed on a single Hyper-V server. Microsoft has found that with SLAT-enabled processors, the Windows* hypervisor processor overhead drops from about 10% to about 2%, and reduces memory usage by about 1 MB for each virtual machine.)
Ein englischsprachiger Artikel, der die Hintergründe erklärt, findet sich z. B. hier. Und hier beschreibt ein Artikel das Ganze auf AMD-V bezogen. Demnach hat AMD RVI bereits 2007 bei den Opteron-Baureihen mit dem Barcelona-Kern eingeführt. Laut Wikipedia hat Intel diese Technologie erstmal bei der Nehalem Microcode Architektur in den Core i7 Prozessoren eingeführt.
Und die Moral von der Geschicht?
Man könnte die obigen Ausführungen zur Kenntnis nehmen und zur Tagesordnung übergehen. Aber irgendwie nervt mich das Ganze denn doch etwas. Hier hatte ich die "frohe Kunde" gebloggt, dass Windows 8 auf allen Windows 7-Maschinen laufen wird. Die Aussage wurde von Microsoft auf der World Partner Conference 2011 gegeben.
"The hardware investment customers make today will be able to take advantage of Windows 8 in the future".
Also, die Rechner, die ich heute (mit Windows 7) kaufe bzw. einsetze, laufen auch mit Windows 8. Deckt sich auch mit den Erfahrungen, die ich mit den bisherigen Builds von Windows 8 gemacht habe.
Mag vielleicht für Windows 8 an sich gelten – und man kann Hyper-V (V3) als Anhängsel ansehen. Wenn ich mir aber so die typischen Rechner für Büroaufgaben ansehe, kommen die nicht unbedingt mit einem Intel Core i7-Prozessor daher – und in Firmen gibt es noch genügend Rechner, die vielleicht vor einem Jahr angeschafft wurden und noch gut laufen.
Gehe ich nun einen Schritt weiter, ist insbesondere im Geschäftsumfeld davon auszugehen, dass in einigen Fällen Virtualisierung genutzt werden wird, um Altsoftware zum Laufen zu bringen. Nun ist es durchaus legitim, da statt Windows Virtual PC die Hyper-V-Technologie als Client in die Business-Varianten von Windows 8 einzubinden (bei den Home-Versionen erwarte ich keinen Hyper-V-Client).
Doof ist aber: Wenn ich es nicht ganz verpeilt habe, konnte man in Windows Server 2008 R2 die SLAT-Unterstützung optional zuschalten. Ich hatte zumindest hier Hyper-V in einem Windows Server 2008 R2 mit Intel-VT-Unterstützung im Kurztest laufen. Wenn die Aussagen im Entwicklerblog korrekt sind, ist bei Hyper-V (V3), welches in Windows 8 enthalten ist, SLAT-Support zwingend erforderlich. Das mag zwar bei der Speicherverwaltung von mehreren VMs Vorteile bringen. Ein Client mit Windows 8 wird aber in meinen Augen selten als Virtualisierungsserver eingesetzt.
Wenn die offene Frage, ob SLAT-Support wirklich erforderlich ist, mit Ja beantwortet wird, hat sich Microsoft ein Bein gestellt. Denn ich gehe mal davon aus, dass der Großteil der Systeme im Feld eben nicht mit entsprechenden CPUs ausgestattet ist. Das erinnert mich an den Krampf bei Windows Virtual PC. Erst hieß es, VT-Unterstützung ist zwingend erforderlich. Um das zu testen, habe ich mir seinerzeit einen neuen Rechner mit entsprechender CPU zugelegt. Kurz danach stellte Microsoft wohl fest, dass doch nicht so viele Systeme im Feld diese VT-Unterstützung per Hardware aufweisen. Also wurde flugs ein Update zur Softwarevirtualisierung von Windows XP-Mode nachgereicht. Genau der gleiche Krampf könnte nun wieder passieren.
Große Zukunft für VMware und Oracle?
Wenn ich mir das so anschaue, sehe ich noch eine große Zukunft für VMware und Oracle. Privatanwender werden den kostenlosen VMware Player (sofern es den noch gibt) oder VMware Workstation einsetzen bzw. auf Oracles Virtualbox (oder VMLite) setzen. Alle diese Virtualisierungsprodukte dürften in Windows 8-Varianten erscheinen. Und vermutlich bieten diese Lösungen auf Clients mehr Leistung zur Virtualisierung als der Microsoft-Ansatz.
Und was im Entwickler-Blog überhaupt noch nicht angerissen wurde, ist die spannende Frage, welche Möglichkeiten Microsoft zur Anwendungsvirtualisierung vorschweben. Die betreffenden Fragen hatte ich hier schon mal angerissen: Wie sieht es mit dem Windows XP-Mode aus, wenn Windows XP 2014 den End of Life-Status erreicht? Und was ist mit dem Windows 7-Mode für Altanwendungen auf ARM-Systemen unter Windows 8?
Unter dem Strich lässt sich konstatieren, dass der Blog-Beitrag von Sinofsky mehr Fragen offen lässt als beantwortet wurden – ziemlich unbefriedigend. Bleibt zu hoffen, dass auf der BUILD 2011 mehr als Marketing Wischi-Waschi rüberkommt und demnächst eine Beta zum Feldtest zur Verfügung steht.
[Update: Ich habe gerade gesehen, dass heise.de sich in diesem Artikel ebenfalls des Themas angenommen hat. Interessant sind die Ausführungen zum Thema, welche Prozessoren nun SLAT unterstützen – das nächste Chaos ist vorprogrammiert.]
Anzeige
Hier liegt der Grund für den SLAT Zwang:
Update: Alex Verboon hat unter [1] eine nette Erkenntnis in seinem Blog gepostet. In der Eingabeaufforderung lässt sich der Befehl systeminfo eingeben. In Windows 8 liefert dieser Befehl Informationen, ob Hyper-V (V3) unterstützt wird und welche Features auf dem System vorhanden sind.
1: http://www.verboon.info/index.php/2011/09/windows-8-how-to-check-if-your-system-can-run-hyper-v/
In Büros sollten die Virtuellen Maschinen sowieso Zentral gespeichert werden und nicht Dezentral. Nach allem was ich bis jetzt gelesen habe soll es auch ohne SLAT möglich sein sich mit einem Hyper-v Server zu verbinden und eine Virtuelle Maschine zu starten. Lediglich die Locale "Lagerung" der VM fällt weck.
@echo123: Danke für den Kommentar. Dein Hinweis, dass Hyper-V auch VMs auf einem Server anspechen kann, ist korrekt. Hintergrund: Hyper-V 3.0 unterteilt sich in einen Client (Hyper-V-Manager) und den eigentlichen Hypervisor (Server, Hyper-V-Plattform). Der Server (Hyper-V-Plattform) wird auf Windows 8 Clients unterstützt, könnte aber z. B. unter Windows Server 2012 laufen – und die Hyper V-Clients verbinden sich per Remote Desktop Protocol (RDP) mit diesen Servern.
Eine Übersicht über Hyper-V 3.0 (Basis Consumer Preview/Release Preview) findest Du unter [1]. Der Kern und Angelpunkt meines Artikels drehte sich aber um das Fakt, dass ein Client-Betriebssystem mit der Hyper-V-Plattform ausgestattet wird. Und dann muss sich mich mit den Plattformanforderungen (SLAT) befassen. Virtualbox und VMware Workstation/Player brauchen diese SLAT-Unterstützung dagegen nicht.
1: http://www.borncity.com/blog/2012/04/14/windows-8-hyper-v-im-test-teil-i/
angeblich wird SLAT nur von der GUI geprüft und mit DISM kann man es auch ohne SLAT support im Client installieren. Kannst du das mal bei deiner CPU überprüfen?
@André: Kann ich gerne tun – bei der CP weiß ich aber, dass da der Hypervisor mit installiert wurde. Als ich dann aber eine VM starten wollte, kam vom Hypervisor die Fehlermeldung, dass dieser nicht starten könne.
Muss mal schauen, wie ich das mit DISM reinfummle? Ich müsste es vermutlich unter einer Windows To Go Version testen, da ich auf meinem QuadCore-System kein Windows 8 nativ installiert habe.
DISM /online /Enable-feature ist die Funktion:
http://technet.microsoft.com/library/dd744582%28WS.10%29.aspx
@André: Ich habe jetzt die Zeit gefunden, das Ganze mal zu testen. Meine Intel Q8300 CPU unterstützt definitiv kein SLAT ([2]). Deine Idee, den Virtualisierer per DISM zwangsweise hinzuzufügen, ist zwar gut und wird auch unter [1] kolportiert. Ich habe es bereits unter [1] nachgetragen – das Ergebnis meiner Tests war doch etwas ernüchternd.
– Ich habe Windows 8 Release Preview als Windows To Go-Installation (32 Bit Variante) von einem USB-Stick auf einem Intel QuadCore Q8300 gebootet. Die Maschine unterstützt Intel-VT, wie ich aus vielen Tests mit VMware/Virtualbox weiß.
– Dann habe ich die administrative Eingabeaufforderung gestartet und folgende Befehle probiert.
dism /online /enable-feature:Microsoft-Hyper-V-All
und
dism /online /enable-feature /feature-name: Microsoft-Hyper-V-All
Beide Befehle wurden erfolgreich ausgeführt und DISM hat die Hyper-V-Komponenten hinzugefügt (andere Befehle, die ich getestet habe, klappten nicht).
Anschließend habe ich zuerst mein Startmenü inspiziert (ich hatte Classic Shell installiert). Dort waren nur die Hyper-V-Client-Komponenten (Hyper-V-Manager) zu finden. Dann habe ich das Dialogfeld "Windows-Funktionen hinzufügen/entfernen" nochmals überprüft – auch dort fehlte (wie erwartet) der Eintrag für die Hyper-V-Plattform (Server). Und nach dem Aufruf des Hyper-V-Manager (Client), habe ich keine Möglichkeit gefunden, eine Hyper-V-VM als Gast aufzusetzen.
Vielleicht habe ich was falsch gemacht oder übersehen – aber der obige Ansatz, um die Hyper-V-Plattform (Virtualisierer) per DISM freizuschalten, scheint zumindest in der Release Preview von Windows 8 nicht zu funktionieren.
Links:
1: http://social.technet.microsoft.com/Forums/en/w8itprovirt/thread/0c569506-3232-4a9d-ae72-67b642dc7951
2: http://blog.lan-tech.ca/2012/03/11/windows-8-hyper-v-and-slat/
"(32 Bit Variante)"
das ist das Problem. Hyper-V gibt es nur bei der 64Bit Version. Die 32Bit hat nur die Tools um remote eine 64Bit Hyper-V zu administrieren.
André
@André: Danke für den Hinweis – da habe ich mal wieder gepennt (hätte meinen eigenen Text lesen sollen ;-). Ich fertige mir eine 64 Bit-Version von Windows 8 To Go an und teste es nochmals.
Update: Geschichte eines gescheiterten Tests
Ich habe nun einen neuen Test durchgeführt. Umgebung war eine 64-Bit-Windows To Go-Version der Release Preview (Windows 8 Pro), die von USB 2.0-Festplatte gebootet wurde. Wie sich so 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 und die 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 Befehl 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).
Update: Ich habe die gesamte Vorgehensweise in diesem separaten Artikel dokumentiert – Fazit: es klappt nicht wirklich.
Links:
1: Windows To Go mit Windows 8 Release Preview
Hast du auch den BCDEdit Eintrag gesetzt?
Daran lag es bei mir mal. Die GUI wird das wohl extra setzen.
@André: Ich teste das mal – muss jetzt erst mal zum Sport – klingt mal recht interessant. Update: Ok, ich habe es jetzt getestet:
In der administrativen Eingabeaufforderung von Windows 8 wurde er folgende Befehl eingegeben:
bcdedit /set {current} hypervisorlaunchtype auto
Danach habe ich Windows 8 neu gebootet und dann den Hyper-V-Manager dazu überreden wollen, den Hyper-V-Server zu starten. Hat leider nichts gebracht. Der Fehler, dass der Hypervisor nicht startet, ist immer noch da.