Altaro: Hyper-V: virtuelle Switches erklärt

Autor: Eric Siron Originalartikel

Hyper-V: virtuelle Switches erklärt

Für Hyper-V Neueinsteiger sind virtuelle Switches oft der Stolperstein. Dieser Artikel versucht die üblichen Fragen zu beantworten und soll einige Verwirrungen beseitigen. Im ersten Teil gehen wir die Begrifflichkeiten des Hyper-V virtuellen Switch durch. Im zweiten Teil betrachten wir mögliche Anwendungsszenarien. Diese Blogeinträge behandeln nur den virtuellen Switch und die Verbindung vom Hypervisor-Betriebssystem mit dem physischen Netzwerk.

verschiedene Switch Arten

Es gibt insgesamt 3 verschiedene Betriebsmodi des Hyper-V Switch: privat, intern und extern. Verwechseln Sie diese Modi bitte nicht mit IP-Adressschemas oder Netzwerkkonfigurationen anderen Technologien.

Privater Switch

Ein privater Switch lässt nur die Kommunikation auf der virtuellen Maschine zu, keine anderen Verbindungen. Nicht einmal das Hypervisor-Betriebssystem hat Zugriff auf das erstellte Netzwerk. Das private Netz ist ein rein logisches und verwendet keine physischen Netzwerkadapter. Der Ausdruck „privat“ hat keinen Bezug zu privater IP Adressierung. Man kann sich einen klassischen Switch darunter vorstellen, welcher keinen Uplink zu anderen Switches bietet.

Interner Switch

Der interne Switch verhält sich ähnlich dem privaten Switch, allerdings mit einer Ausnahme: Das Betriebssystem des Hypervisors kann einen virtuellen Adapter für dieses Switch-Netzwerk besitzen und somit an der Kommunikation teilnehmen. Andere virtuelle Maschinen mit dem gleichen internen Switch-Netz können ebenso an der Verbindung teilnehmen. Dieser Switch besitzt keine Verbindungsmöglichkeit mit einem physischen Netzwerkadapter und somit ist auch kein Uplink zu anderen Switches möglich.

Externer Switch

Diese Switch-Variante muss an einen physischen Netzwerkadapter gebunden sein. Der externe Switch erlaubt die Kommunikation zwischen dem Hypervisor-Betriebssystem und den virtuellen Maschinen. Verwechseln Sie nicht externe/öffentliche IP-Adresse mit der Bezeichnung „externer“ Switch. Es handelt sich auch nicht um einen Switch der vielleicht mit dem Internet verbunden sein muss. Sie können auch die gleichen private IP-Adressen auf diesen Adaptern verwenden wie bereits vorhanden auf Ihrem physischen Netzwerk.

Konzept des externen virtuellen Switches

Den externen virtuellen Switches zu verstehen wird aufgrund der verwandten Begrifflichkeiten erschwert. Die Hyper-V Manager GUI nennt es „Erstellt ein virtuelles Netzwerk, das an den physischen Netzwerkadapter gebunden wird, damit virtuelle Computer Zugriff auf ein physisches Netzwerk erhalten“. Der PowerShell-Befehl „New-VMSwitch“, beinhaltet den Parameter „-AllowManagementOS“ mit seiner Beschreibung „Specifies wheather the parent partition (i.e. the management operating system) ist o have access tot he physical NIC bounded to the virtual switch to be created.“ – macht es nicht gerade besser. Daher denken viele Menschen an folgendes Bild:

Unglücklicherweise ist diese Vorstellung falsch. Wird ein externer virtueller Switch erzeugt, dann ist im ersten Moment noch nichts mit dem physischen Netzwerkadapter verbunden, außer natürlich der virtuelle Switch selbst. Anstatt den Adapter zu „Teilen“ erhält das Hypervisor-Betriebssystem einen virtuellen Adapter, wie auch jede virtuelle Maschine. Folgendes Bild zeigt das richtige Prinzip des externen virtuellen Switchs.

In dieser Abbildung wird gezeigt wie der externe Switch arbeitet. Falls Sie die Option „Gemeinsames Verwenden“ nicht aktivieren oder wenn Sie „-AllowManagementOS=0“ setzen, dann wird der Adapter „Management OS Virtual Adapter“ einfach nicht erzeugt. Die physische Netzwerkkarte wird niemals für andere Zwecke verwendet als für das Bereitstellen des virtuellen Switches.

Haben Sie jemals versucht mit Hilfe des Hyper-V Manager von einem Remote-System einen virtuellen Switch auf einem Host mit der Option „Gemeinsames Verwenden“ zu erzeugen und der Hyper-V Manager reagierte nicht mehr? Das passiert weil, die IP-Einstellungen sind ungebunden zum physischen Netzwerk, der virtuelle Switch wird darauf aktiviert, ein neuer virtueller Adapter für das Management-Betriebssystem (Hypervisor) wird erstellt und die IP-Adressen werden zugewiesen. Sind Sie nun remote in das System über diesen Adapter eingewählt, funktioniert das nicht weil dieser Prozess einen Verbindungsabbruch vorsieht.

Wenn Sie in Windows Server 2012 einen virtuellen switch erzeugen und die „Gemeinsames Verwenden“ Option nicht aktivieren, hält Sie nicht davon ab mit der PowerShell einen virtuellen Adapter auf diesem Switch zu erstellen. In beiden Versionen können Sie die Option „Gemeinsames Verwenden zulassen“ via Hyper-V Manager aktivieren. Der Begriff „zulassen“ bedeutet leider nicht „zulassen“, sondern „erzeuge einen virtuellen Adapter und ordne diesen dem Management-Betriebssystem zu“. Setzen Sie die Option „Gemeinsames Verwenden“ durch die PowerShell für diesen Adapter, so wird in der Hyper-V Manager GUI ebenso die Option angehakt. Ich verwende die Option meistens nicht, da ich lieber meinen eigenen virtuellen Adapter erzeuge bevor ich den automatisch erzeugten modifiziere.


Teil 2

Nun werden verschiedene Einsatzszenarien untersucht.

Private, Interne und externe virtuelle Switches

Die meisten virtuellen Switches werden im externen Modus betrieben, da es sonst keinen anderen Weg für eine Verbindung in das physische Netz gibt. Aber dennoch gibt es Verwendung für die anderen beiden. Der hauptsächliche Verwendungszweck dieser nicht-öffentlichen Switches sind „inter-system-Leistungsfähigkeit“ und „Isolation“.

Leistungsfähigkeit

Private und interne Switches sind nicht mit dem physischen Netzwerk verbunden. Daher sind diese nicht an die Limitierungen von physischen Komponenten des Netzwerkes gebunden. Ein privater Switch kann Verbindung mit anderen Netzwerkadaptern aufnehmen die am gleichen Switch angeschlossen sind, und zwar mit der Geschwindigkeit des Host-Systems-Bus. Aber die Verbindung erfordert auch Kosten. Die virtuellen Netzwerkadapter müssen trotzdem auch noch die Netzwerkprotokolle durchlaufen. Die Packet-Bearbeitung benötigt CPU-Leistung. Im Vergleich zu einem physischen Netz, welches als Flaschenhals gesehen werden kann, besteht die Möglichkeit bei einem rein virtuellen Netz, dass die Packet-Bearbeitung weit mehr Ressourcen benötigt als in einem herkömmlichen Gigabit-Netzwerk.

Es darf nicht vergessen werden, dass in einem privaten und einem internen Switch-Netzwerk die Kommunikation außerhalb des physischen Hosts nicht ermöglicht wird. Haben Sie zwei virtuelle Maschinen mittels privatem Switch verbunden und einer der beiden Hosts wird durch „Live-Migration“ auf einen anderen Hypervisor verschoben, so ist die private Netzwerkverbindung unterbrochen. Diese Limitierung kann übergangen werden, aber nicht durch die Bordmittel von Hyper-V.

Isolation

Da private und interne Switches nicht mit dem physischen Adapter verbunden sind, besteht klarerweise eine Isolation von allen Geräten die nicht mit dem virtuellen Switch verbunden sind. Daher könnte diese Eigenschaft bei sensiblen und kritischen Systemen verwendet werden.

Erweiterte Konfiguration

Windows Server stellt die Rolle „Remote Access Service“ zur Verfügung. Damit wird eine Vielzahl von Verwendungszwecken ermöglicht. Zwei Einsätze davon sind bereits in der vorigen Abbildung zu erkennen, nämlich Routing und Network-Translation (NAT). Die Rolle würde auf einer VM mit 2 Netzwerkadaptern installiert werden. Dem einen Interface wird das private Netzwerk zugewiesen. Dem anderen Interface das externe Switch-Netzwerk, hier wird das Routing und RAS aktiviert. Somit ist eine Brücke zwischen privaten Switch und externen Switch geschaffen. Wenn Sie wünschen können Sie auch noch NAT konfigurieren um eine höhere Isolationsstufe zu erreichen. Um den Konfigurationsaufwand zu vereinfachen besteht die Möglichkeit zusätzlich die Rolle DHCP-Server bzw. DHCP Relay auf der VM zu installieren.

Werden die Adapter des privaten oder internen Switchs mit „LiveMigration“ auf einen anderen Host transferiert, besteht die Möglichkeit durch ein RAS System diese Verbindungen weiterhin zu nutzen. Ein (dualhomed) RAS System muss auf beiden Hypervisor-Maschinen existieren und jeweils einem Switch mit dem gleichen Namen aufweisen. Es gibt mehrere Wege dies zu erreichen, aber am einfachsten geht es wenn jeder RAS Server eine unterschiedliche IP auf dem gleichen privaten/internen Switch verwendet. Die verbundenen Maschinen werden mit beiden RAS-Server-IPs als Gateway konfiguriert. Im Vergleich zu einer herkömmlichen „Live Migration“ können hier aktive Verbindungen leicht unterbrochen werden.

Konfiguration des Hyper-V Switches

Viel Konfigurationsaufwand gibt es an dieser Stelle nicht. Falls Sie den Hyper-V Manager verwenden, dann starten Sie mit einem Klick auf den „Virtual Switch Manager“ auf der rechten Seite. Zu beachten gibt es allerdings die Tatsache, dass es bei einer Remote-Verbindung auf den Hyper-V Manager zu einem Verbindungsabbruch führen kann, da es zu kurzen Aussetzern kommen kann wenn der virtuelle Switch angelegt wird. Ist dies der Fall wird die gesamte Switch-Erzeugung fehlschlagen. Alternativ kann die PowerShell auf der Hyper-V Konsole verwendet werden.

Der Befehl „New-VMSwitch“ wird zum Anlegen eines Switch verwendet. Obwohl dieser nur einige Optionen besitzt können diese nur von dem Artikel auf TechNet abgehandelt werden.

Externe Swiches müssen auf einem physikalischen Adapter erzeugt werden (oder auf einer Gruppe von physikalischen Adaptern) welcher nicht bereits in einem anderen virtuellen Switch verwendet wird. Verwenden Sie „GetNetAdapter“ um eine Liste von Adaptern zu erhalten.

1 New-VMSwitch -Name „vSwitch“ -NetAdapterName „Ethernet 2“ -AllowManagementOS 0

Es gibt dabei einiges zu beachten. Wenn Sie einen privaten oder internen Switch verwenden möchten, sollten sie den Parameter –SwitchType mit einer der beiden Optionen verwenden. Dieser Parameter wird im obigen Beispiel nicht verwendet weil der Parameter –NetAdapterName einen externen Switch erzeugt. Der Wert für Quality-of-Service wird ebenso automatisch erzeugt. In der Dokumentation des cmdlet wird von „minimum weight“ gesprochen, allerdings ist da nicht korrekt. QoS sprengt allerdings den Umfang dieses Artikels, daher werde ich nicht genauer darauf eingehen. Wie im Teil 1 dieses Artikels bereits erwähnt bedeutet AllowManagementOS 0, dass jetzt kein virtueller Adapter erzeugt wird. Wenn Sie den Wert auf 1 setzen, wird ein virtueller Adapter in dem Hypervisor-Betriebssystem angelegt, welcher konfiguriert werden kann.

Um einen virtuellen Adapter im Hypervisor-Betriebssystem zu erstellen, müssen Sie die PowerShell (außer der Adapter wird automatisch erzeugt falls die Option „Allow“ gesetzt wrude) verwenden. Der Befehl ist auf TechNet beschrieben. Ein Beispiel:

1 Add-VMNetworkAdapter -SwitchName „vSwitch“ -ManagementOS -Name „LiveMigration“

Das Anlegen eines Adapters ist relative einfach. Sie können soviele anlegen wie Sie benötigen. Mehrere Adapter im Management-Betriebssystem für einen virtuellen Switch sind am wichtigsten wenn eine Gruppierung verwendet wird. Das Management-Betriebssystem sieht den Adapter mit dem Namen „vEthernet (verwendete Bezeichnung)“. Diesen Namen benötigen Sie für jedes Network-cmdlet das nicht „VM“ beinhaltet wie etwa „New-NetIPAddress“.

Der letzte wichtige Konfigurations-Punkt ist die VLAN-Einstellung für virtuelle Adapter. Der virtuelle Hyper-V Switch is 802.1q-kompatibel und Adapter die zwischen Management-Betriebssystem und VM verwendet werden können einem VLAN zugewiesen werden. Der virtuelle Switch kümmert sich um das Trunking von ein- und ausgehenden Paketen. Die Definition von VLANs kann in den VM-Einstellungen des Hyper-V Managers vorgenommen werden. Mittels PowerShell steht das Kommando „Set-VMNetworkAdapterVLAN“ zur Verfügung.

1 Set-VMNetworkAdapterVlan –ManagementOS –VMNetWorkAdapterName „LiveMigration“ -Access –VlanId 10

Dieser Befehl besitzt viele weitere Optionen, die aber eher für fortgeschrittene Zwecke verwendet werden, wie etwa in einer mandantenfähigen Umgebung.

Cluster

In diesem Beitrag wurde nicht besonders auf Cluster-Umgebungen eingegangen. Hier ist es wichtig zu wissen, dass für jeden virtuellen Adapter einer high-available VM auf einen virtuellen Switch zugreifen kann welcher auf jedem Host den gleichen Namen aufweist. Ausnahme dabei bildet die Zuweisung eines Network Resource Pools. Der Pool-Name muss auf allen Hosts derselbe sein. Also ähnlich wie bei virtuellen Switch Namen.