Virtualisieren mit vSphere, Hyper-V und KVM

Wer erfolgreich seine Server-Landschaft virtualisieren will, sollte die Vor -und Nachteile der einzelnen Produkten wie VMvare vSphere, Microsoft Hyper-V oder Red Hat Enterprise Virtualization kennen. [...]

HYPER-V HOLT AUF
Während VMware das Genre X86-Virtualisierung im Jahr 1998 mit VMware Workstation, einem reinen Typ2-Hypervsor quasi erfunden hat und seinen Typ-1-Hypervisor ESX (später ESXi, vsphere) seit 2001 entwickelt – was auch die hohe Marktdurchdringung erklärt – haben Microsoft und Red Hat erst sehr viel später nachgezogen. Hyper-V ist mit seiner Microkernel-Architektur im Gegensatz zu VMware Kern ein auf Paravirtualisierung ausgerichtet und daher konzeptionell mit dem Xen-Projekt vergleichbar, dass Ende des Jahres 2003 auf der Bildfläche erschienen war.

Wie Xen arbeitet Hyper-V mit einen Parent-Partition (dom0 bei Xen) und einem gegenüber VMware deutlich einfacher aufgebauten Hypervisor, der allerdings zur Bereitstellung von der für Hypervisors essentiellen Deprivilisierungstechnik auf die „Mitarbeit“ der Gastsysteme angewiesen ist, während Gäste bei der von VMware erfundenen Vollvirtualisierung nichts davon wissen, dass sie auf virtualisierter Hardware laufen und daher unmodifiziert funktionieren.

MICROKERNEL
In der Microkernel-Architektur von Hyper-V werden die Spezifika der Hardware „außerhalb“ des schmal gehaltenen Hypervisors (Parent-Partition) behandelt. Der Vorteil ist neben dem kompakten Hypervisor, dass die Treiberversorgung und Hardwarekompatibilität im Gegensatz zu einem monolithischen Hypervisor, wie VMware exzellent ist.

Die Gastsysteme müssen allerdings modifiziert sein, „wissen“ also, dass Sie auf virtualisierter Hardware laufen und kommunizieren ausschließlich über die Hypercall-API und den so genannten VM-Bus mir dem Hypervisor, der sämtliche Funktionsaufrufe behandelt und allein mit der physischen Hardware spricht. Wie Xen auf die Linux-Architektur war Hyper-V anfangs ausschließlich für Microsoft-Gastsysteme ausgelegt, bei denen Microsoft die betreffenden Modifikationen selbst einbauen kann.

EINFACHE INBETRIEBNAHME
Dafür lässt sich Hyper-V als „Rolle“ in Windows Server deutlich einfacher in Betrieb nehmen. Mit dem einfachen Aktivieren der Hyper-V-Rolle leitet man unter der Haube einen recht komplexen Vorgang ein. In dessen Verlauf siebt der Server Manager quasi im Nachhinein den eigentlichen Hypervisor unter das laufende Windows, wodurch der auf echter Hardware installierte Windows Server komplett in eine virtuellen Maschine (der Parent Partition) verfrachtet wird und selbst nur noch für das Steuern des Hypervisors zuständig ist.

Erst durch das Aktivieren der Hyper-V-Rolle wird der Virtualisierungs-Stack aus Diensten, Komponenten und Treibern zur eigentlichen Management-Instanz in der Parant-Partiton, welche fortan genau wie alle anderen virtuellen Maschinen über die Paravirtualisierungsschicht ( VMBus) auf die physische Hardware zugreift.

ZWINGENDER CPU-VIRTUALISIERUNGSSUPPORT
Allerdings funktioniert das Aktivieren der Hyper-V-Rolle ausschließlich bei CPUs mit Hardware-Virtualisierungssupport (vmx), die außerdem Intel Extend Page Tables (EPT, bzw SLAT) unterstützen müssen, was erklärt, dass das Produkt erst seit 2006 eine gewisse Relevanz hat. Daher gibt es Hyper-V auch nur für die X64-Architektur. Die Gemeinsamkeit mit der Xen Architektur ist für Insider nicht überraschend, da Microsoft und XenSource (seinerzeit noch nicht von Citrix übernommen) seit Mitte 2006 zusammenarbeiten.

Hyper-V (intern v, 1.0) ist erstmals mit Windows Server 2008 erschienen, war aber seinerzeit funktional und vom Leistungsumfang keine Gefahr für den Platzhirsch VMware, da tragfähige Konzepte für die Virtualisierung von Netzwerken und Storage fehlten. Das gilt auch für Hyper-V 2.0 in Windows Server 2008R2. Mit Windows Server 2012 und Hyper-V 3 hatte Microsoft seine Virtualisierungstechnologie allerdings so weit entwickelt, dass auch Features wie die Live-Migration von VMs möglich wurden. Bedingung dafür war Shared Storage mit einem Cluster-fähigen Dateisystem, das Microsoft in Windows Server 2012 in Form von Cluster Shared Volumes (CSV) einführte. NFS-Shared-Storage unterstützt Hyper-V nicht.

Seit Windows Server 2012R2 lassen sich zudem auch SMB-3-Freigaben als Shared Sorage nutzen und mit der neuen Rolle ScaleOut-Fileserver (SoFS), sowie der Unterstützung für die Storage-, bzw. Shared Nothing Live-Migration hatte Microsoft Hyper-V 3.1 endgültig zu einer Enterprise-tauglichen Virtualisierungsplattform aufgepumpt, zumal die Hochverfügbarkeitskonzepte mit Windows Failover Cluster im Vergleich zu VMware schon damals vergleichsweise weit entwickelt waren. Derzeit unterstützt Hyper-V pro Host bis zu 320 logische Prozessoren (2048 virtuelle Prozessoren), 1024 virtuelle Maschinen und 4TB RAM sowie pro virtuelle Maschine 1TB RAM, 64 virtuelle CPUs und pro Cluster 64 Knoten mit maximal 8000 VMs.

WINDOWS SERVER 2016
Richtig spannend und ggf. etwas enger für vSphere könnte es allerdings in kommenden Jahr mit der Einführung von Windows Server 2016 werden. Auch in dieser Version hat Microsoft Hyper-V weiter aufbohrt. So lassen sich nun auch in Hyper-V virtuelle Netzwerkadapter im laufenden hinzufügen und der Arbeitsspeicher kann im laufenden Betrieb angepasst werden, auch ohne dass man explizit das Dynamic Memory Feature nutzt.

VMware kann beides schon länger. Interessant in Hyper-V 2016 ist auch, dass VMs nun so genannte Production Checkpoints unterstützen. Hierbei wird zum Erzeugen eines Snapshots nicht nur der Speicherzustand der VM benutzt, sondern auch der Volume Shadow Service (VSS) innerhalb der VM. Die VM weiss hier also, dass es einen Snapshot gibt. Ferner sollen die Integrationsdienste (Integration Services) in Hyper-V 2016 nicht mehr mithilfe von ISO-Dateien, sondern via Windows Server Update Services (WSUS) aktualisiert werden.