Der Blick auf die geplanten Funktionen zeigt, dass Microsoft seinen Hypervisor vor allen Dingen für das Enterprise tauglich machen will. Verbesserungen finden sich besonders bei Management, Hochverfügbarkeit (HA), Verteilung und Performance.

Die Möglichkeiten für das Management wurden durch die Integration von PowerShell in die Rolle Server Core erweitert. Insgesamt lassen sich virtuelle Maschinen unter Hyper-V auf drei Arten verwalten:

• lokal oder entfernt über Kommandozeile oder PowerShell "cmdlets"

• grafisch über die Hyper-V-Managementkonsole, ein MMC-Snap-in, das auf einem vollständigen Windows 2008 Server lokal ausgeführt werden kann, oder sich alternativ auf einem PC unter Vista entfernt nutzen lässt.

• Für Multi-Server-Umgebungen sieht Microsoft den System Center Virtual Machine Manager 2008 (SCVMM) vor

Die neue PowerShell bringt nicht nur mehr Befehle (240 cmdlets) mit, sondern wird auch für Windows 7 sowie für Server Core verfügbar sein. Das Scripting sorgt für die einfache Automatisierung von Abläufen bei der Verwaltung von Hyper-V-VMs. So existieren inzwischen frei verfügbare cmdlet-Bibliotheken, in denen sich Routinen beispielsweise für das automatisierte Sichern und Rücksichern von virtuellen Maschinen finden. Vor allem ist PowerShell remote einsetzbar so dass damit eine zentrale Steuerung etabliert werden kann.

Über ein neues Hyper-V-Konfigurationsmenü können wichtige Einstellungen vorgenommen werden, darunter für den Domain- und Workgroup-Beitritt, die Netzwerk-Konfiguration sowie Einstellungen für das Update und für Remote-Desktop und Remote Management. Außerdem lassen sich darüber Failover-Cluster konfigurieren und Server neu starten. Gerade Einsteigern erleichtert es das erste Setup, denn es müssen keine langen Kommandos mehr eintippen, nur um die Basiskonfiguration zu erledigen.

Fortschritte beim Deployment

Während sich beim Management nicht allzu viel getan hat, sind die neuen Hot-Plugging-Optionen fast schon revolutionär: Virtuelle wie physische Laufwerke können einer VM im laufenden Betrieb zugewiesen oder wieder von dieser abgehängt werden. Dies betrifft zum einen .vhd-Dateien sowie auch "pass-through"-Festplatten, also Laufwerke, die direkt an den Gast durchgereicht werden, ohne dass sie im Host konfiguriert sind. Die Anbindung erfolgt in diesem Fall über den virtuellen SCSI-Controller von Hyper-V.

Unter Windows 7 und 2008 R2 können Systeme auch direkt aus .vhd-Dateien gebootet werden, was ein zentrales Deployment virtueller und physischer Systeme ohne lokale Festplatten ermöglicht.

Mit WIM2VHD, dem "Windows Image to Virtual Hard Disk Converter", steht ein neues Werkzeug zur Verfügung, mit dem sich WIM-Systemabbilder von Windows 7 oder 2008 aus der physikalischen in die virtuelle Umgebung zu migrieren lassen.

Integration von Speicher

Cluster Shared Volumes (CSV) erlauben dem Hypervisor endlich, unter einer Logical Unit Number (LUN) mehrere VMs abzulegen. Bislang musste für jede virtueller Maschine eine separate LUN eingerichtet werden, was den Verwaltungsaufwand unnötig erhöhte.

Zugleich leisten CSV einen zentralen Beitrag zur Hochverfügbarkeit. Mittels Dynamic I/O Redirection lässt sich der Ausfall einer SAN- oder Netzwerkverbindung bei einem Hyper-V-Server oder einer VM kompensieren, indem der Traffic über einen benachbarten Cluster-Knoten geleitet wird.

Bislang sind CSV ausschließlich für die Speicherung und Bereithaltung von Hyper-V-VMs (in Form von .vhd-Dateien) gedacht. Es wird ausdrücklich davor gewarnt, diese Laufwerke für normales File-Sharing zu verwenden, da früher oder später Datenverluste drohen.

Live Migration und High Availibility

Die lang erwartete Migration von VMs während des laufenden Betriebs auf einen anderen Server stellt einige Anforderungen an die technische Umgebung. Es setzt zum einen mindestens Windows 2008 Server R2 Enterprise Edition oder die Standalone-Version von Hyper-V ("Hyper-V Server 2008 R2"). Darüber hinaus müssen sich die beteiligten Rechner im selben TCP/IP-Subnetz befinden und Zugriff auf ein Netzwerklaufwerk (SAN, NFS, NAS) haben, auf welchem die virtuellen Maschinen abgelegt sind. Microsoft sieht für die Speicherung die neuen Cluster Shared Volumes (CSV) vor, eine Erweiterung des NTFS-Dateisystems, um konkurrierenden Zugriff von verschiedenen VMs auf dasselbe Laufwerk zu ermöglichen.

Die CPUs der beteiligten Rechner müssen vom selben Hersteller und aus derselben Prozessorfamilie stammen sowie über den gleichen Funktionsumfang verfügen, damit die Übertragung - ob "Live" oder "Quick" (mit Systemabschaltung) - funktioniert. Darüber hinaus muss die Hardware nicht unbedingt völlig identisch sein.

Zusätzlich müssen die Hyper-V-Server das Microsoft Failover Clustering installiert und konfiguriert haben. Maximal 16 Hosts (Knoten) können zu einem Cluster zusammengeschaltet werden - nur zwischen diesen Rechner lassen sich dann VMs im laufenden Betrieb verschieben. Hierfür empfiehlt der Hersteller ein dediziertes Gigabit-Netzwerk mit redundanter Auslegung der Komponenten.

Die Live Migration lässt sich aus dem Failover Cluster Manager steuern, sie kann jedoch auch remote mittels PowerShell- oder WMI-Script ausgeführt werden. Außerdem kann auch der SCVMM den Vorgang anstoßen.

Die Live Migration legt zunächst auf dem Zielrechner eine neue VM an, kopiert dann die Konfiguration von der Quelle zum Ziel und überträgt schließlich den Speicherinhalt der VM. Zuletzt wird die Quell-VM angehalten und korrespondierende VM auf den Zielrechner gestartet. Dieser Übergang macht sich schlimmstenfalls durch einige wenige Ping-Aussetzer bemerkbar. Dies ist ein spürbarer Fortschritt gegenüber der bisher verfügbaren Quick Migration, bei der die VM während des Transfers pausieren muss, wobei einige Minuten vergehen und Netzwerkverbindungen abreißen.

In unseren Tests erwies sich der Vorgang als unerwartet langwierig. Eine nicht beschäftigte VM mit 1 GB Hauptspeicher zu migrieren nahm dabei fast zehn Minuten in Anspruch, wobei dem Rechnerverbund aus Hyper-V-Hosts und iSCSI-Storage jedoch kein dediziertes und für den SAN-Verkehr optimiertes Netzwerk zur Verfügung stand.

Das Management erweist sich als nicht gut gelungen: Um eine einzige VM hochverfügbar zu machen und sie für Live Migration vorzubereiten, bedarf es einer Vielzahl von Schritten in unterschiedlichen Werkzeugen - iSCSI-Initiator, Festplatten-Manager, Failover Cluster Manager, Hyper-V-Manager. Wird die Reihenfolge nicht eingehalten, liefert der Cluster Validator zwar entsprechende Fehlermeldungen, die eine Diagnose durch den Administrator jedoch nicht ersetzen.

Hier finden Sie einen Screencast zum Thema "Live Migration Demo unter Hyper V-2.0 Beta".

Performance und Ressourcenverbrauch

Die Hardware hat in den letzten 12 Monaten wichtige Fortschritte bei der Unterstützung von virtualisierten Workloads gemacht. Daher ist es nur konsequent, dass Hyper-V 2.0 diese nutzt. Dabei geht es vornehmlich um Optimierungen in der CPU, im Memory sowie bei der Netzwerkanbindung. Second Level Translation (SLAT) bezeichnet spezielle CPU-Mechanismen (bei AMD "Enhanced Page Tables", bei Intel "Nested Page Tables"), die das Speicher-Management beschleunigen und gleichzeitig den Speicherverbrauch des Hypervisors senken. TCP Offloading, Virtual Machine Queue (VMQ) und Jumbo Frames sind Funktionen heutiger auf Virtualisierung spezialisierter Netzwerkkarten, die viele Operationen auf dem Chip ausführen, die sonst der Prozessor übernehmen würde. Hyper-V kann diese Funktionen zukünftig nutzen.

Ein weiteres interessantes Feature, Dynamic Memory, ist in der Beta von R2 entgegen ersten Ankündigungen nicht enthalten und wird es voraussichtlich auch nicht in das endgültige Release schaffen. Damit könnte Arbeitsspeicher je nach Bedarf dynamisch einer VM zugewiesen und auch wieder entzogen werden. Dieser Vorgang würde helfen, physische Ressourcen bei sich ändernden Bedingungen optimal zu nutzen. VMware ESX bietet einen solchen Mechanismus schon seit langem, während XenServer nicht darüber verfügt.

Core Parking ist eine ebenfalls neue Funktion von Hyper-V, das unbenutzte CPU-Kerne abschaltet, wenn sie nicht benötigt werden, was den Gesamtstromverbrauch reduzieren soll.

Unterstützung für Gastsysteme

Hyper-V R2 verträgt sich mit diversen Windows-Varianten, auf dem Server von Windows 2000 aufwärts und auf dem Client muss es mindestens XP SP2 sein. Bei Linux gibt es zumindest in der Beta keine Fortschritte. Sie stellt keine neuen "Integration Components" (ICs) bereit, die für den produktiven Betrieb von Linux-Gästen auf Hyper-V nötig sind. Offiziell wird wieder nur Novell SUSE Linux Enterprise Server 10 (32 und 64 Bit) unterstützt. Nach einem Abkommen mit Redhat wird RHEL 5.x auf Hyper-V laufen. Entsprechende Ergebnisse werden noch für 2009 erwartet.

Fazit

Hyper-V ist gereift und kann von der Anzahl der Features an den Wettbewerb näher heranrücken. Mit Live Migration und dem erweiterten Failover Clustering beseitigt es wesentliche Defizite der aktuellen Version. Zusätzliche Tools, insbesondere die Integration von PowerShell, erleichtern das Management. Wie sich die Performanceoptimierungen in der Praxis tatsächlich auswirken, lässt sich in der Betaausführung nicht seriös messen.

Größere Installationen benötigen mit Sicherheit den SCVMM, weil sich sonst die Konfiguration und Administration der virtualisierten Umgebung zu aufwändig und unübersichtlich gestaltet.

Auch in Version 2 bleibt Hyper-V jedoch ein Virtualisierer für Windows, auch wenn in absehbarer Zeit neben SuSE auch Redhat als offiziell unterstütztes Gastsystem hinzukommt. Wer eine gemischte Umgebung aus mehreren Server-Betriebssystemen aufgebaut hat, wird sich ohnehin überlegen, ob er seine Hardware von Microsoft virtualisieren lässt.

Das Release 2 von Hyper-V kommt voraussichtlich 2010 auf den Markt und zieht dann bei den wichtigsten Basisfunktionen mit den Konkurrenten VMware und Citrix gleich. Während Microsoft noch seinen Hypervisor nachrüstet, eilt der Marktführer VMware einen weiteren Schritt voraus. Statt einzelne Server zu virtualisieren, strebt er die Kontrolle aller Hardware-Ressourcen des Rechenzentrums an. In einer solchen internen Cloud ist etwa Live Migration nur mehr eine Funktion, die dem übergeordneten Zweck der automatischen Ressourcenverteilung zwischen beliebig großen Server-Pools dient. (ws)