Was die Prozessorkompatibilität in Hyper-V wirklich tut

Seit Windows Server 2008 R2 gibt es in Hyper-V ein unscheinbares Häkchen, das man in den Prozessor-Eigenschaften einer virtuellen Maschine setzen kann. Es ist in der aktuellen Fassung in Windows Server 2012 R2 beschriftet mit “Zu einem physischen Computer mit einer anderen Prozessorversion migrieren” (im Server 2008 R2 lautete es noch holprig “Mit einer anderen Prozessorversion zu einem physikalischen Computer migrieren”). Um dieses Kontrollkästchen reihen sich einige Mythen und Missverständnisse. Was verbirgt sich wirklich dahinter?

Tatsächlich gab es in der 2008-er Fassung von Hyper-V nicht nur dieses eine Kästchen, sondern auch noch ein zweites. Dieses war beschriftet mit “Älteres Betriebssystem, beispielsweise Windows NT, ausführen”. Seit Windows Server 2012 gibt es das zweite Kästchen nicht mehr (die zugehörige Funktion hingegen schon – dazu später mehr). Besonders diese Kombination führte zu so manchem Missverständnis.

Warum also sollte man das Kästchen mit der Prozessorversion ankreuzen? Die Antwort liegt in der Art, wie sich moderne Betriebssysteme auf den Rechner einstellen, auf dem sie gerade laufen.

Beim Start des Betriebssystems prüft dieses, welche Funktionen der Prozessor bietet, der im Rechner steckt. Besonders die erweiterten Funktionen will das Betriebssystem ja an seine Applikationen weitergeben, damit diese die darin steckenden Optimierungen nutzen und so möglichst schnell arbeiten können. Verschiedene CPUs können durchaus über verschiedene Funktionen verfügen – und dort kann sich ein Problem verbergen. Normalerweise verändert sich die CPU ja nicht im laufenden Betrieb eines Rechners. Bei einer “Live Migration” allerdings, während der eine laufende VM von einem physischen Hostserver auf einen anderen wechselt, kann genau dies passieren.

In einem Host-Cluster ist es unter Hyper-V (genau wie bei den anderen wichtigen Virtualisierungslösungen) erlaubt, dass die Hostserver unterschiedliche Prozessoren verwenden. Das ist in den meisten Situationen auch kein Problem, denn im Fall eines Failover (ein Hostserver fällt aus, und seine VMs werden von einem anderen Hostserver neu gestartet) starten die beteiligten VMs ja ordentlich neu, und dann erkennen sie auch den Prozessor und dessen Funktionen. Nur bei einer Live-Migration kann es passieren, dass eine VM, die beim Starten eine bestimmte CPU erkannt hat, plötzlich auf einem Host mit einer anderen CPU läuft. Versucht diese VM nun, diesen Prozessor mit seinen spezifischen Funktionen anzusprechen, kommt es zu einem Bluescreen (denn der Prozessor versteht das Betriebssystem nicht).

Genau für diese Situation gibt es das Kontrollkästchen “Zu einem physischen Computer mit einer anderen Prozessorversion migrieren” in den CPU-Einstellungen einer VM. Es verbirgt die erweiterten Funktionen der CPU, sodass die VM beim Wechsel von einem Host auf einen anderen auch dann keine CPU-Unterschiede feststellt, wenn die CPUs nicht dieselben sind. Der Effekt dieser Einstellung ist also: Man kann in einem Cluster Hostserver mit verschiedenen CPUs nutzen und laufende VMs zwischen diesen per Live Migration verschieben. Eine Einschränkung bleibt allerdings: Alle CPUs müssen derselben Architektur angehören – oder vereinfacht gesagt: Sie müssen vom selben Hersteller kommen. Entweder alle CPUs von Intel oder alle von AMD – eine Mischung funktioniert nicht mit einer Live Migration.

Trotz dieser praktischen Technik verzichten manche Kunden auf die Einstellung, weil sie befürchten, damit die “Performance” ihrer VMs zu beeinträchtigen. Schließlich, so die Annahme, “sieht” die VM in diesem Fall ja eine “ältere” CPU, und das macht sie ja langsam. Das ist allerdings ein Irrtum. Schauen wir uns dazu an, was die Einstellung tatsächlich bewirkt.

Anders als viele Administratoren annehmen, präsentiert Hyper-V seinen virtuellen Maschinen keine emulierte CPU, auch nicht bei gesetztem Häkchen. Die VM “sieht” immer die CPU, die wirklich im Hostserver steckt. Fragt die VM allerdings die Details zur CPU ab, so greift Hyper-V sehr wohl ein. Schließlich basiert ein Großteil der Servervirtualisierung darauf, dass der Hypervisor die Hardware-Aufrufe der virtuellen Maschinen abfängt und selbst koordiniert. Ruft nun also eine VM beim Start (oder auch später) die Funktion “CPUID” auf, um die Funktionen des Prozessors in Erfahrung zu bringen, so fängt Hyper-V den Aufruf ab und entfernt aus der Antwort die Bits, die zu erweiterten Funktionen gehören. Dadurch stellt sich die VM nicht auf diese erweiterten Funktionen ein, die vielleicht auf einer anderen Host-CPU gar nicht vorhanden sind.

Die allgemeine Leistungsfähigkeit der betreffenden virtuellen Maschinen leidet unter dieser Einstellung nicht, denn die ausgeblendeten Funktionen betreffen vor allem Multimedia-Spezialitäten. Die braucht man auf einem Server in der Regel ohnehin nicht. Alles, was eine Server-VM für ihre Performance braucht, ist in den allermeisten Situationen von dem Versteckspiel gar nicht betroffen. Oder anders gesagt: Für den Großteil der Serverdienste stellt die Kompatibilitätsoption keinen Nachteil dar. Sie verbessert hingegen die Skalierbarkeit von Host-Clustern und damit die Möglichkeiten zur Lastverteilung und zur Ausfallsicherheit.

Die folgenden Screenshots demonstrieren, was das Häkchen tatsächlich bewirkt. Mit dem kostenlosen Werkzeug “CPU-Z” kann man nachsehen, was das Betriebssystem über den Prozessor in Erfahrung bringt. Als erstes folgt die Angabe, die eine Hyper-V-VM mit Windows Server 2012 R2 auf einem Host mit demselben Betriebssystem serviert bekommt:

Die CPU-Angaben innerhalb einer VM unter Hyper-V ohne weitere Einstellungen

Bevor ihr mault: Ja, das ist keine Server-CPU. Es handelt sich bei dem Hostserver um mein Notebook.

Für die zweite Aufnahme habe ich dieselbe VM heruntergefahren und das Kontrollkästchen “Zu einem physischen Computer mit einer anderen Prozessorversion migrieren” aktiviert. Alternativ hätte ich in der PowerShell auch das Cmdlet “Set-VMProcessor” verwenden können (das erst ab Windows Server 2012 zum Lieferumfang gehört).

Die CPU-Angaben derselben VM, wenn die Prozessor-Kompatibilität aktiviert ist

Man sieht hier deutlich, dass die VM “dieselbe” CPU sieht, nur fehlen diesmal einige Angaben zu den möglichen CPU-Instruktionen. Sehr schön lässt sich aber im Vergleich erkennen, dass der CPU-Typ, der Takt, die Caches usw. völlig identisch sind.

Nun gibt es noch eine zweite Einstellung ähnlicher Art, die man seit Windows Server 2012 allerdings nur per PowerShell vornehmen kann. In Windows Server 2008 R2 gab es noch ein eigenes Kontrollkästchen dafür namens “Älteres Betriebssystem, beispielsweise Windows NT, ausführen”. Damit nun niemand auf die Idee kommt, Microsoft würde noch irgendwelchen Support für NT leisten, hat man das Kontrollkästchen aus dem Hyper-V-Manager entfernt. Die eigentliche Funktion gibt es aber noch. In der PowerShell lautet das zugehörige Kommando:

Set-VMProcessor -VMName TS01 -CompatibilityForOlderOperatingSystemsEnabled $true -ComputerName HV01

In Windows Server 2008 R2 gab es zwei Kontrollkästchen für die CPU-Kompatibilität

Im Prinzip bewirkt diese Einstellung genau dasselbe wie das Live-Migration-Kästchen: Hyper-V verbirgt einige Prozessor-Eigenschaften vor der VM. Im Fall der zweiten Option sind das aber noch ein paar Eigenschaften mehr, mit denen sehr alte Betriebssysteme noch nichts anfangen konnten. Das folgende Bild zeigt dieselbe VM wie die ersten beiden, nur diesmal mit aktivierter “Alte-Betriebssystem-Kompatibilität”.

Dieselbe VM, diesmal mit CPU-Kompatibilität für alte Betriebssysteme

Wie man sieht, bekommt die VM immer noch die “tatsächliche” CPU mit dem realen Takt angezeigt. Wie bei der Migrations-Kompatibilität fehlen einige erweiterte Prozessor-Features. Vor allem aber verbirgt Hpyer-V den Prozessor-Cache vor der VM, denn Betriebssystem-Oldies wie NT kannten sowas noch nicht.

Mehr dazu:

[Processor Compatibility in Hyper-V R2 – Ben Armstrong]

http://blogs.msdn.com/b/virtual_pc_guy/archive/2009/06/09/processor-compatibility-in-hyper-v-r2.aspx

[When to Use Processor Compatibility Mode to Migrate Virtual Machines]

http://technet.microsoft.com/en-us/magazine/gg299590.aspx