Hyper-V: Notizen und Best Practice

Hier einige Notizen und Best-Practice-Informationen zum Einrichten und Betreiben von Hyper-V unter Windows Server 2008. Alle Angaben sind natürlich ohne Gewähr. Insbesondere bei Performance- und Optimierungsempfehlungen sind immer weitere Analysen nötig.

Die Angaben setzen sich aus offiziellen Empfehlungen (z.B. relevant für die Zertifizierungsprüfung) und ersten Erfahrungen aus größeren Projekten zusammen.

Detaillierte Informationen zu den Einrichtungs-Themen finden sich z.B. hier:

[Download details: Hyper-V Planning and Deployment Guide]
http://www.microsoft.com/Downloads/details.aspx?FamilyID=5da4058e-72cc-4b8d-bbb1-5e16a136ef42&displaylang=en

Hardware, Sizing und Ersteinrichtung

• Hyper-V unterstützt aktuell bis zu 24 Cores auf bis zu vier physischen CPUs. Da wir sicher bald CPUs mit mehr als sechs Cores sehen werden, wird es Patches geben, die diese Grenze nach oben verschieben.
• Moderne CPUs (z.B. i7) unterstützen das Umschalten zwischen VMs besser als ältere. Bei performancekritischen Systemen oder Hosts, die viele VMs beherbergen sollen, empfiehlt sich also eine CPU der jeweils neuesten Generation.
• Für das CPU-Sizing gibt es eine Faustregel: Pro “realem” CPU-Core kann man drei “virtuelle” CPUs (vCPU) einplanen. Zwei vCPUs sollte man dabei stets für die Parent Partition reservieren, den sie muss den gesamten I/O-Verkehr abhandeln und kann sonst leicht zum Flaschenhals werden.
  Achtung: Bestimmte Systeme verlangen eine “konservativere” Planung (z.B. Exchange: hier sollte man 1,5 bis 2 vCPUs pro Core rechnen), und einzelne Applikationen werden nur mit einer 1:1-Zuordnung von ihren jeweiligen Herstellern supportet (kann z.B. für SAP gelten).
• Die für Hyper-V nötigen Funktionen sind auf einem neuen Server oft im BIOS noch nicht aktiviert. Zuerst sollte man also nach dem letzten BIOS-Update des Herstellers Ausschau halten. Wenn man dann die Virtualisierungs-Unterstützung im BIOS einschaltet, muss man hinterher den Server ganz ausschalten (CPU stromlos) und erst dann neu starten, denn nur mit einem “Warm Reboot” funktioniert das Umschalten meist nicht.
• Der Host unterstützt bis zu 1 TB physischen RAM (wobei reale Hardware derzeit “nur” 256 GB ermöglicht).
• Hyper-V muss den Arbeitsspeicher fest den VMs zuweisen. Ein Überbuchen (Overcommit, bei VMware als “Ballooning” bezeichnet) ist bei laufenden VMs nicht möglich – wenn man versucht, eine VM zu starten, deren RAM-Zuweisung den noch verfügbaren Arbeitsspeicher überschreitet, startet diese nicht.
• Für die Parent Partition sollten stets 2-4 GB Arbeitsspeicher übrig bleiben. Hyper-V lässt zwar eine geringere Ausstattung zu, aber dies wird schnell zum Flaschenhals, eben weil die Parent Partition an allen I/O-Vorgängen beteiligt ist.
• Als allgemeine Faustregel (auch bei physischen Servern) hat sich eine 30-Prozent-Reserve beim Arbeitsspeicher bewährt.

Netzwerk-Hardware

• Für einen alleinstehenden Host empfiehlt es sich, mindestens vier Netzwerkports einzuplanen, um das Teaming sinnvoll zu nutzen. Davon sollte ein Port bzw. Team exklusiv der Parent Partition (also der Verwaltungs-VM) zur Verfügung stehen, um die VMs vom Host sinnvoll trennen zu können.
  Beim Clustering sollten es, um den Heartbeat redundant zu unterstützen, sechs sein. Läuft der Cluster oder der Host mit iSCSI-Storage, sind mindestens zwei weitere Ports einzuplanen, um den iSCSI-Datenverkehr separat behandeln zu können.
  Mehr hierzu:[Microsoft Support Policy for NIC Teaming with Hyper-V]
  http://support.microsoft.com/?kbid=968703

  [Cheng’s Random Thoughts on System Management : NIC teaming and VMM]
  http://blogs.technet.com/chengw/archive/2009/02/26/nic-teaming-and-vmm.aspx

• Windows Server 2008 unterstützt keine 100-Mbit-NICs mehr.  (Dieser Hinweis ist nicht korrekt.)
• NICs mit 10 Gbit können durchaus sinnvoll sein, weil der Host dann den Netzwerk-I/O schnell abhandeln kann – sofern RAM und CPU für die Parent Partition ausreichend dimensioniert sind.
• Gast-VMs können bis zu 8 “synthetische” (also auf reale NICs gemappte) und zusätzlich bis zu vier “Legacy”-Netzwerkkarten zugewiesen bekommen. Im Host selbst gibt es keine technische Beschränkung (außer natürlich der Hardware-Ausstattung).

Storage

• Der Engpass beim Sizing ist meist der Disk-I/O. Hier empfiehlt sich also eine Analyse und die Nutzung einer möglichst leistungsfähigen Storage-Konfiguration.
• VMs könnten technisch betrachtet zwar auf CIFS-Netzlaufwerken abgelegt werden, dies ist aber nicht supportet.
• In Hyper-V-Clustern sollte es pro VM eine eigene LUN geben, denn der Failover-Cluster kann immer nur ganze LUNs schwenken. Liegen mehrere VMs in derselben LUN, müssen diese immer gemeinsam von einem Host auf den anderen wechseln (sowohl beim Failover als auch bei der Quick Migration).
  Diese Einschränkung lässt sich erst mit Windows Server 2008 R2 überwinden.
• iSCSI-HBAs sind für Hyper-V auch im Cluster supportet. Dabei arbeiten deren Treiber mit dem Windows-eigenen iSCSI Initiator zusammen.

Host-Einrichtung

• Das Zuweisen der Rolle “Hyper-V” über den grafischen Server-Manager öffnet auch gleich die nötigen Firewall-Ports. Bei einer Installation in Server Core geschieht dies jedoch nicht! In diesem Fall müssen die Ports mit einem netsh-Kommado (oder remote) explizit geöffnet werden.
• Wer Hyper-V-Hosts über Sysprep oder WDS massenhaft bzw. automatisiert ausrollen möchte, sollte das Sysprep ausführen, bevor er die Rolle Hyper-V zuweist. Anderenfalls kann Hyper-V nach dem Booten des neuen Hosts die Konfigurationsdatenbank nicht öffnen, weil sie noch den Namen des ursprünglichen Systems trägt und nicht den neuen.
• Hyper-V kann zu Testzwecken auch als VM installiert werden! Dann ist es allerdings nicht möglich, VMs zu starten. Man kann dann also nur die Managementfunktionen testen.
• Die Parent Partition sollte in SAN-Umgebungen eine eigene LUN erhalten, weil sie den gesamten I/O aller VMs steuert. Auf diese Weise entsteht kein zusätzlicher Leistungsverlust.
• Richtet man Hyper-V auf einem Core-Server ein, so steht die PowerShell nicht zur Verfügung. Arbeitet man aber mit dem Virtual Machine Manager und installiert dessen Agent auf dem Core-Server, so sorgt der Agent für die Umsetzung von PowerShell-Kommandos.

Host-Clustering

• Wer Hyper-V clustern möchte, muss auf allen Nodes einheitlich entweder nur Server Core oder nur die Vollinstallation einrichten. “Voll” und Core darf in einem Cluster nicht gemischt sein.
• Das Heartbeat-Netz sollte man nicht mehr mit Crosslink-Kabeln einrichten, sondern per Switch, weil GBit-Karten nach dem Ausfall der anderen Seite sonst oft Probleme bereiten (keine Verbindung).
• Ressourcen im Clustering: Auch nach dem Failover sollte ein Clusterknoten nicht mehr als 80 Prozent seiner Ressourcen auslasten. Für Zwei-Knoten-Cluster im Aktiv-Aktiv-Betrieb heißt das, dass jeder Knoten zu maximal 40 Prozent ausgelastet sein sollte. Cluster aus drei oder mehr Knoten nach dem Aktiv-Aktiv-Passiv-Prinzip erlauben hier u.U. eine bessere Nutzung.
• Wenn Quick Migration genutzt werden soll, müssen alle beteiligten Clusterknoten identische bzw. kompatible CPUs haben. Die CPU wird nicht virtualisiert, sondern an den Gast durchgereicht. Wäre sie nach dem Verschieben der VM plötzlich eine andere, liefe die VM in einen Bluescreen. (Nach dem Reboot läuft eine solche VM wieder, weil beim Startvorgang die CPU neu erkannt wird, aber nicht im laufenden Betrieb.)
• Sobald die Clusterdienste für Hyper-V aktiviert sind, sollten VMs nur noch im Cluster-Manager angelegt oder verwaltet werden (oder im VMM, aber nicht über den Hyper-V-Manager), damit sie als Clusterressource zur Verfügung stehen und damit der Clusterdienst die VMs nach dem Beenden nicht einfach wieder neu startet.

VM-Konfiguration

• Hyper-V lässt die Reservierung von Ressourcen mit mehreren Parametern zu. Allgemein sollte man das nur nutzen, wenn es zwingende Gründe dafür gibt. In den meisten Fällen ist die dynamische Ressourcenverteilung günstiger.
• Fest zuweisen muss man (wie oben erwähnt) den Arbeitsspeicher pro VM.
• Die “virtuellen CPUs” lassen sich in ihrer Zahl einer VM zuweisen. Vorsicht dabei: Wenn eine VM z.B. zwei CPUs zugewiesen bekommt, kann der interne CPU-Scheduler sie nur dann mit einer CPU-Zeitscheibe versorgen, wenn gleichzeitig zwei CPU-Zyklen frei sind. In eng bemessenen Systemen kann dies die Performance einzelner VMs beeinträchtigen. Braucht eine VM also nur eine CPU, sollte man ihr auch nicht mehr zuweisen.
• Zeitsynchronisation: Die Systemzeit von VMs kann man entweder über die Methoden des Betriebssystems (z.B. W32TM bei Windows) steuern oder über die Integrationskomponenten vom Host synchronisieren lassen. Da die Zeitgeber des VM-Betriebssystems oft Probleme in einer virtualisierten Infrastruktur haben, ist meist folgende Kombination am besten: Der Hyper-V-Host (also die Parent Partition) synchronisiert sich per W32TM gegen die Domäne. Die darauf laufenden VMs synchronisieren ihre Zeit über die Integration Services mit dem Host, dazu deaktiviert man in den VM-Betriebssystemen den Zeitdienst. Vorsicht: Das setzt voraus, dass der DC, der die PDC-Rolle (und damit den domänenweiten Zeitdienst) hält, selbst nicht als VM läuft.

Virtuelle Festplatten

• Hyper-V kennt vier Typen virtueller Festplatten:
  • Fixed: Die VHD-Datei hat eine feste Größe, die gleich beim Erzeugen der virtuellen Platte auf der physischen Festplatte des Hosts angelegt wird. Die Größe kann man nachträglich ändern (nur größer), aber nur offline.
    Vorteil: Dies vermeidet Fragmentierung und den Leistungsverlust, der beim dynamischen Wachstum entstehen würde.
  • Dynamic: Die VHD-Datei hat eine Maximalgröße, wird aber nur in der tatsächlich benötigten Größe physisch erzeugt. Sie wächst bei Bedarf bis zum Maximum.
    Vorteil: In Testsystemen oder knapp bemessenen Umgebungen lässt sich so Plattenplatz sparen.
  • Differential: Eine solche Disk hat eine bestehende VHD-Datei als “Parent” und speichert nur die Änderungen, die eine VHD gegenüber der bestehenden Disk aufweist. Die Nutzung erfolgt dann per Overlay, d.h. Hyper-V hat dann beide VHDs im Zugriff und liest quasi zuerst die Differential Disk und greift auf die Parent-Disk zu, wenn Daten dem Originalsystem entsprechen. Das lässt sich in Testumgebungen nutzen, wenn man mehrere ähnliche Systeme hat; diese belegen dann insgesamt nur wenig Speicherplatz.
    Nachteil: Die VHDs sind voneinander abhängig.
  • Pass-through: Hierbei wird einer VM eine physische Festplatte (bzw. meist eine LUN im SAN) zugewiesen. Eine VHD-Datei entsteht dabei nicht.
    Vorteil: Maximale Performance (deutlich geringere Latenzen) und direkte Nutzung evtl. vorhandener SAN-Features.
    Nachteil: Keine Snapshots möglich.
  • In Produktionsumgebungen werden i.d.R. nur Fixed und Pass-Through Disks unterstützt.
• Die Maximalgröße von VHDs beträgt 2 Terabytes.
• Um eine Pass-through Disk einzurichten, muss man die betreffende Festplatte/LUN im Parent erst in der Datenträgerverwaltung ausdrücklich als “offline” markieren, sonst steht sie Hyper-V nicht zur Verfügung.
• VMs können in Hyper-V nur von IDE-Platten starten! Das hat den Vorteil, dass bei der VM-Installation keine Treiberprobleme entstehen.
• SCSI-Platten kann man nur als “synthetische” Devices einrichten, d.h. zunächst müssen die Integrationsdienste laufen (bzw. ein Treiber in der Gast-VM).

Netzwerk-Konfiguration

• Hyper-V kennt drei Typen von Netzwerkverbindungen für VMs. Diese sollte man sinnvollerweise vor dem Erzeugen von VMs definieren, sonst stehen den VMs nämlich keine synthetischen NICs zur Verfügung.
  • Extern: Dieser Netzwerktyp erlaubt einer VM, auf das LAN, die anderen VMs sowie auf den Host zuzugreifen (vorausgesetzt natürlich, die weiteren Netzwerkeinstellungen lassen das zu)
  • Intern: Dieser Netzwerktyp ist nur für die Kommunikation der VMs untereinander sowie mit dem Host geeignet. So angebundene VMs haben also keine Verbindung zum Produktions-LAN außerhalb des Hosts.
  • Privat: Dieser Netzwerktyp erlaubt die Kommunikation der VMs untereinander, aber weder mit dem Host, noch mit dem LAN. (Für diesen Netzwerktyp existiert kein virtueller NIC im Parent.)
• Pro physischer Netzwerkkarte (NIC) kann man nur einen vSwitch (virtuelle Netzwerkverbindung) definieren.
• Die VLAN-Tags, die man auf Hyper-V-Ebene festlegen kann, werden nur für den ausgehenden Netzwerkverkehr verwendet. Die Gast-VMs sehen diese Tags nicht. Sie dienen auch nur zur Einbindung des gesamten Hosts und seiner NICs in eine vorhandene VLAN-Struktur und haben keinen Einfluss auf die virtuellen Netzwerkverbindungen der Gast-VMs. Wenn Gast-VMs mit VLANs arbeiten sollen, ist dies innerhalb der jeweiligen Gast-VM zu konfigurieren.
• In der Parent Partition erkennt man einen NIC, der von VMs genutzt werden kann, daran, dass nur das Protokoll “Virtual Network Switch” darauf gebunden ist. Sind andere Protokolle gebunden, handelt es sich um einen physischen NIC, auf den nur der Parent zugreift.
• Als Empfehlung sollte man vor dem Anlegen der Netzwerkverbindungen die NICs des Host innerhalb der Parent Partition eindeutig benennen. Das erleichtert die spätere Zuordnung. Ebenso sollten die vSwitches passende eindeutige Namen bekommen. Beispiele:
  • LAN-phy-Broadcom-Port1
    könnte den ersten physischen NIC bezeichnen, der mit dem Produktions-LAN verbunden ist
  • MGM-phy-Intel-Port1
    könnte den ersten physischen NIC bezeichnen, der mit dem Management-LAN verbunden ist (also zur Anbindung der Parent Partition für die Administration)
  • LAN-ext-Broadcom-Port1
    könnte den vSwitch (also die Hyper-V-Netzwerkverbindung) bezeichnen, der mit der o.g. ersten LAN-Verbindung gekoppelt und als “externes” Netzwerk konfiguriert ist
  • Namens-Erweiterungen wie z.B. VLAN-IDs usw. können nach Bedarf eingesetzt werden
• Aus Sicherheitsgründen ist es empfehlenswert, die VM-Netzwerkverbindungen von denen der Parent Partition zu trennen. Dies verhindert, dass ein Angreifer von einer gekaperten VM per Netzwerk auf die Parent Partition zugreift. Dazu ist Folgendes nötig:
  • Die Parent Partition erhält eine dedizierte Netzwerkverbindung, an die keine VMs gebunden sind. Idealerweise greift diese auf das Management-LAN zu (soweit vorhanden) und nicht auf das Produktions-LAN.
  • Für diesen Parent-NIC legt man einen vSwitch an und entfernt dann von der virtuellen Netzwerkkarte alle Protokollbindungen. (Man könnte diesen virtuellen NIC auch deaktivieren, aber das gibt oft Probleme in Überwachungswerkzeugen, die dann Warnungen ausgeben.)
• Hyper-V lässt keine WLAN-Verbindungen zu. Um dies in einer Testumgebung doch zu ermöglichen, eignet sich folgender (nicht supporteter) Trick: Man fügt in der Parent Partition einen Loopback-Adapter als NIC hinzu und erzeugt mit diesem und der WLAN-Verbindung innerhalb von Windows eine Bridge.
• Soll eine VM per Netzwerk-Boot installiert werden, muss man der “leeren” VM erst einen Legacy-NIC zuweisen. Nach der fertigen Installation weist man dann eine “synthetische” Netzwerkverbindung zu und entfernt den Legacy-NIC wieder.

VM-Management

• Will man VMs oder den Host verwalten, sind spezielle Zugriffsrechte nötig. Um diese zu setzen und zu bearbeiten, ist der Authorization Manager in der Parent Partition nötig (AzMan.msc). Um dies zu vereinfachen, finden sich im Internet Skripts, die die Aufgabe erledigen.
  Besser geht dies mit dem Virtual Machine Manager, der erweiterte Werkzeuge dafür bietet.
• Der Hyper-V-Manager lässt die Definition von zwei Standardpfaden für neue VMs zu: Einer betrifft den Speicherort der VHD-Datei, der andere den der Konfigurationsdateien. Es ist sinnvoll, beide auf denselben Pfad zu legen, denn die Dateien für gespeicherte VMs legt Hyper-V immer im selben Ordner ab wie die Konfigurationsdateien (und nicht im VHD-Pfad – es sei denn, beide sind identisch). Zudem hat man so alle Dateien beieinander.
• Ex- und Import: Beim Exportieren einer VM kopiert Hyper-V alle Dateien der VM (VHD und Konfiguration) auf den angegebenen Zielpfad. Vorsicht: Beim Importieren kopiert Hyper-V keine Dateien, sondern erzeugt nur (exklusive) Pointer auf die angegebenen Dateien! Im Regelfall sollte man also die Dateien erst manuell an den gewünschten Speicherort kopieren.
• Vor dem Export kann es zudem sinnvoll sein, erst die Netzwerkverbindungen zu entfernen. Beim Import versucht Hyper-V nämlich, diese anhand ihres Namens zuzuordnen. Bestehen beim Import aber keine Netzwerkverbindungen, so ist man in der Einrichtung flexibler.
• Hyper-V lässt mit Bordmitteln auch den Import einer ESX-VM zu (offline).
• Den Virtual Machine Manager, so vorhanden, sollte man in einer VM oder auf separater Hardware installieren, nicht in der Parent Partition. In der Parent Partition sind keine Applikationen supportet.
• Der Virtual Machine Manager kann auch ESX-Hosts und –VMs verwalten. Voraussetzung ist dabei aber ein bestehender Virtual-Center-Server (VC), denn VMM bringt keine eigenen ESX-Funktionen mit, sondern spricht nur die wichtigsten Funktionen des VC-API an.
• Die Ports des VMM sind TCP 8100 für die Management-Konsole und TCP 443 (= https) für die Kommunikation mit den Hosts.
• VMM bringt eine Migrationsmöglichkeit für physische Maschinen mit (P2V). Hierbei wird von dem Quellsystem ein VSS-Snapshot erzeugt, sodass die Originalmaschine weiterläuft. Da dies beim Umschalten die Gefahr von Inkonsistenzen der Applikation birgt (denn die Quellmaschine könnte auf einem aktuelleren Stand sein als die Ziel-VM), sollte man vor diesem Vorgang die Dienste der jeweiligen Applikation stoppen.
• Auch die Online-Konvertierung von VMware-VMs ist mit VMM möglich. Das funktioniert aber nur mit supporteten Betriebssystemen, weil die Treiber während des Prozesses ausgetauscht werden.
• Performance-Monitoring: Im Taskmanager sieht man nur die Aktivität der Parent Partition! Der Hyper-V-Manager gibt einige Details über die Auslastung der VMs an. Interessant wird es aber im Performance Monitor, wo sich die Counter pro Instanz (also pro VM) differenziert auswählen lassen.

Snapshots

• Snapshots bezeichnet Hyper-V (bzw. der VMM) auch als “Checkpoints”. Der Mechanismus besteht darin, dass alle Änderungen an der VM, die nach dem Checkpoint erfolgen, in eine separate Overlay-Datei geschrieben werden (auch die Konfiguration wird dabei separat geschrieben). So lassen sich verschiedene Zustände einer VM festhalten. Snapshots/Checkpoints können in einer Art Baumstruktur verzweigt aufeinander beruhen.
• Ein Snapshot lässt sich gezielt ansteuern, ohne andere Zustände zu beeinflussen (revert). Man kann einen Snapshot auch in den darunterliegenden Zustand integrieren und so die VM-Dateien zusammenführen, wobei der jeweils vorhergehende Zustand nicht mehr anwählbar ist (apply).
• Es kann vorkommen, dass das Erzeugen eines Snapshots fehlschlägt. Ursache kann ein Timing-Problem sein, sodass ein erneuter Versuch dann meist glückt.