Wer Hyper-V auf Nehalem-CPUs einsetzt, muss mit häufigen Bluescreens rechnen. Schuld ist ein Fehler im APIC-Timer der hochmodernen CPUs. Bei der Lösung des Problems machen weder Intel noch Microsoft einen guten Eindruck.
Anwender von Nehalem-System, die Microsofts Virtualisierungstechnologie Hyper-V unter Windows Server 2008 R2 einsetzen, bekommen derzeit so häufig einen Bluescreen zu sehen, wie sie es seit Windows 95 nicht mehr gewohnt sind. Das ist insofern besonders ärgerlich, da die Kombination aus Nehalem und Hyper-V besonders oft in Serversystemen eingesetzt werden, bei denen mehrere Ausfälle pro Tag nicht hinnehmbar sind.
Die Fehlermeldung lautet "0x00000101 - CLOCK_WATCHDOG_TIMEOUT". Nahezu alle Nehalem-Systeme können von diesem Fehler betroffen sein. ZDNet hat verschiedene Systeme getestet. Auf einigen lässt sich der Fehler überhaupt nicht reproduzieren, andere stürzen regelmäßig ab.
Ursache dieses Problems ist ein von Intel dokumentierter Bug, den der Hersteller wie üblich "Erratum" nennt. In der Spezifikation der Xeon-5500-Serie[1] (PDF) ist dieser Bug unter der Bezeichnung AAK119 aufgelistet. Andere Nehalem-Prozessoren listen denselben Bug unter anderen Namen auf.
Im Wesentlichen geht es darum, dass der APIC-Timer Interrupts generiert, obwohl er das gemäß seiner Programmierung nicht tun sollte. Laut Intel-Dokumentation passiert das, wenn ein Core aus dem C6-Powerstate aufwacht. Microsoft scheint das Verhalten auch beim Powerstate C3 beobachtet zu haben, da eine der Empfehlungen[2] lautet, als "Workaround" die Energiezustände C3 und C6 abzuschalten.
Intel schreibt weiter, dass bestimmte "komplexe" Bedingungen erfüllt sein müssen, damit der Bug auftritt. Außerdem sei Intel keine kommerzielle Software bekannt, die von diesem Bug betroffen sei. Dazu kann man nur feststellen, dass Intel offensichtlich keinen Überblick über den Softwaremarkt hat, wenn es die Virtualisierungslösung des größten Softwareherstellers der Welt nicht kennt.
Microsoft hält seit Anfang Oktober einen Hotfix[3] für den Bug bereit. Allzu großes Vertrauen sollte man in diesen Patch jedoch nicht setzen. Er kommt weder auf dem üblichen Weg per Microsoft Update, noch ist es möglich, ihn von einer Website herunterzuladen. Um den Patch zu bekommen, muss man eine Anfrage per E-Mail[4] stellen. Danach erhält man einen Link zu einer passwortgeschützten Datei.
ZDNet hat festgestellt, dass der Patch auf einem Supermicro-System mit X8SIL-F-Motherboard und einem Xeon-3450-Prozessor (Lynnfield) zwar keinen weiteren Schaden anrichtet, jedoch auch keinen Nutzen bringt. Die Absturzhäufigkeit bleibt mit etwa einem Bluescreen pro Tag auffallend konstant.
In den Kommentaren zu dem MSDN-Blogeintrag[5], der den Hotfix angekündigt, finden sich ähnliche Erfahrungsberichte: Der Hotfix zeige keine Wirkung. Einem Leser fällt auf, dass sowohl die Original- als auch die Hotfix-Versionen der Dateien Hvax64.exe und Hvix64.exe den Versionsstring 6.1.7600.16431 tragen.
Das Abschalten des Powermanagements mittels Registry-Patch behebt das Problem hingegen zuverlässig. Dies hat natürlich interessante Nebeneffekte. Zum einen wird damit auch der Turbo-Modus des Nehalem deaktiviert, zum anderen erhöht sich der Stromverbrauch.
Ein Testsystem mit einem Core i7-920 von ZDNet verbraucht nach Anwendung dieser "Holzhammermethode" im Idle-Betrieb 95 Watt statt vorher 89 Watt. Eine solche Erhöhung des Stromverbrauchs ist bereits für mittelständische Unternehmen mit eigenen Servern nicht hinnehmbar. Ein großer Hoster, der auf Nehalem-Prozessoren setzt, braucht an diese Lösung nicht einmal zu denken.
Heise Online hat herausgefunden[6], dass Microsoft in seiner Dokumentation des Bugs die Empfehlung aussprechen wollte, Hyper-V nicht auf Nehalem-Prozessoren einzusetzen. Intel sei in letzter Minute "auf die Barrikaden gegangen" und habe diese Empfehlung verhindert.
Dafür muss Microsoft Intel dankbar sein. Hyper-V verlangt den Einsatz von Hardwarevirtualisierungsunterstützung durch den Prozessor. Die zweite Generation dieser Technologie mit Second Level Address Translation (SLAT), von Intel Extended Page Tables (EPT) genannt, ist nur auf Nehalem-Prozessoren verfügbar.
Ältere Intel-Prozessoren, etwa auf Core-2-Basis, beherrschen diese Technologie nicht. Von ZDNet durchgeführte Microbenchmarks[7] zeigen, dass bei der Virtualisierung ohne SLAT deutliche Performanceverluste auftreten. Die von der Geschwindigkeit her akzeptable Binary-Translation-Technik, die ganz ohne Hardwarevirtualisierung auskommt, beherrscht Hyper-V nicht.
Bei Intel scheint man derzeit an eine Beseitigung des Problems nicht zu denken. Ein November-Update[8] (PDF) der Spezifikation für die Xeon-3400-Serie listet den Bug unter der Bezeichnung AAO89 auf. Erneut heißt es dort: "Intel hat dieses Erratum bei keiner kommerziell verfügbaren Software beobachtet". In der Zwischenzeit sollte man jedoch davon ausgehen können, dass sich das Problem mit Nehalem und Hyper-V bis zu Intel herumgesprochen hat.
Wenngleich das Problem offensichtlich von Intel verursacht wurde, muss man feststellen, dass auch Microsoft beim Design von Hyper-V nicht alles richtig gemacht hat. Die Verwendung des APIC als Zeitquelle hatte in der Vergangenheit immer wieder zu Problemen geführt. Ausgerechnet Microsoft legte das bereits im September 2002 überzeugend dar.
Microsoft hatte damals die Einführung eines neuen Timer-Bausteins gefordert, der vollkommen unabhängig von der CPU arbeitet. Damals ging es nicht um Virtualisierung, sondern um Multimedia-Anwendungen.
In dem Dokument[9] heißt es: "Der Advanced Programmable Interrupt Controller (APIC) beinhaltet viele Eigenschaften der Echtzeituhr [des IBM AT aus dem Jahr 1984]. Er wurde entwickelt, um mehrere Prozessoren synchron zu halten. Er verfügt nur über eine niedrige Auflösung, und das Silizium dieser Uhr ist manchmal ziemlich buggy. Entscheidender ist jedoch, dass der Timer in einigen Implementierungen durch das Power-Management angehalten wird, was ihn als zuverlässige Zeitquelle unbrauchbar macht. Er wird daher nur selten verwendet."
Ein Softwareentwicklungsleiter mit ein wenig Erfahrung hätte daraus durchaus schließen können, dass man sich auf Komponenten besser nicht verlassen sollte, bei denen schon öfter "Errata" dokumentiert wurden und die durch neue Power-Management-Methoden, etwa Deep Sleep einzelner Cores oder Turbo-Modi, nicht vorsehbare Nebeneffekte zeigen.
Der von Microsoft und Intel gemeinsam entwickelte High Performance Event Timer[10] (HPET) ist auf jedem modernen PC vorhanden. Da Hyper-V ohnehin nur auf Prozessoren mit Hardwarevirtualisierungsunterstützung läuft, kann man davon ausgehen, dass jeder Rechner, auf dem Hyper-V grundsätzlich lauffähig ist, auch über einen HPET-Baustein verfügt.
Ganz so einfach darf man es sich jedoch nicht machen. Die Verwendung des APIC-Timers, der jeweils lokal auf jedem Core vorhanden ist, hat durchaus Vorteile bei der Virtualisierung. Nutzt man ihn, so muss man sich jedoch über mögliche Konsequenzen im Klaren sein. Die Hypervisor-Hersteller halten Details darüber, wie sie welche Timer-Bausteine verwenden, unter Verschluss. Fakt ist jedoch, dass Konkurrent VMware keine Stabilitätsprobleme beim Einsatz von Nehalem-Prozessoren hat, sei es durch geschickte Umgehung des dokumentierten Bugs oder durch Verwendung anderer Timer-Mechanismen an kritischen Stellen.
Hyper-V hat nicht nur Probleme mit Nehalem-Prozessoren. Auch die Verwendung von "High-End-Grafikkarten" bereitet Microsofts Virtualisierungslösung Schwierigkeiten. Unter "High-End" versteht Microsoft in diesem Fall alles, was über reine SVGA-Funktionalität hinausgeht und Write Combining[11] unterstützt. In dem MSDN-Blog mit dem beschönigenden Titel Understanding High-End Video Performance Issues with Hyper-V[12] gesteht Microsoft ein, bei Pages mit Write Combining Performanceschwierigkeiten bei der Software-Emulation von mehrstufigen Page Tables zu haben.
Dieses Problem ist für die meisten Serverbetreiber irrelevant, da Server in der Regel nur mit einer Onboard-SVGA-Karte ausgerüstet sind. Wer jedoch auf einer High-End-Workstation ein Serverbetriebssystem einsetzt oder die kostenlose Stand-alone-Hyper-V-Lösung nutzt, wird von den Lösungsvorschlägen kaum begeistert sein. Diese lauten nämlich, seine High-End-Grafikkarte mit dem SVGA-Treiber zu betreiben oder die Aero-Oberfläche zu deaktivieren. Ein weiterer, recht allgemein gehaltener Workaround lautet "Choose your video card carefully".
Einen sinnvollen Lösungsansatz bietet Program Manager Ben Armstrong mit dem Vorschlag, sich einen Prozessor mit SLAT zu beschaffen, sofern man grundsätzlich bereit ist, die Anschaffung neuer Hardware als Umgehung von Bugs zu akzeptieren. Natürlich hat die Sache einen Haken: Im Fall von Intel-Prozessoren bedeutet das den Umstieg auf Nehalem.
Wegen den bekannten Stabilitätsproblemen mit Nehalem hätte derselbe Program Manager beinahe in einem anderen Blog-Eintrag vom Einsatz von Nehalem-Prozessoren ausdrücklich abgeraten. Ein unlösbares Problem ist das jedoch nicht. Wenn schon Hardwaretausch, so kann man auch auf ein AMD-System mit RVI-fähigem Prozessor[13] umsteigen. Damit gibt es keinerlei Schwierigkeiten.
Beim Einsatz von Microsofts Virtualisierungslösung Hyper-V auf Nehalem-Prozessoren wie Xeon 55xx oder Core i3/i5/i7 kann es je nach verwendetem System zu Stabilitätsproblemen kommen, die sich in regelmäßigen Bluescreens manifestieren. Typischerweise sind ein bis zwei Bluescreens pro Tag zu verzeichnen. Dieses Verhalten ist nicht einmal für Arbeitsplatzrechner akzeptabel - von kritischen Serveranwendungen ganz zu schweigen.
Obwohl dieses Verhalten eindeutig auf einen dokumentiertes "Erratum" von Intel zurückzuführen ist, machen beide Unternehmen bei der Lösung des Problems keine gute Figur. Intel zieht sich auf die Position zurück, es kenne keine kommerzielle Software, die von diesem Problem betroffen ist.
Microsoft hingegen veröffentlicht Lösungsvorschläge und Workarounds, die nicht akzeptabel sind, und stellt einen offensichtlich nutzlosen Hotfix zur Verfügung. Darüber hinaus arbeiten beide Unternehmen nur bei einer "politischen" Lösung des Problems zusammen, indem sie über Formulierungen bei der Dokumentation streiten.
Dass sowohl Hardware als auch Software regelmäßig mit Bugs behaftet sind, sollte für Entwickler zum Tagesgeschäft gehören. Meist lässt sich kurzfristig eine akzeptable Lösung schaffen. Wenn Intel und Microsoft anders als VMware nicht in der Lage sind, das Problem alleine zu lösen, sollten sie besser gemeinsam an einer technischen Lösung arbeiten, statt Betreiber von Nehalem-Servern mit Hyper-V einfach im Regen stehen zu lassen. So wird Microsoft VMware sicherlich keine Marktanteile abnehmen.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/