Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 1

Eine der Funktionen, die Microsoft im kommenden Windows Server “8” am stärksten überarbeitet, ist die Virtualisierung mit Hyper-V. In einer kleinen Artikelserie werden wir die wichtigsten Neuerungen vorstellen. Bitte berücksichtigt dabei, dass das neue Server-Windows noch nicht einmal in der Betaphase ist – alles kann sich also noch ändern. Allerdings dürfte es eher unwahrscheinlich sein, dass Redmond hinter das bisher Gezeigte zurückgeht.

Alle Informationen beruhen auf der “Developer Preview” von Windows Server “8”, die MSDN-Abonnenten zugänglich ist und die auf der Build-Konferenz im September 2011 gezeigt wurde. Schriftliche Informationen dazu sind leider noch Mangelware, doch auf der Build-Webseite gibt es eine ganze Reihe sehenswerter Videos zum Thema.

Allgemeine Neuerungen

Erstmals wird mit Windows “8” die Virtualisierung per Hyper-V auch im Client-Betriebssystem vorhanden sein. Das ermöglicht “Bare-metal”-Virtualisierung auch für Arbeitsplatzrechner, um beispielsweise auf derselben Hardware parallel mehrere Betriebssysteme auszuführen. Bislang war Citrix der einzige Anbieter, der so etwas auf Basis der Xen-Technik ermöglicht. Zwar steht über die Client-Versionen von Windows “8” noch nichts fest, doch ist es sehr wahrscheinlich, dass Hyper-V nur in den höherwertigen Fassungen für Geschäftskunden enthalten sein wird.

Für Virtualisierungs-Hostserver empfiehlt Microsoft auch weiterhin den Betrieb in der reduzierten Core-Installationsvariante, um möglichst wenige Komponenten im Betriebssystem zu haben. Im aktuellen Stadium ist es allerdings möglich, eine Art Hybrid-Installation vorzunehmen, bei der auch die grafische Oberfläche als Funktion aktivierbar und abschaltbar ist. Aufgrund der sehr umständlichen Verwaltbarkeit eines Core-Hosts könnte dies die sinnvollste Fassung darstellen.

Die neue Hyper-V-Ausgabe wird vor allem die Skalierungsgrenzen virtueller Umgebungen drastisch nach oben verschieben. Bislang angekündigt sind folgende Limits:

• CPUs (LP) pro Host: 160
  LP steht für “Logical Processors” – damit sind die Cores einer CPU, aber auch die Threads einer Hyper-Threading-CPU gemeint
• vCPUs pro VM: 32
• vCPUs pro Host: 1024
  vCPUs sind die „virtuellen CPUs“, also die Prozessoren, die man den VMs zuweist. Aufgrund der erweiterten NUMA-Unterstützung ist der Wert hier sehr hoch.
• RAM pro Host: 2 TB
• RAM pro VM: 512 GB
• Aktive VMs pro Host: 1024
• Clusterknoten: 64
• aktive VMs pro Cluster: 4000

Für Snapshots wird es (endlich) möglich sein, ein “Live Merge” auszuführen. Dadurch werden die Daten des Snapshots und der laufenden VM miteinander kombiniert, wenn man etwa einen Snapshot im laufenden Betrieb entfernt. Bislang ist es nach dem Löschen eines Snapshots erforderlich, die betreffende VM ausdrücklich herunterzufahren (ein Neustart reicht nicht!), damit Hyper-V die Daten zusammenführt. Das erweist sich bisweilen als Stolperfalle. Da die neue VM-Replikation (dazu mehr in einem späteren Artikel dieser Serie) auf VM-Snapshots beruht, ist die bisherige Einschränkung nicht länger tragbar und wird somit überwunden.

Für VMs, die in ein SAN integriert sind oder einen Cluster bilden, ist interessant, dass man mit Hyper-V 3.0 nun auch Fibre-Channel-HBAs als virtuelle Geräte in eine VM durchreichen kann. Das ermöglicht in performancekritischen Umgebungen eine wesentliche Vereinfachung, denn bislang konnten virtuelle Maschinen nur per iSCSI in ein SAN integriert werden (was in FC-Umgebungen natürlich eher unerwünscht ist).

Arbeitsspeicher

Für Dynamic Memory gibt es einige Verbesserungen. Dazu zählt die neue EInstellungsmöglichkeit einer Größe für das “Startup RAM” zusätzlich zu den bisherigen Werten für die minimale und die maximale RAM-Ausstattung einer dynamisch konfigurierten virtuellen Maschine. In Hyper-V 2.0 (unter Windows Server 2008 R2) gibt es nur die Unter- und die Obergrenze. Beim Start einer VM bekam diese stets die mininale RAM-Menge zugewiesen, die nicht mehr unterschritten werden konnte. Sofern die VM mehr Arbeitsspeicher benötigt, kann sie diesen über die Integrationsdienste beim Host anfordern und bekommt, sofern verfügbar, weiteres RAM zugewiesen. Die neue Dreiteilung erlaubt noch größere Flexibilität, weil es in der Praxis eine Reihe von Diensten und Applikationen gibt, die beim Start deutlich mehr RAM brauchen als im (ruhigen) Normalbetrieb. In solchen Fällen kann eine VM auch unter den Startup-Wert zurückfallen.

Eine neue Einstellung beim Arbeitsspeicher allerdings überrascht – und erstaunlicherweise lassen sich darüber noch keine verlässlichen Informationen erhalten. Sie nennt sich “Second Level Paging” und könnte einer Art Sensation gleichkommen. Bislang nämlich hat Microsoft vehement und teilweise hoch aggressiv gegen diesen Ansatz der Speicherverwaltung argumentiert.

Unter Second Level Paging versteht man in der Virtualisierung die Auslagerung von RAM-Inhalten auf die Festplatte auf der Host-Ebene. Während Paging an sich unproblematisch und “gutes” Verhalten ist, wenn es durch das jeweilige Betriebssystem kontrolliert wird, kann das Host-basierte Auslagern zu erheblichen Problemen führen. Es tritt dann auf, wenn der physisch verfügbare Arbeitsspeicher auf dem Host knapp wird und der Host gezwungen ist, RAM freizugeben. In diesem Fall kann er RAM-Inhalte, die den VMs gehören, auf die Platte schreiben. Da der Host aber nicht weiß, welche RAM-Inhalte für die VM gerade kritisch sind, kann dies in erheblichen Leistungseinbußen resultieren, wenn die VM etwa genau die gerade ausgelagerten Daten wieder ins RAM laden will.

Bislang war Microsofts Argumentation hier, dass dieser Performanceeinbruch nicht tolerierbar sei und Hyper-V deshalb keinen Gebrauch vom Second Level Paging macht, wie es die meisten anderen Virtualisierungsanbieter tun. Dass diese Option nun plötzlich für Hyper-V 3.0 auftaucht, lässt einige Spekulationen zu:

• Microsoft hat einen Weg gefunden, das Paging der VM mit dem Host abzugleichen und so nur solche Speicherseiten auf die Festplatte auszulagern, die die VM gerade nicht kritisch benötigt.
• Hyper-V nutzt das Second Level Paging  nur in Situationen, in denen Dynamic Memory nicht zur Verfügung steht, beispielsweise beim Bootvorgang.
• Microsoft muss eingestehen, dass Dynamic Memory in Grenzsituationen nicht ausreichend schnell ist, um RAM-Engpässe auszugleichen.

Falls die letzte Option der Fall ist, wäre das durchaus eine interessante Situation und würde die Argumentation von VMware bestätigen, die u.a. in einem viel beachteten Blogpost vorgetragen wurde. Leider findet sich, wie gesagt, noch nichts Verlässliches zu dieser neuen Option.

Verwaltung

Auch auf dem Gebiet der Hyper-V-Verwaltung findet sich in der Developer Preview einiges Interessante. So ist dort ein PowerShell-Modul für Hyper-V nicht nur mitgeliefert, sondern bei installierter Rolle auch bereits eingerichtet. Die Kommandos sehen wesentlich umfangreicher aus als die der bisherigen, separaten PowerShell-Library, die auf Codeplex angeboten wird. Vor allem würde die direkte Integration aber bedeuten, dass Microsoft die Verwaltung mit modernen PowerShell-Commandlets nun endlich offiziell supportet. Per PowerShell lassen sich nun auch einige Einstellungen in delegierten Umgebungen vornehmen, so etwa das Recht, sich per VMConnect mit der Konsole einer VM zu verbinden.

Der Best Practice Analyzer (BPA) in der Preview verfügt über eine ganze Reihe neuer Konfigurationsregeln, die derzeit aber offensichtlich noch nicht angewandt werden. Einige dieser Regeln lassen Rückschlüsse auf weitere neue Detailfunktionen des Hypervisors zu.

Das interessanteste Vehikel für die Administration einer größeren Virtualisierungsumgebung sind aber die Ressourcenpools, die man direkt auf Host-Ebene definieren kann. Sie lassen es zu, beispielsweise mehrere vSwitches zu einem Switch-Pool zusammenzufassen. Virtuelle Maschinen können nun mit einem solchen Pool verbunden werden, wobei Hyper-V dann für die Auswahl des konkreten vSwitches sorgt. Ähnliches gilt auch auf Storage-Ebene. Neben Flexibilität dürfte dies nun auch gezielte Beschränkungen ermöglichen, damit etwa die Admins bestimmter VMs nur auf wenige vordefinierte vSwitches oder Speicherorte zugreifen dürfen.

Ausblick

In weiteren Beiträgen unserer Reihe wird es um die neuen Netzwerk-Funktionen, Clustering und Replikation sowie um weiterführende Quellen gehen.