Die wohl attraktivste Eigenart von Hyper-V ist die niedrige Einstiegsschwelle. Es beginnt mit dem Preis – sobald Sie Windows-Server-VMs auf Ihrer Virtualisierung ausführen, erhalten Sie den Hypervisor gratis dazu. Sind es mehr als elf VMs pro Host, lohnt sich bereits aus Sicht der VM-Lizenzierung die Datacenter Edition, die Ihnen gleichzeitig Zugriff auf fortgeschrittene Funktionen wie Storage Spaces Direct, Software-defined Networking, Shielded VMs und Hypervisor Based Activation eröffnet [1].

Erfahrene Windows-Administratoren profitieren von dem gewohnten Installationsverfahren, der breiten Hardwareunterstützung und der Möglichkeit, den bereits erworbenen Erfahrungsschatz in Verwaltung und Troubleshooting von Windows-Server-Systemen auch im Hypervisor-Bereich einzusetzen.

Für die Verwaltung von Hyper-V sieht Microsoft vier Ansätze vor:

1. Auf der Management Console (MMC) basierende Tools (Hyper-V Manager und Failover Cluster Manager).

2. Native PowerShell-Unterstützung von Hyper-V, Failover-Clustering, Storage Spaces Direct und Software Defined Networking.

3. Windows Admin Center (WAC), das für fast alle Funktionen der Hyper-V-Verwaltung PowerShell-Remoting und Remote-WMI verwendet.

4. System Center, insbesondere die beiden Komponenten Virtual Machine Manager (VMM) und Operations Manager (SCOM). Beide Anwendungen benutzen Agenten, die im Kontext des lokalen Systems jedes Hyper-V-Hosts laufen und so über die notwendigen Rechte verfügen, alle Operationen auf dem betreffenden Host durchzuführen.

Die auf System Center basierte Umgebung ist extrem aufwendig in Einrichtung und Betrieb, erlaubt dafür aber sowohl die Kontrolle über die Konfiguration der verwalteten Hosts und der darauf laufenden VMs als auch die laufende Überwachung ihrer Performance [2]. Administratoren, die keine Ressourcen – sei es personell, finanziell oder technisch – für die System-Center-Implementierung haben, müssen sich andere Lösungsansätze suchen.

Die Konfiguration des ersten Hyper-V-Hosts ist ein komplexer Vorgang, besonders wenn es sich um einen für Sie neuen Servertyp handelt und der Host Teil eines Clusters werden soll. Umso einfacher ist theoretisch die Einrichtung aller weiteren Hosts desselben Clusters, denn hier wollen Sie unbedingt dafür sorgen, dass die Konfigurationen und Softwarestände der Knoten im gleichen Cluster identisch sind. Die Konfiguration von Hyper-V-Servern erfolgt in den immer gleichen Etappen:

- Grundkonfiguration (Computername, Rollen und Features)

- Netzwerkkonfiguration (Adapterzuweisung, Teaming, IP-Adresse, DNS)

- Domänenmitgliedschaft

- Storage-Konfiguration (Anbindung, Formatierung, MPIO)

- Hyper-V-Einrichtung

- Einbinden in Cluster sowie Cluster-Konfiguration

Manchmal sind vor der Konfiguration von Windows noch Einrichtungsschritte an der Hardware notwendig – Konfiguration der Storage-Adapter, der Festplatten-Arrays, Aktivierung der Virtualisierungsfeatures im BIOS und so weiter. Ob sich diese Einstellung auch automatisieren lässt, hängt vom Hersteller und Modell des jeweiligen Servers ab. In diesem Artikel gehen wir davon aus, dass die Hardwarekonfiguration des Servers bereits Ihren Vorgaben entspricht.

Soll der Server die komplette Konfiguration durchlaufen, wird an einigen Stellen ein Reboot notwendig: Umbenennen der Maschine, Einbinden ins AD, Installation der Hyper-V-Rolle und Aktivieren von MPIO für iSCSI sind lediglich einige Beispiele. Daher muss Ihr Konfigurationsskript genug Intelligenz besitzen, um nach einem Reboot die Arbeit dort aufzunehmen, wo sie durch den Neustart unterbrochen wurde. Hierbei kommen in der Praxis folgende Ansätze zum Einsatz:

- Einstellungen händisch setzen, beispielsweise durch die Angabe der Konfigurationsphase beim Aufruf des Skripts. Hier müssen Sie, falls Sie mehrere Hosts gleichzeitig zu konfigurieren haben, den Überblick darüber behalten, welcher Host welche Phase bereits durchlaufen hat, um sich nicht zu verzetteln.

- Untersuchen der aktuellen Konfiguration bei jedem Aufruf und Beginn der Änderungen dort, wo die erste Abweichung festgestellt wurde. Auf diese Art und Weise wird die gewünschte Konfiguration schrittweise erzwungen.

- Verwenden von PowerShell Desired State Configuration (DSC), um die gewünschte Konfiguration zu erzwingen und auch in der Zukunft konstant zu halten.

Die ersten beiden Varianten stellen den imperativen Ansatz von Infrastructure-as-Code (IaC) dar, beim Einsatz von DSC sprechen wir vom deklarativen Ansatz.

Nutzen Sie viele Hyper-V-Hosts, deren Hardwareausstattung und gewünschte Konfiguration identisch ist, kann sich der Einsatz von DSC definitiv lohnen. Andernfalls rentiert sich die Investition in den Wissensaufbau vermutlich nicht, sofern Sie nicht bereits über Erfahrung in der Verwendung und im Troubleshooting von DSC verfügen.

Um ein Skript zu entwickeln, das Ihnen in Zukunft mit wenig Aufwand ermöglicht, neue Hosts zu konfigurieren und die Konfiguration bestehender Hosts auf ihre Korrektheit zu prüfen, müssen Sie neben dem PowerShell-Code dem Skript auch eine Konfigurationsbeschreibung beilegen. Dabei gilt es, drei Arten von Konfigurationseinstellungen zu betrachten:

1. Universelle Einstellungen, die für das gesamte Netzwerk gelten wie beispielsweise Subnetz-Definitionen, DNS-Server oder Domänennamen.

2. Modell- oder clusterspezifische Einstellungen wie die Zusammenfassung von bestimmten Netzwerkkarten zu Teams oder Storage-Pfaden.

3. Individuelle Servereinstellungen wie Computername oder IP-Adresse.

Oft genügt es, die modellspezifischen Einstellungen im individuellen Teil mitzugeben, um das Skript nicht zu verkomplizieren. Als Konfigurationsspeicher verwenden Sie am besten eine XML- oder JSON-Datei – je nachdem, welches Format Sie besser beherrschen. Am Anfang jeder Skriptausführung wird die Datei eingelesen. Tritt dabei ein Fehler auf (Datei fehlt, ist nicht lesbar oder hat einen Fehler in der Datenstruktur), muss das Skript abgebrochen werden. Ferner erfordern alle Operationen, die das Skript durchführt, eine Ausführung mit erhöhten Rechten. Dies sollten Sie gleich am Anfang erzwingen:

Die Zuordnung einer Serverkonfiguration sollte am besten anhand der Seriennummer erfolgen. Zum einen ist es die einzige unveränderliche Konstante, zum anderen sind bei den meisten Herstellern die Seriennummern der zu liefernden Server bereits vor der Auslieferung bekannt, sodass Sie die Konfigurationen in Ruhe vorbereiten können, bevor die neuen Server eintreffen. Die Struktur der XML-Datei für das obige Beispiel könnte also wie folgt aussehen:

Um den richtigen Server zu identifizieren, hilft der folgende Code:

Ist die Konfiguration vorhanden, kann das Skript fortfahren. Zunächst einmal checken wir, ob der Server bereits den richtigen Namen hat und ob die Hyper-V-Rolle installiert ist. Beide Operationen erfordern einen Neustart, können aber in einem Aufwasch durchgeführt werden:

Die Managementtools benötigen wir in diesem Szenario zwingend, weil das Skript im weiteren Verlauf davon Gebrauch machen wird, um den Host zu konfigurieren.

Zwei weitere Features, die Sie gleich am Anfang hinzufügen können, sind Multipath-I/O (MPIO) und Failover-Clustering. Allerdings werden sie nicht immer benötigt – bei Standalone-Hosts, lokalen Festplatten oder bei SMB-Freigaben als Hyper-V-Storage spielt Clustering beziehungsweise MPIO natürlich keine Rolle. Daher müssen Sie die Angaben für diese Features im serverspezifischen Teil der Konfiguration eintragen:

Das Kürzel "RR" steht hier für "Round Robin" und entspricht der standardmäßigen MPIO-Richtlinie des zukünftigen Hosts.

Sie können den Block für das Ergänzen jedes fehlenden Features nach dem obigen Muster hinzufügen oder intelligenter vorgehen und die Namen der benötigten Features zuerst in ein Array sammeln, um dieses dann als Argument an "Install-WindowsFeature" zu übergeben. Für Failover-Clustering würde der Code beispielsweise wie folgt aussehen:

Das Networking ist der wohl am schwierigsten zu konfigurierende Teil eines Virtualisierungshosts. Das gilt übrigens nicht nur für Hyper-V, sondern trifft auf jeden Hypervisor zu. Die Palette der möglichen Topologien reicht von einem "Edge-Hypervisor" mit zahlreichen physischen Adaptern, die in verschiedene Netze gepatcht sind, bis zum "Converged Networking", wo ein einziges Paar von Hochleistungs-Netzwerkkarten als Team die gesamte Kommunikation des Hosts besorgt, inklusive Management und Storage-Anbindung. In diesem Fall müssen Sie für jeden Verwendungszweck einen dedizierten virtuellen Netzwerkadapter erstellen und mit Bandbreiten-Beschränkungen dafür sorgen, dass für IP-basierten Storage-Zugriff und Livemigration immer genug Reserve vorhanden ist.

Anders als bei manueller Bereitstellung, ist das konvergente Netzwerk tatsächlich am einfachsten zu scripten, denn es entfällt der Teil der Konfiguration, der die menschliche Intelligenz am meisten fordert – die Zuordnung der Netzwerkkarten zu ihren jeweiligen Verwendungszwecken. Je nach vorhandenen Servermodellen ist die Erkennung der für das konvergente Networking benötigten NICs maximal einfach und fällt unter eine der fünf Regeln:

1. Alle vorhandenen Adapter verwenden (beispielsweise bei Blade-Servern, die nur eine Mezzanine-Karte mit zwei virtuellen Ports haben).

2. Alle gepatchten Adapter verwenden, also diejenigen, die den Status "Up" aufweisen. Das ist beispielsweise bei Servern der Fall, in denen 10/100-GBit- und 1-GBit-Adapter verbaut sind, aber nur die schnellen Karten tatsächlich verwendet werden sollen.

3. Alle Adapter mit einer bestimmten Geschwindigkeit verwenden. Das ist beispielsweise dann nützlich, wenn weitere aktive Netzwerkadapter existieren, die jedoch nicht zum Einsatz kommen sollen, wie beispielsweise die virtuelle 100-MBit/s-Karte, die HPE iLO dem Betriebssystem präsentiert.

4. Alle Adapter eines oder mehrerer bestimmter Modelle verwenden. Diese Art der Netzwerkkarten-Bestimmung hilft dann, wenn die Server noch ungepatcht grundkonfiguriert werden müssen. Allerdings kann die Konfiguration ohne funktionierendes Netzwerk nicht abgeschlossen werden – Schritte wie Beitritt zur AD-Domäne, Bildung eines Clusters oder Anbindung von iSCSI-LUNs werden zwangsläufig scheitern.

5. Alle Adapter verwenden, auf denen eine bestimmte VLAN-ID konfiguriert wurde. Auch hier ist eine "Offline-Einrichtung" bis zu einem bestimmten Punkt möglich.

Sind die richtigen Netzwerkkarten identifiziert, kann der einzige benötigte vSwitch erstellt und die Adapter diesem als Uplink hinzugefügt werden. Mit modernen Windows-Server-Versionen kommt dabei meistens Switch Embedded Teaming (SET) [3] zum Einsatz. Haben Sie in Ihrem Netzwerk die Anforderung, das herkömmliche Netzwerkkarten-Teaming (LBFO) zu verwenden (beispielsweise um LACP zu ermöglichen), können Sie dies bis inklusive Windows Server 2025 ebenfalls durchführen.

Allerdings steht dieses Feature in Verbindung mit Hyper-V auf der Abkündigungsliste, sodass Sie rechtzeitig mit Ihrem Netzwerkteam sprechen sollten, um das Switch Independent Teaming (das einzige von SET unterstützte Teaming-Verfahren) zu ermöglichen. Und auch an der PowerShell benötigen Sie den "geheimen" Parameter "-AllowNetLbfoTeams $true", um einen vSwitch mit einem LBFO-Team als Uplink anzulegen.

Deutlich komplexer ist eine gescriptete Abbildung von Netzwerk-Konstellationen, die für einen Menschen viel intuitiver sind und leichter von der Hand gehen. Ein herkömmlicher Virtualisierungshost hat typischerweise viele physische Netzwerkschnittstellen, die in verschiedene Netzwerke gepatcht oder zumindest mit verschiedenen VLANs versehen sind. Anders als ein menschlicher Administrator kann Ihr Skript nicht auf die Serverrückseite schauen und einfach anhand von Kabelfarben oder Beschriftungsfähnchen feststellen, welche der acht modellgleichen Netzwerkkarten in das Management-, iSCSI- oder DMZ-Netzwerk verbinden soll.

Ist dieser Fall bei Ihnen üblich, sollten Sie erwägen, einen manuellen Zwischenschritt in der Einrichtung Ihrer Hyper-V-Hosts einzulegen und den Netzwerkkarten in Windows Namen zu geben, die ihrem Einsatzzweck oder dem verbundenen VLAN entsprechen. Anhand dieser Namen kann das Skript die korrekten Adapter sehr einfach identifizieren. Alle verfügbaren physischen Netzwerkadapter erhalten Sie mit Get-NetAdapter -Physical. Der in Windows sichtbare Adaptername ist in der Eigenschaft "Name" enthalten, das Modell des Adapters ist in "DriverDescription" zu finden.

Um die IP-Konfiguration abzurufen, übergeben Sie ein NetAdapter-Objekt oder eine Interface-ID an: Get-NetIPConfiguration. Dort finden Sie auch Angaben zu den eventuell eingestellten DNS-Servern. Um diese anzupassen und die automatische Registrierung im DNS für alle Interfaces außer Management zu deaktivieren, verwenden Sie die Cmdlets "Set-DnsClient" und "Set-DnsClientServerAddress". Sind mehrere Adapter zu einem herkömmlichen Team zusammengefasst, helfen die Cmdlets "Get-NetLbfoTeam" und "Get-NetLbfoTeamMember", das richtige Team zu identifizieren.

Danach erhalten Sie mit Get-NetLbfoTeamNic die virtuelle Team-Netzwerkkarte, mit der Sie in Bezug auf die IP-Konfiguration genauso verfahren können, wie mit einem physischen Netzwerkadapter. Ein neues Team erzeugen Sie mit:

Falls ein Adapter, der zu einem LBFO-Team hinzugefügt werden soll, eine statische IP-Konfiguration aufweist, kann es zu Nebeneffekten kommen. Ihr Skript sollte solche Konfigurationen daher bereinigen, was nur funktioniert, bevor der Adapter Teil des LBFO-Teams wurde.

Ist die zu konfigurierende Schnittstelle virtuell und an einen vSwitch angebunden, erhalten Sie diese mit dem Befehl:

Um physische Adapter zu einem SET-fähigen vSwitch zusammenzufassen und einen virtuellen Host-Adapter anzulegen, verwenden Sie:

Mit der korrekten Auswertung der bestehenden Konfiguration und deren Überführung in den gewünschten Zustand werden Sie vermutlich die meiste Zeit zubringen. Wenn in Ihrer Organisation klare Spielregeln in Bezug auf mögliche Netzwerkkonfigurationen der Hyper-V-Hosts herrschen, können Sie hier natürlich eine Abkürzung nehmen und nur die Fälle behandeln, die bei Ihnen tatsächlich auftreten können.

Ist die Netzwerkkonfiguration abgeschlossen, kann der neue Host der AD-Domäne und eventuell einem FailoverCluster beitreten. Widerstehen Sie dabei der Versuchung, Anmeldedaten für diese Vorgänge im Skript zu speichern. Da das Skript auf einem beliebigen neuen Server laufen muss, ist jede Verschlüsselung dieser sensitiven Daten allenfalls eine Verschleierung. Gerät Ihr Skript in falsche Hände, haben Sie das Admin-Kennwort verraten.

Bauen Sie deshalb lieber eine Abfrage mit "Get-Credential" in Ihr Skript ein. Verwenden Sie dabei unbedingt den Parameter "-Message" und formulieren Sie eine sehr deutliche Mitteilung, damit Ihr legitimer Wunsch nach hochprivilegierten Anmeldedaten sich klar von jeder anderen Credentials-Abfrage unterscheiden lässt. Den Domänenbeitritt selbst bewirken Sie mithilfe des Cmdlets "Add-Computer" [4]. Hier können Sie auch die OU übergeben, in der das neue Computerobjekt erstellt werden soll.

Auf den Domänenbeitritt muss zwingend ein Neustart folgen. Um das Skript nach dem Reboot noch einmal zu starten, müssen Sie sich interaktiv anmelden. Es bietet sich an, dafür ein Domänenkonto zu verwenden, das sowohl lokale Administratorberechtigungen auf dem neuen Server hat als auch das Recht, ihn dem vorgesehenen Cluster hinzuzufügen. In diesem Fall können Sie sich die Abfrage expliziter Anmeldedaten zum Cluster-Beitritt sparen.

Vor dem Beitritt sollte Ihr Skript sich mittels Get-Cluster [5] vergewissern, dass es das Cluster überhaupt gibt. Geben Sie dabei die Domäne an, damit lediglich die Cluster-Namen ausgelesen werden, und gleichen diese Liste mit dem Zielnamen ab. Existiert der Cluster noch gar nicht, muss es angelegt werden – es sei denn, Sie erzeugen so oft Virtualisierungscluster, dass es sich lohnt, auch diesen Schritt zu automatisieren. Zudem sollte das Skript bestehende Cluster-Knoten auslesen und den möglichen Beitritt mittels Test-Cluster [6] validieren. Dabei können Sie einige Checks überspringen wie beispielsweise Storage oder Patchstand.

Sind alle Voraussetzungen gegeben, kann der neue Host mittels Add-ClusterNode dem Cluster beitreten. Falls Ihr Hyper-V-Cluster bereits produktiv eingesetzt wird, ist dort vermutlich die Lastverteilung aktiv. Tritt ein neuer Host dem Cluster bei, kann es passieren, dass die Lastverteilung versucht, VMs darauf zu verschieben, noch bevor die Konfiguration finalisiert ist. Daher sollten Sie auf einen erfolgreichen Cluster-Beitritt vorerst den Befehl Suspend-ClusterNode folgen lassen und die Freischaltung des neuen Knoten nach endgültiger Kontrolle manuell durchführen.

Denken Sie daran, dass Ihr Skript, sofern Sie der beschriebenen Vorgehensweise folgen, ab dem Domänenbeitritt in einem anderen Benutzerkontext als zuvor ausgeführt werden wird. Sie sollten das Skript daher an einem benutzerneutralen Ort (beispielsweise "C:\TEMP") ablegen und alle Dateien wie Logs oder Konfigurationsexporte, die das Skript eventuell erzeugt, außerhalb des Benutzerprofils erzeugen.

Die Verwaltung von Storage in Windows mittels PowerShell zeigt unser Sonderheft-Artikel "Windows-Server-Storage mit der PowerShell automatisieren" [8]. Alle diese Techniken können auch bei der Bereitstellung von Hyper-V-Hosts zum Einsatz kommen. Bei der Einbindung von iSCSI-LUNs gibt es zwei Besonderheiten, die Sie in Ihrem Workflow abbilden müssen:

1. Der automatisch erzeugte Initiator-IQN in Windows ist so lang, dass manche Storage-Systeme nur die ersten sechs Zeichen des Computernamens behandeln können. Heißen Ihre Hyper-V-Server "HVHOST001", "HVHOST002" und so weiter, kann es passieren, dass Ihr SAN immer den gleichen IQN sieht und die LUN-Reservierungen nicht erfolgreich den Besitzer wechseln können.

2. Der IQN wird dem SAN erst mitgeteilt, wenn die Netzwerk-Konfiguration abgeschlossen ist und das Portal erstmalig kontaktiert wurde. Danach muss unter Umständen ein SAN-Administrator die erforderlichen LUNs erst für den neuen IQN freigeben oder diesen zu einer Initiatorgruppe hinzufügen.

Beiden Phänomenen können Sie begegnen, indem Sie den IQN im Zuge der Provisionierung auf einen vorher vereinbarten, ausreichend kurzen Wert setzen. Dann kann der SAN-Administrator diesen IQN bereits auf die richtigen LUNs berechtigen, und die Inbetriebnahme des neuen Hosts klappt reibungslos.

Je mehr Sorgfalt Sie bei der Entwicklung Ihres Host-Konfigurationsskripts oder der entsprechenden DSC-Definitionen haben walten lassen, desto einfacher gelingt es Ihnen, die Konfiguration konstant zu halten. Sehen Sie in Ihrem Skript einen reinen Testmodus vor, der Abweichungen von der gewünschten Konfiguration nur feststellt und an die Konsole ausgibt, aber nicht gleich behebt. Mit DSC haben Sie den Testmodus bereits inklusive – das Cmdlet Test-DscConfiguration [7] liefert Ihnen den Compliance-Status, bevor Sie die Konfiguration mit Start-DscConfiguration noch einmal verbindlich anwenden.

Natürlich können Sie für die Konfigurationsprüfung auch ein komplett separates Skript erstellen. Dieses wird jedoch große Überschneidungen mit dem Konfigurationsskript aufweisen, was den Pflegeaufwand deutlich erhöhen dürfte. Eventuell ist sogar die Entwicklung eines eigenen Moduls sinnvoll, das zwei Befehle exportiert (Konfiguration und Test), intern jedoch auf einen Satz gemeinsamer privater Funktionen zurückgreift. Der Testmodus in einem Skript hat allerdings den zusätzlichen Mehrwert, dass sich damit Fehler abfangen lassen, die bei der Interpretation der Konfigurationsdatei und beim Vergleich mit dem vorhandenen Zustand des Servers auftreten können.

Zwei Beispielskripte inklusive der dazugehörigen XML-Dateien können Sie in unserem Downloadbereich [9] herunterladen. Diese können als Ausgangspunkt für Ihr eigenes Provisionierungsskript dienen.

Ist ein Hyper-V-Host oder -Cluster betriebsbereit, ist es wichtig zu wissen, dass die Performance der dort ausgeführten virtuellen Maschinen den Erwartungen entspricht. Damit Sie den Überblick über die Ressourcenverwendung von VMs oder Gruppen von VMs behalten, bietet Ihnen Hyper-V das "Resource Metering". Die Daten liefert Ihnen das Cmdlet Measure-VM [10]. Damit Ihr Host Performancedaten über eine bestimmte VM sammelt, müssen Sie allerdings zuerst die Datensammlung mit Enable-VMResourceMetering [11] aktivieren.

Standardmäßig beträgt das Berichtsinterval – der Zeitraum also, über den die Performancedaten gemittelt und die Maximalwerte ermittelt werden – eine Stunde. Sie können ihn mit dem Parameter "-ResourceMeteringSaveInterval" des Cmdlets Set-VMHost verkürzen oder verlängern. Dieser Befehl kann auch Teil Ihres Provisionierungsskripts werden, falls Sie bereits einen optimalen Wert für Ihre Datensammlung herausgefunden haben. Falls Sie an Performancedaten einer Gruppe von VMs interessiert sind, können Sie diese zu einem "Resource Pool" zusammenfassen. Anders als bei einigen anderen Virtualisierungsprodukten, dienen Ressourcenpools in Hyper-V ausschließlich der Sammlung von Performancedaten. Ein Pool bezieht sich immer auf eine konkrete Auswahl der zu überwachenden Ressourcen. Sie können also beispielsweise nur das Monitoring des Arbeitsspeichers für eine Gruppe von VMs aktivieren.

Hyper-V-Hosts funktionieren am besten, wenn ihre Konfigurationen optimal erstellt und dauerhaft eingehalten werden. Vor allem sind identische Vorgaben innerhalb eines Clusters wichtig. In größeren Umgebungen hilft PowerShell DSC, die Servereinstellungen auf dem gleichen Stand zu halten. Falls der Einsatz von DSC zu aufwendig für Ihren konkreten Fall erscheint, können Sie mittels herkömmlicher PowerShell-Skripte den gewünschten Zustand ebenfalls erzwingen. Und auch bei der Performanceüberwachung kann die PowerShell sehr gut helfen, wenn Sie nicht über spezialisierte Tools verfügen.