Virtual Machine Manager von Microsoft

Johann Baumeister ist Diplominformatiker und freier Autor. Er testete den VMM für unsere deutsche Schwesterzeitschrift Computerwoche.

Unter dem Sammelbegriff «System Center» fasst Microsoft seit rund zwei Jahren ihre System Management Tools zusammen. Zu den jüngsten Elementen zählt der Virtual Machine Manager (VMM) für die Verwaltung virtueller Maschinen. Bisher beschränkte sich diese Disziplin allein auf jene virtuellen Maschinen, die durch Microsofts «Virtual Server» erzeugt und unter ihm ausgeführt wurden. Über die Kombination von VMM mit dem im Februar lancierten Windows Server 2008 will Microsoft mit Hyper-V ab Sommer eine zweite Virtualisierungsumgebung bereitstellen. Sie ist an den Hypervisor-Konzepten des ESX-Server von VMware angelehnt und soll Redmond weitere Anteile im vielversprechenden Virtualisierungsmarkt sichern. Aktuell spielt Microsoft gegenüber VMware allerdings noch eine Nebenrolle. Künftig aber wird zur Verwaltung virtueller Instanzen und Infrastrukturen mit Windows Server 2008 und dessen Hypervisor auch der Virtual Machine Manager herangezogen. Damit avanciert Letzterer zu einem zentralen Verwaltungs-Tool für die Servervirtualisierung.

Für den Test kam die aktuelle, erste Version von VMM zum Einsatz, als Virtualisierer wurden zwei getrennte Host-Systeme mit Virtual Server 2005 verwendet. Die Architektur des VMM gliedert sich in die gängigen Komponenten: Zum einen der VMM-Server, eine Datenbank, in der VMM seine Konfigurationen ablegt, ferner die Verwaltungskonsole sowie ein Portal, über das Benutzer virtuelle Maschinen in Eigenregie verwalten können. Die Trennung des Servers von seiner Verwaltungsumgebung soll die Fernwartung des Systems über eine separate Konsole ermöglichen. Falls nötig, kann die Verwaltungskonsole auch zusammen mit dem VMM-Server auf einem Rechnersystem laufen. Diese Konstellation wurde für den Test gewählt.

Der VMM umfasst Funktionen zur Konfiguration des Hosts und bietet einen Assistenten für die Wahl des passenden Hosts. Hinzu kommen eine Bibliothek für virtuelle Images und alle für die Erzeugung und Verwaltung virtueller Maschinen nötigen Basisfunktionen. Mit an Bord sind eine Reihe Verwaltungsobjekte für das Monitoring und Reporting. Als Rechnerbasis zur Ausführung der virtuellen Maschinen kennt der VMM Hosts, die sich auch zu Gruppen (Host Groups) bündeln lassen. Die virtuellen Maschinen wiederum werden auf den Hosts platziert. Eine Host-Gruppe stellt aber lediglich eine Verwaltungseinheit für die virtuellen Maschinen dar. Ein automatischer Lastausgleich oder Failover, ähnlich wie es VMware mit VMotion anbietet, findet nicht statt.

Das bedeutet nicht, dass Microsoft keine Funktionen zur Lastverteilung anbietet, diese sind nur anders umgesetzt. Die Windows-Betriebssysteme bieten schon seit mehreren Jahren Cluster-Funktionen mit Balancing, weshalb bei Microsoft die Lastverteilung über das OS und nicht im Virtualisierungs-Tool erfolgt.

Die Hosts, ihre Gruppierung in Host-Gruppen und die virtuellen Maschinen stellen die aktiven Elemente zur Laufzeit dar. Die Umsetzung aller Aktionen erfolgt im Zuge von Jobs. Dabei handelt es sich um Skripte, die in der PowerShell erstellt wurden.

Die Ausrichtung an der PowerShell ist eine der grundsätzlichen konzeptionellen Neuerungen, die Microsoft vor wenigen Jahren begonnen hat. Sie bedeutet, dass alle neuen Server und Verwaltungssysteme mit einer API für die PowerShell ausgestattet werden. Über diese Schnittstelle erfolgt auch die Verwaltung des jeweiligen Servers. Die grafischen Tools generieren in dieser Konstellation immer nur PowerShell-Skripte.

Analog verhält es sich auch mit der VMM-Konsole. Die Skripte werden von den Assistenten der VMM-Konsole aufgebaut und dann als Jobs abgearbeitet, was letztendlich zu einer weitaus höheren Flexibilität führt. Einerseits entkoppelt dieses Verfahren den Aufbau der Kommandofolgen durch das GUI von der späteren Abarbeitung. Zweitens stellt VMM diese Skripte dem Admini-strator zur Verfügung. Dieser kann sie sodann nach eigenem Gusto variieren, als Grundlage für eigene Batch-Läufe heranziehen und sich so einen Fundus an Verwaltungsskripten aufbauen.

Die Gliederung des VMM in mehrere Komponenten findet sich analog bei den Installationsoptionen, die ein Setup des Server-Systems, der Verwaltungskonsole und eines Self-Service-Portals unterscheiden. Daneben steht der Virtual Server als eigentliche Ausführinstanz für die virtuellen Maschinen und künftig auch für den Hyper-V beziehungsweise Windows Server 2008. Der VMM fungiert dabei als verwaltende Konsole, die via APIs die Virtualisierungs-Engines überwacht und steuert.

In den Virtual Server eingebettet sind wie bisher die virtuellen Maschinen. Als Basissystem für den VMM-Server wird Windows Server 2003 mit dem SP1 sowie die Windows-Remote-Verwaltung (WinRM) verlangt. Letztere lässt sich, falls nicht vorhanden, von der Microsoft-Website beziehen. Sind diese Voraussetzungen erfüllt, gibt es für die Bereitstellung und Konfiguration des VMM keine besonderen Anforderungen. Im Testszenario wurde die VMM-Konsole in einer virtuellen Instanz eines Windows Server 2003 ausgeführt. Der Basisrechner bestand ebenfalls aus Windows Server 2003 SP1 und dem darauf installierten Virtual Server R2. Er diente gleichzeitig auch als Host-System für weitere virtuelle Maschinen.

Zur Kommunikation mit dem Virtual Server oder auch dem Library Server benötigt der VMM einen Agenten. Dieser wird bei der Bereitstellung eines Hosts automatisch mit eingerichtet. Ferner wird auf diesem Rechner, falls der Virtual Server noch nicht besteht, auch dieser mit installiert. Im Test gab es zwei Host-Systeme als Ausführinstanzen für die virtuellen Maschinen, die Bereitstellung und Integration der Hosts in die VMM-Verwaltungsinfrastruktur war einfach zu bewerkstelligen. Die bereits auf dem Host vorhandenen virtuellen Maschinen wurden korrekt erkannt und integriert.

Für den Aufbau neuer virtueller Maschinen stellt Microsoft, wie auch für alle weiteren Aktionen, Assistenten bereit. Diese fragen in einem mehrstufigen Dialog die benötigten Einstellparameter ab, generieren am Ende die Skripte und erledigen die ihnen zugedachten Aufgaben. Zur Verwaltung der VMs stehen die Operationen Erzeugen, Löschen, Verschieben oder Kopieren von virtuellen Maschinen bereit. Die VMs lassen sich ferner von physischen Rechnern migrieren oder aus einem ISO-Image, einer Vorlage (Template), einer VHD-Datei beziehungsweise einer bestehenden virtuellen Maschine ableiten. Im Rahmen des Dialogs wählt der Administrator die passenden Optionen aus. Hierzu zählen die Hardwareeinstellungen für die virtuellen Festplatten, die Netzkarten sowie Angaben zur CD/DVD-Nutzung, Diskette und ähnliche Peripheriebausteine. Einstellbar ist auch eine relative CPU-Nutzung im Verhältnis zu allen anderen VMs auf diesem Host. Eine so erzeugte VM lässt sich direkt starten und ausführen. Sie kann aber auch in einer Bibliothek hinterlegt werden, wo sie für weitere Abbilder bereitsteht, die sich auf diesen Bibliothekseintrag beziehen.

Bei der Platzierung einer erzeugten VM sollte natürlich der optimal geeignete Host gewählt werden. Diese Zuordnung kann der Administrator nach eigenen Wünschen vornehmen, oder er greift auf die Unterstützung des VMM zurück. Dieser liefert ihm einen Vorschlag zur bestmöglichen Platzierung der VM hinsichtlich der geforderten Ressourcen wie Hauptspeicherbedarf, Netz- und IO-Last sowie CPU-Nutzung. Diese Vorschläge kann der VMM allerdings nur dann unterbreiten, wenn er das Lastverhalten der neuen virtuellen Maschine kennt oder einschätzen kann. Für neu zu erzeugende VMs müssen diese Angaben daher vom Administrator kommen. Das Vorschlagsverfahren wird aber nicht nur bei der Neuanlage von VMs angewandt, es kommt auch bei der Migration physischer Rechnersysteme in virtuelle Umgebungen zum Einsatz. In diesem Fall kann der VMM durch die Beobachtung des Lastverhaltens passende Vorschläge unterbreiten.

Die Nutzung der VMM-Konsole ist in erster Linie für den IT-Verwalter gedacht. Er benötigt dazu die notwendige Software und die passenden Berechtigungen. Um eine abgestufte Verwaltung zu erreichen, sind Rollen zu definieren. Ferner kann die Konsole für die jeweiligen Bearbeiter angepasst werden. Daneben stellt Microsoft mit dem Self-Service-Portal die Verwaltungsfunktionen auch für weitere, berechtigte Nutzer der VMs bereit. Insbesondere für Testszenarien oder in der Softwareentwicklung lassen sich so eigene Systeme aufbauen und verwalten. Die Berechtigungen dazu sind direkt an die Organisationseinheiten und Benutzer des Active Directory gebunden. Dabei ist zu bestimmen, was die berechtigten Personen dürfen, und was nicht. Neben Starten und Stoppen der VMs sind das unter anderem die Funktionen zum Pausieren einer VM oder zum Setzen von Checkpoints. Damit die berechtigten Benutzer die Ressourcen des Hosts nicht über das ihnen zugedachte Mass hinaus beanspruchen, lassen sich Grenzen (Quotas) definieren.

Mit dem Self-Service-Portal stehen auch die Templates und Bibliotheken zur Verfügung. In Templates werden Vorlagen für die VM hinterlegt, auf die dann sehr schnell zugegriffen werden kann. Ein Template stellt aber immer nur das Grundgerüst für eine VM dar. Deren Detailkonfiguration, die Personalisierung des Systems, muss noch vorgenommen werden. Hierzu gehören etwa die Einstellungen zum Rechnernamen, der IP-Adressen oder auch der Security-IDs der Rechner. Diese Schritte werden heute häufig durch SYSPREP-Aktionen vorgenommen. SYSPREP kann auch in den Ablauf der VMM-Scripte integriert und damit automatisiert werden.

Mit dem Virtual Machine Manager hat Microsoft in seiner Virtualisierungsstrategie einen grossen Schritt nach vorne getan. Das Tool stellt alle Funktionen für die umfassende Verwaltung virtueller Serversysteme bereit und erlaubt eine einfache Administration virtueller Maschinen. Diese können im Kontext des Virtual Server und nun auch mit dem Windows Server 2008 ausgeführt werden. Ferner soll mit dem Hyper-V demnächst eine weitere Variante für virtuelle Infrastrukturen zur Verfügung stehen.

Weitere Informationen

Der Microsoft System Center VMM wurde auf einem Rechnersystem mit Windows Server 2003 SP1 installiert. Das Betriebssystem war wiederum selbst Gast eines Virtual Server 2005 R2, der als Basis-Betriebssystem Windows Server 2003 SP1 verwendete. Das Basis-OS und der darauf befindliche Virtual Server 2005 wurden aus dem VMM heraus verwaltet. Daneben wurde ein weiterer Rechner mit Windows Server 2003 SP1 und dem Virtual Server 2005 als Host-System eingesetzt. Sie wurden aus der Gastinstanz über eine Netzwerkbrücke verwaltet. Als Netzwerk diente ein gemischtes System mit Fast-Ethernet- und Gigabit-Ethernet-Baugruppen.

Die Verteilung der virtuellen Maschinen erfolgte auf die beiden Hosts. Als Speichermedien für die virtuellen Disks und zur Ablage der virtuellen Maschinen wurden sowohl die lokalen DAS-Platten der Host-Systeme als auch ein -separates iSCSI-System verwendet.

Der iSCSI-Speicher beruhte auf dem Windows Unified Data Storage Server, einer Windows-Server-2003-Variante zur Datenspeicherung. Der Domänen-Controller wurde ebenfalls in einer eigenen virtuellen Maschine ausgeführt.