Virtualisierungstechnologien bieten eine Reihe von Vorteilen. Man kann die Anzahl physischer Server reduzieren, indem mehrere virtuelle Server auf einer physischen Maschine betrieben werden. Das erleichtert das Management von Systemumgebungen. Gleichzeitig kann man die Leistungsfähigkeit von Servern durch den parallelen Betrieb mehrerer virtueller Systeme besser ausnutzen, ohne dabei Konflikte bezüglich der Interoperabilität verschiedener Serveranwendungen in Kauf nehmen zu müssen.
Ausserdem lassen sich heterogene Infrastrukturen effizienter betreiben, da sich unterschiedliche Betriebssysteme auf einem physischen System ausführen lassen. Und selbst für die Sicherheit kann die Virtualisierung Vorteile bringen, da man Serverfunktionen besser voneinander trennen und auch mehrschichtige Infrastrukturen in virtueller Form realisieren kann. Die flexible Verschiebbarkeit von virtuellen Maschinen über verschiedene physische Server hinweg bringt schliesslich sogar Vorteile für die Verfügbarkeit.
Es gibt eine ganze Reihe von Ansätzen für die Virtualisierung. Microsoft unterstützt in seinem Portfolio mit Produkten wie der WSV, SoftGrid oder dem Virtual Server eine ganze Reihe dieser Verfahren (siehe auch InfoWeek 05/07). Für die verschiedenen Verfahren gibt es dabei durchaus unterschiedliche Begrifflichkeiten. Die wichtigsten Ansätze im Zusammenhang mit der Windows Server Virtualization (WSV) sind die native oder volle Virtualisierung, die partielle Virtualisierung respektive Hybrid-Virtualisierung sowie die Paravirtualization, Type 1 Virtual-Machine Manager oder Hypervisor-Konzepte.
Die Unterschiede liegen sowohl auf der Ebene, auf der die Virtualisierung durchgeführt wird, als auch in der Integration mit der Hardware. Die native oder volle Virtualisierung stellt ein vollständiges Abbild der Hardware für die Gast-Betriebssysteme bereit. Dieses Konzept wird sowohl bei Produkten wie Vmware und dem Virtual Server 2005 als auch bei der WSV verwendet. Sie unterscheidet sich von einer teilweisen Emulation von Systemen.
Das von der WSV verwendete Konzept der Virtualisierung arbeitet mit einem sogenannten Microkernel-Hypervisor. Bei diesem werden die Treiber für die Hardware nicht in den Hypervisor integriert. Statt dessen wird mit den Treibern der jeweiligen VMs gearbeitet. Damit sind für die unterstützten Betriebssysteme keine speziellen Treiber erforderlich, was zu einer breiteren Hardwareunterstützung führt. Im Gegensatz dazu steht das Konzept des monolithischen Hypervisors. Bei diesem werden die Treiber als Teil eines reduzierten Betriebssystems bereitgestellt. Dieser Hypervisor ist allerdings deutlich komplexer und weniger flexibel.
Die Implementierung mit dem Hypervisor als Basis und speziellen Komponenten, die innerhalb der Parent- und Child-Partitionen aus-geführt werden, ist nicht trivial. Die Herausforderung liegt vor allem in der Kommunikation zwischen den virtuellen Maschinen, deren Steuerung und im Zugriff auf die Hardware.
Bei der WSV laufen die Zugriffe auf die Hardware über die Parent-Partition und die dort verwendeten Treiber. Diese Partition kommuniziert über die Virtualization Service Providers (VSPs) und den VMBus mit den Child-Partitionen. In diesen gibt es analog Virtualization Service Clients (VSCs) als Gegenstück zu den VSPs. Die sogenannten Enlightenments sind Abbilder der virtuellen Treiber. Auf diese wird zugegriffen, um tatsächlich mit den Hardwarekomponenten arbeiten zu können. Nur in der Parent-Partition gibt es den eigentlichen Stack für die Virtualisierung. Über diesen werden die Arbeitsprozesse und der WMI-Provider für die Steuerung der Virtualisierungsfunktionen bereitgestellt.
In den vergangenen Monaten ist viel über die Kooperation von Microsoft mit verschiedenen Firmen im Linux- und Open-Source-Umfeld geschrieben worden. Einer der wichtigsten Punkte dabei ist das Zusammenspiel zwischen der Xen-Virtualisierung und der WSV. Dabei wird es unter anderem möglich sein, einen Xen-aktivierten Linux-Kernel über den VMBus und entsprechende Virtualization Service Clients mit dem Virtualization Service Provider in einer WSV-Umgebung kommunizieren zu lassen (siehe Diagramm «WSV in Zusammenarbeit mit Xen»). Diese Interoperabilität soll in beide Richtungen gelten, um flexible, heterogene Server-Infrastrukturen aufbauen zu können.
Die WSV stellt relativ hohe Anforderungen an die Hardware. Es wird zwingend 64-Bit-Hardware benötigt mit CPUs, welche die Virtualisierung unterstützen (AMD-V oder Intel VT). Ausserdem muss entsprechend viel Speicher vorhanden sein, um mehrere Systeme sinnvoll parallel zueinander ausführen zu können.
Dafür gibt es für die Leistungsfähigkeit der einzelnen VMs auch wenig Grenzen – man kann auch sehr komplexe virtuelle Maschinen ausführen.
Die WSV soll mit dem Windows Server 2008 verfügbar gemacht werden und ist erstmals im aktuellen Release Candidate 0 enthalten – dort noch als sogenannter CTP (Customer Technology Preview). Sie wird als spezielle Server-Rolle eingerichtet. Die Windows-Server-Core-Installation wird zumindest in diesem Release aber noch nicht unterstützt.
Gerade bei den Anforderungen und Installationsprozeduren des Windows Server 2008 RC 0 wird aber auch deutlich, dass die WSV noch in einem etwas früheren Entwicklungsstatus als das eigentliche Betriebssystem ist. Durch die Umsetzung als Server-Rolle spricht aber viel dafür, dass die WSV zeitlich zum Windows Server 2008 verfügbar werden wird. Wichtig sind einige Einschränkungen. So kann WSV beispielsweise nicht auf Domänencontrollern eingerichtet werden. Ausserdem verträgt sich WSV nicht mit Virtual PC und dem Virtual Server. Es bleibt abzuwarten, welche Einschränkungen noch bis zum Release beseitigt werden und welche bestehen bleiben.
Insgesamt wird die Windows Server Virtualization aber eine interessante Ergänzung zu den bisher schon verfügbaren Virtualisierungstechnologien im Windows-Umfeld werden. Insbesondere für produktive, sehr leistungsfähige Server und den parallelen Betrieb von Windows- und Linux-Infrastrukturen wird sie einige Bedeutung erlangen.
