Hyper-V und Netzwerke

Die Netzwerkkonfiguration gehört zu den komplexesten Komponenten einer Hyper-V-Installation. Erstaunlicherweise gilt dies, obwohl – zumindest im aktuellen Release – die Netzwerkfähigkeiten des Microsoft-Hypervisors deutlich hinter denen der Mitbewerber zurückbleiben. So gibt es funktional nicht viel mehr zu tun, als virtuelle Switches zu erzeugen und die Netzwerkkarten der virtuellen Maschinen darauf zu verbinden. Als einzige Erweiterung ist es in Windows Server 2008 R2 möglich, der jeweiligen Verbindung eine VLAN-ID mitzugeben. Der Switch selbst wiederum kann als “extern” (Verbindung zum Host und ins externe LAN möglich), “intern” (Verbindungen nur zum Host und anderen lokalen VMs, aber nicht ins externe Netz) oder “privat” (Verbindung zu lokalen VMs, aber nicht zum Host) definiert werden. Das war es. Netzwerk-Pools, Bandbreitensteuerung oder Firewall-Funktionen sucht man in Hyper-V vergeblich.

Und trotzdem gibt es bei Admins erhebliche Unsicherheiten und immer wieder ärgerliche Fehlkonfigurationen mit den rudimentären Hyper-V-Netzwerken. Wie kommt das?

Ein Großteil der Unklarheit liegt an der ungünstigen Darstellung, die Microsoft für die Netzwerkverbindungen gewählt hat. Es gibt nämlich nicht mehr als das bekannte Verbindungs-Applet der Systemsteuerung, das alle Netzwerktypen, die der Virtualisierungshost sieht, unterschiedslos mit demselben Icon anzeigt. Ein noch relativ einfaches Beispiel zeigt die nächste Abbildung. Preisfrage: Wieviele physische Netzwerkkarten hat dieser Server?

Abb. 1: Ansicht der Netzwerkverbindungen in der “Parent Partiton”

Auflösung: Der hier betrachtete Server hat drei physische Netzwerkadapter. Die anderen beiden Einträge zeigen virtuelle Karten, die durch Hyper-V ins Spiel kamen. Doch auch die drei “physischen” Verbindungen gehören zwei unterschiedlichen Typen an: Zwei davon sind nämlich virtuelle Switches, die dritte ist eine “normale” Netzwerkkarte. Wie man leicht sieht, haben alle dasselbe Icon. Alles klar?

Die Logik der Hyper-V-Netzwerke

Um hier Licht ins Dunkel zu bringen, ist etwas Hintergrund erforderlich. Trotz der geringen Gestaltungsmöglichkeiten für virtuelle Netzwerke ist die unterliegende Technik durch das Hypervisor-Prinzip nämlich sehr komplex: Zu unterscheiden sind je nach Betrachtungsweise mindestens drei Ebenen, die wir im Folgenden zugrunde legen. Dabei handelt es sich um

• die Host-Ebene mit den physischen Netzwerkadaptern, die tatsächlich die elektrische Verbindung zum Netzwerk herstellen. Zusätzlich ordnet unsere Betrachtung auch das Adapter-Teaming dieser Ebene zu, dazu gleich mehr
• die Hypervisor-Ebene mit den virtuellen Switches, über die die virtuellen Maschinen ihre Verbindung ins Netzwerk herstellen
• die VM-Ebene, in der die virtuellen Maschinen (einschließlich der Parent-Partition – auch dazu gleich mehr) und ihre jeweiligen Betriebssysteme ihre Netzwerkkarten “sehen” und konfigurieren

Abb. 2: Logik der Netzwerkverbindungen in Hyper-V

Die Host-Ebene

In unserem Beispiel hat der betrachtete Host-Server sechs Netzwerkkarten, die unten auf der Host-Ebene dargestellt sind (violetter Bereich). Fünf dieser Netzwerkkarten (hier: NIC1 bis NIC5) sind dazu gedacht, den virtuellen Maschinen Verbindungen in das externe Netzwerk zu bieten (wobei es sich hier um bis zu drei getrennte Netzwerke handeln kann, es können aber auch weniger sein). Die sechste Karte (NIC6) dient dazu, einen separaten Netzwerkzugang für die “Parent Partition” zu definieren, über den keine der VMs eine Verbindung erhalten kann. Microsoft empfiehlt ein solches separates Management-Netzwerk, um die administrativen Aufgaben, die den Hyper-V-Host betreffen, vom normalen Netzwerkverkehr zu trennen. Zwingend notwendig ist ein solches eigenes Management-Netz nicht, und viele Kunden verzichten darauf.

Jeweils zwei Netzwerkkarten (NIC1/NIC2 sowie NIC3/NIC4) sind als Teams definiert, damit die zugehörigen Netzwerkverbindungen eine gewisse Ausfallsicherheit und in günstigen Fällen auch eine Lastverteilung haben. Das Teaming muss in Windows Server 2008 R2 mit separater Software geschehen, die normalerweise vom Hersteller der Netzwerkkarten stammt (z.B. Broadcom BACP oder Intel ProSet). Dieses Teaming findet logisch betrachtet auf der Ebene des Hosts statt, weil Hyper-V nichts davon weiß. Das bedeutet auch, dass man bei der Einrichtung des Teaming eine bestimmte Installationsreihenfolge einhalten muss, weil es sonst zu gravierenden Zugriffsproblemen im Netzwerk kommen kann.

Die Hypervisor-Ebene

Der Hypervisor (orangefarbener Bereich) definiert virtuelle Switches (in Windows Server 2008 R2 als “virtuelle Netzwerke” bezeichnet, erst Windows Server “8” spricht von virtuellen Switches) und bietet damit die Möglichkeit, mehrere virtuelle Maschinen an die physischen Netzwerkadapter des Hostservers zu binden. Diese virtuellen Switches lassen eine unbegrenzte “Überbuchung” der physischen Verbindungen zu: Ob nur eine virtuelle Netzwerkkarte an eine physische gebunden ist, drei oder zwanzig, ist dem Hypervisor zunächst egal.

Die virtuellen Switches definiert man zum ersten Mal bei der Ersteinrichtung von Hyper-V. Auf einem Host mit drei Netzwerkkarten sieht das z.B. so aus (hierbei wird ebenfalls eine Karte für das Management-Netz reserviert):

Abb.3: Definition virtueller Switches bei der Erstkonfiguration von Hyper-V in Windows Server 2008 R2

Nachträglich lassen sich virtuelle Switches im Hyper-V-Manager erzeugen und konfigurieren, in Windows Server 2008 R2 über den Punkt “Manager für virtuelle Netzwerke” bzw. in Windows Server “8” über “Manager für virtuelle Switches”.

Wie oben bereits angemerkt, sind die Konfigurationsmöglichkeiten für die virtuellen Switches sehr eingeschränkt. Man kann dort nur den Netzwerktyp sowie eine VLAN-ID für die Parent Partition zuweisen:

• “Extern”: Dieser Switch stellt eine uneingeschränkte Verbindung in das dahinterliegende Netzwerk her. Über welche Netzwerkkarte der Verkehr läuft, wählt man im Auswahlfeld darunter aus – Vorsicht, hier steht der Gerätename und nicht der evtl. manuell gewählte “freundliche” Name.
  Ist das darunter stehende Häkchen gesetzt, können VMs nicht nur andere Rechner im betreffenden LAN, sondern auch den “Host” selbst (genauer: die Parent Partition) erreichen. Obwohl das Häkchen standardmäßig aktiviert ist, ist diese Einstellung meistens nicht notwendig, weil VMs normalerweise den Host gar nicht über das Netz ansprechen müssen.
• “Nur intern”: Ein solcher Switch stellt in Wirklichkeit gar keine Verbindung ins physische LAN her, sondern erlaubt nur den Verkehr innerhalb des virtuellen Netzwerks. Die daran angebundenen VMs erreichen also keine Rechner im LAN, sondern nur solche auf demselben Host sowie den “Host” selbst. Aus diesem Grund kann man dort auch keine Netzwerkkarte auswählen.
  In der Produktion ist ein solches Netzwerk meist nicht nützlich, es ist eher interessant für Testaufbauten oder zur Vorkonfiguration von VMs, die zunächst nicht ans LAN sollen.
• “Privates Netzwerk für virtuelle Computer”: Dieser Switch hat auch keine Verbindung zur Außenwelt, daher gibt es auch hier keine Netzwerkkarte zur Auswahl. Dieses Netzwerk entspricht weitgehend dem “internen” mit dem Unterschied, dass der “Host” darüber nicht erreichbar ist.
• Die VLAN-ID, die man an dieser Stelle auswählen kann, betrifft nur den Datenverkehr der Parent Partition, hier auch als “Verwaltungsbetriebssystem” bezeichnet. Sie betrifft keine anderen VMs, die man an solch einen Switch anbindet! Wirksam wird sie daher nur, wenn man das Häkchen “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen” aktiviert – anderenfalls hat die Parent Partition ja gar keine Verbindung zu diesem Switch.

Erst in Windows Server “8” kann man virtuelle Switches funktional erweitern. Das ist allerdings ein völlig separates Thema, das wir an dieser Stelle nicht weiter behandeln.

Die VM-Ebene

Auf der VM-Ebene (türkiser Bereich) weist man den virtuellen Maschinen ihre Netzwerkkarten zu, verbindet sie mit virtuellen Switches und konfiguriert sie innerhalb des Betriebssystems der jeweiligen VM. Unter Windows Server 2008 R2 kann eine VM bis zu acht virtuelle Netzwerkkarten erhalten, von denen jede an maximal einen virtuellen Switch verbunden werden kann (also keine oder eine Verbindung, aber nicht mehr als eine – ein physischer Netzwerkport kann ja auch keine oder eine Kabelverbindung haben, aber nicht mehrere). Dabei kann man auch mehrere virtuelle Karten mit demselben virtuellen Switch verbinden, aber das ist nur in Ausnahmefällen sinnvoll.

Abb. 4: Netzwerkverbindungen für eine VM, hier mit aktivierter VLAN-ID für einen der Ports

Auf der Ebene der einzelnen Netzwerkports einer VM kann man optional eine VLAN-ID zuweisen. Dabei muss man natürlich dafür sorgen, dass dieses VLAN außerhalb der Hostumgebung (also auf den dahinterliegenden physischen Switches) korrekt umgesetzt wird.

In unserer Beispielgrafik oben haben wir exemplarisch zwei virtuelle Maschinen und die Parent Partition dargestellt:

• Die VM-A verfügt über eine einzige virtuelle Netzwerkkarte (vNIC-A). Diese ist an den virtuellen Switch “vSwitch1” gebunden (welcher seinerseits auf Team1 konnektiert, also über NIC1 und NIC2 ins physische Netzwerk zeigt).
• Die VM-B hat zwei virtuelle Netzwerkkarten: vNIC-B1 konnektiert auf den vSwitch3 und läuft so auf der physischen NIC5 ins LAN. vNIC-B2 ist mit vSwitch2 verbunden, läuft also über Team2 auf den Karten NIC3 und NIC4 ins physische Netz.
• Die Parent Partition hat in unserem Beispiel ebenfalls zwei Netzwerkkarten. Die virtuelle Karte vNIC-Par ist beim Einrichten des virtuellen Switches vSwitch3 über das Häkchen “Gemeinsame Verbindung … zulassen” definiert worden. Sie stellt also eine Verbindung zu vSwitch3 her, auf den auch VM-B konnektiert ist.
  Die physische Verbindung pNIC-Par ist nichts anderes als die physische Karte NIC6, die wir in unserem Beispiel für das Management-Netzwerk reserviert haben.

Ein wichtiger Hinweis: Diese Konfiguration ist nur eine Illustration der Prinzipien. Sie stellt keine Empfehlung für echte Konfigurationen dar (wenn sie auch technisch möglich wäre und nicht unsinnig ist).

In der Grafik ist auch zu sehen, an welchen Stellen die Netzwerkverbindungen mit IP-Adressen versehen sind (dunkler “IP”-Kreis). Diese Konfigurationen finden ausschließlich innerhalb der jeweiligen VM-Betriebssysteme bzw. in der Parent Partition (dort für deren eigene Netzwerkverbindungen) statt. Virtuelle Switches haben in Hyper-V keine eigenen IP-Adressen, und auch den physischen Karten ist keine IP-Konfiguration zugewiesen!

Die Ansicht in der Parent Partition

Spannend ist nun die Frage, wie die Verbindungen in unserem Beispiel in der Parent Partition angezeigt würden. Zur Erinnerung: Der Host hat sechs Netzwerkkarten. Wie viele Verbindungs-Icons sieht man nun also in unserem Beispiel, wenn man im “Host” die Netzwerksteuerung öffnet? Und Zusatzfrage: Wie viele IP-Adressen sind im Host zu konfigurieren?

Abb. 5: Die Ansicht der Verbindungs-Icons in der Systemsteuerung der Parent Partition (schematisch)

Antwort: Man sieht in unserem Beispiel neun Verbindungssymbole!

• Fünf Icons stellen die physischen Karten dar, die direkt oder über ein Team als virtuelle Switches konfiguriert sind. Öffnet man die Eigenschaften dieser Symbole, so sieht man dort keine IP-Konfiguration und keine “normalen” Protokollbindungen, sondern nur das virtuelle Switch-Protokoll bzw. den Protokolleintrag der Teaming-Software.
• Ein Icon (pNIC-Par) stellt die sechste physische Karte dar. Da diese nicht in Hyper-V mit einem vSwitch verbunden ist, zeigt sie die normalen Protokollbindungen und hat auch eine IP-Konfiguration.
• Zwei Icons stammen von der Teaming-Software. Hierbei handelt es sich um die virtuellen Adapter, die die Netzwerk-Teams repräsentieren. Da wir im Beispiel an jedes Team einen vSwitch gebunden haben, haben auch diese Symbole keine IP-Konfiguration, sondern sind nur an das virtuelle Switch-Protokoll gebunden.
• Schließlich gibt es eine virtuelle Netzwerkkarte innerhalb der Parent Partition (vNIC-Par). Sie ist, wie oben schon gesagt, über das Häkchen “Gemeinsame Verbindung … zulassen” eingerichtet worden. Da es sich für die Parent Partition um eine “normale” Netzwerkkarte handelt, gibt es hier die normalen Protokollbindungen und damit auch eine IP-Konfiguration.

Wenn man nun den “Host” konfiguriert, sollte man die Finger von der Protokollkonfiguration aller virtuellen Switches lassen, ebenso sollte man die Teams in Ruhe lassen. Zu konfigurieren sind hier je nach Bedarf nur zwei der Verbindungen: pNIC-Par und vNIC-Par, denn nur diese beiden stellen tatsächlich “klassische” Netzwerkverbindungen für das Host-Betriebssystem (also die Parent Partition) dar.

Best Practice

Auch die Darstellungen in diesem Artikel werden nicht jede Frage beantworten und stellen noch keine ausreichende Grundlage für Planung und Konfiguration dar. Daher im Folgenden noch einige ergänzende Hinweise.

• Wie man sieht, sind Planung und Aufbau virtueller Netzwerke in Hyper-V durchaus komplex. Es empfiehlt sich also, hierfür ausreichend Zeit schon in der Design-Phase vorzusehen.
• Ein produktiver Hyper-V-Hostserver sollte ausreichend Netzwerkports vorsehen, um hinterher die konkreten Anforderungen zu erfüllen. Das kann durchaus bedeuten, dass manche Hardware nicht in Frage kommt, wenn sie nicht genügend Ports bietet (z.B. einfachere Blade-Systeme). Berücksichtigen sollte man je nach Situation:
  • Wie viele getrennte physische Netzwerkverbindungen benötigen die VMs, die auf dem System laufen sollen?
    Dabei ist zu berücksichtigen, dass man zwar durchaus fünf, zehn oder auch zwanzig VMs über nur eine physische Netzwerkkarte anbinden kann. Für viele Zwecke ist das auch ohne Probleme machbar. Aber: Obwohl hier ein virtueller Switch im Spiel ist, der den Verkehr steuert, handelt es sich dann eben nur um eine einzige Karte, also ggf. nur einmal 1 Gbit ins Netzwerk. Hier ist zu prüfen, ob es für die VMs wirklich ausreicht, sich 1 Gbit Gesamtbandbreite zu teilen. Ist das zu wenig, sollte man mehrere physische Karten (und mehrere vSwitches) vorsehen.
  • Ist der Zugriff auf getrennte LAN-Segmente durch die VMs auf einem Host erforderlich?
    Pro physisches LAN benötigt man eine physische Netzwerkkarte und einen zugeordneten vSwitch. Sollen einige VMs also in ein Segment 172.16.x.y gelangen, andere in ein physisch getrenntes Segment 192.168.x.y, so sind zwei NICs einzuplanen.
  • Soll es ein separates Management-LAN geben?
  • Ist ein Speichernetz angebunden?
    Ein Speichernetz sollte man in der Produktion unbedingt über ein separates LAN führen, also auf keinen Fall über dieselben Netzwerkkarten ansprechen, die auch den produktiven LAN-Verkehr bedienen. Besonders im Fall von iSCSI ist dies relevant.
  • Gibt es ein Cluster-Netzwerk?
    Ein Hyper-V-Cluster sollte auf jeden Fall (mindestens) ein eigenes physisches Netzwerksegment für den clusterinternen Datenverkehr (Heartbeat, Live Migration, CSV) haben. In größeren Umgebungen wird man hier sogar mehrere getrennte Netzwerke definieren.
• Die Parent Partition sollte auf eine Netzwerkverbindung zugreifen können, über die sie sich mit Updates versorgen kann (vorzugsweise per WSUS). Hierbei kann es sich um das Management-LAN handeln, was aber evtl. zusätzliche Konfiguration erfordert.
• Benötigt die VM-Umgebung auf Netzwerkebene erweiterte Funktionen (z.B. Netzwerk-Management, Bandbreitensteuerung, Filterung/Firewalls, Intrusion Detection usw.), so stehen in Windows Server 2008 R2 dafür keine Bordmittel und nur sehr wenige Drittanbieter-Produkte zur Verfügung. Erst mit Windows Server “8” und seinen “Extensible vSwitches” gibt es hier eine definierte Schnittstelle für ergänzende Plug-ins.
• Das Teaming ist unbedingt nach den Vorgaben des jeweiligen Herstellers einzurichten. Hinweise dazu gibt z.B. dieser Artikel:
  [How-To: Netzwerkkarten Teaming mit Hyper-V | Server Talk]
  http://www.server-talk.eu/2009/12/02/how-to-netzwerkkarten-teaming-mit-hyper-v/
• Es empfiehlt sich, die Netzwerkverbindungen in der Parent Partition mehrfach manuell umzubenennen. Windows selbst vergibt sonst nur Standardbezeichnungen à la “LAN-Verbindung 7”, was schnell sehr unübersichtlich wird.
  • Die erste Umbenennung erfolgt direkt nach der Installation des Host-Betriebssystems und noch vor der Aktivierung der Hyper-V-Rolle.
    Bewährt hat sich eine Namenskonvention, die die Karten als physisch kennzeichnet und gleichzeitig über das Netzwerk Auskunft gibt, das über das angeschlossene Netzwerkkabel erreichbar ist. Zudem ist es meist sinnvoll, den Port eindeutig zu kennzeichnen. Beispiele:
    • phy-LAN-Port1, phy-LAN-Port2
    • phy-DMZ-Port-links, phy-Mgmt-Port-rechts
  • Die zweite Umbenennung erfolgt ggf. wenn Teams eingerichtet sind. Auch hier sollten die Namen prägnant und sprechend sein. Beispiele:
    • phy-Team-LAN-Port1-2
    • phy-Team-LAN-VLAN2
  • Die dritte Umbenennung erfolgt, wenn Hyper-V fertig installiert und die virtuellen Karten der Parent Partition erzeugt sind. Diese sollten auch aussagekräftige Namen haben. Beispiele:
    • vir-Parent-LAN
    • vir-Parent-WSUSNetz
• Und schließlich ist es dringend zu empfehlen, die Design-Entscheidungen und die reale Implementierung der Netzwerke gut zu dokumentieren, weil man sonst schnell wieder den Überblick verliert.

Abb. 6: Beispiele für sprechend benannte Netzwerkverbindungen in der Parent Partition