7
HyperV VLANS mit mehreren NICs
Hallo zusammen,
ich benötige einen Rat, wie ich am besten folgende Situation konfiguriere:
Ich habe ein kleines Netzwerk (siehe Abbildung), dass ich mit verschiedenen VLAN konfiguriert habe.
Mich würde nun interessieren, wie ich den HyperV Host und die VMs einbinde.
Der Server ist mit 3 NICs ausgestattet, davon ist eine für den iDRAC (NIC3) vorgesehen.
Auf dem HxperV sollen VMs unterschiedlicher VLANs laufen.
Mein erster Ansatz war:
NIC1 dediziert für den Host, Management VLAN20. Am Switch als AccessPort mit VLAN20
NIC2 für die VMs, hier war ich mir aber dann schon nicht mehr sicher, wie ich den Switch, den vSwitch und die Konfig der VM-Netzwerkkarte einstelle.
Zudem kam nun dier Gedanke auf unterschiedliche VLANS den VMs zuzuweisen.
Daher habe ich im Netz und auf eurer seite recherchiert und habe nun einen anderen Plan, bevor ich deisen aber umsetze, wollte ich fragen, ob das so korrekt und sinnvoll ist:
1) NIC1+NIC2 auf dem Switch als LAG-Trunk definieren, sowie auf dem Windows Server als Teaming-Trunk
2) In der HyperV einen vSwitch-external erstellen (mache ich hier irgendwelche VLAN Einstellungen?
3) Dem auf dem Host angezeigten Netzwerkadapter des vSwictch-external eine feste IP aus dem VLAN20 zuweisen
4) Die Netzwerkkonfig in den VMs mit der jeweiligen VLAN 10 bzw.11 versehen.
Wäre das so korrekt?
Ich bin leider unterwegs und komme erst nächste Woche dazu, das umzusetzen bzw. zu testen, aber ich möchte schonmal in der Theorie das Vorgehen planen.
Danke für eure Tipps
Thorsten
ich benötige einen Rat, wie ich am besten folgende Situation konfiguriere:
Ich habe ein kleines Netzwerk (siehe Abbildung), dass ich mit verschiedenen VLAN konfiguriert habe.
Mich würde nun interessieren, wie ich den HyperV Host und die VMs einbinde.
Der Server ist mit 3 NICs ausgestattet, davon ist eine für den iDRAC (NIC3) vorgesehen.
Auf dem HxperV sollen VMs unterschiedlicher VLANs laufen.
Mein erster Ansatz war:
NIC1 dediziert für den Host, Management VLAN20. Am Switch als AccessPort mit VLAN20
NIC2 für die VMs, hier war ich mir aber dann schon nicht mehr sicher, wie ich den Switch, den vSwitch und die Konfig der VM-Netzwerkkarte einstelle.
Zudem kam nun dier Gedanke auf unterschiedliche VLANS den VMs zuzuweisen.
Daher habe ich im Netz und auf eurer seite recherchiert und habe nun einen anderen Plan, bevor ich deisen aber umsetze, wollte ich fragen, ob das so korrekt und sinnvoll ist:
1) NIC1+NIC2 auf dem Switch als LAG-Trunk definieren, sowie auf dem Windows Server als Teaming-Trunk
2) In der HyperV einen vSwitch-external erstellen (mache ich hier irgendwelche VLAN Einstellungen?
3) Dem auf dem Host angezeigten Netzwerkadapter des vSwictch-external eine feste IP aus dem VLAN20 zuweisen
4) Die Netzwerkkonfig in den VMs mit der jeweiligen VLAN 10 bzw.11 versehen.
Wäre das so korrekt?
Ich bin leider unterwegs und komme erst nächste Woche dazu, das umzusetzen bzw. zu testen, aber ich möchte schonmal in der Theorie das Vorgehen planen.
Danke für eure Tipps
Thorsten
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668996
Url: https://administrator.de/contentid/668996
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
7 Kommentare
Neuester Kommentar
Ich bin nicht sicher ob ich richtig verstanden habe, du möchtest mehrere VLANs auf einem Hyper-V Host einrichten und dabei mehrere Netzwerkkarten nutzen. Dein Ziel ist es, zwei NICs zu zu bündelns, um Redundanz und höhere Bandbreite zu ermöglichen, und über einen virtuellen Switch (vSwitch) die VLAN-Tags zu verwalten. Du fragst, ob diese Konfiguration sinnvoll ist und wie die VLAN-Zuweisungen am besten umgesetzt werden sollten, damit die VMs verschiedene VLANs nutzen können.
Richtig ?
Richtig ?
Moin,
Korrekt, bedenke aber, dass LBFO Teams für HyperV ab Server 2022 nicht mehr unterstützt werden. Bei Switch Embedded Teaming darf auf dem Switch kein Trunk angelegt werden.
Wenn der Host das Team mit nutzen soll, stellst du hier das VLAN für den Host ein.
Richtig.
Auch richtig.
Gruß,
Avoton
NIC1+NIC2 auf dem Switch als LAG-Trunk definieren, sowie auf dem Windows Server als Teaming-Trunk
Korrekt, bedenke aber, dass LBFO Teams für HyperV ab Server 2022 nicht mehr unterstützt werden. Bei Switch Embedded Teaming darf auf dem Switch kein Trunk angelegt werden.
2) In der HyperV einen vSwitch-external erstellen (mache ich hier irgendwelche VLAN Einstellungen?
Wenn der Host das Team mit nutzen soll, stellst du hier das VLAN für den Host ein.
3) Dem auf dem Host angezeigten Netzwerkadapter des vSwictch-external eine feste IP aus dem VLAN20 zuweisen
Richtig.
4) Die Netzwerkkonfig in den VMs mit der jeweiligen VLAN 10 bzw.11 versehen
Auch richtig.
Gruß,
Avoton
1
4) Die Netzwerkkonfig in den VMs mit der jeweiligen VLAN 10 bzw.11 versehen
Nicht "in den VM's", sondern "im Hyper-V Manager", die Netzwerkkarte für die jeweilige VMDie VM's erhalten dann das VLAN untagged und darin muss nichts mehr eingestellt werden.
3
@spok 71 Ja, so war es gemeint.
Also der KI-Agent meinte zu mir:
Avotons Antwort ist grundsätzlich korrekt, aber es wäre hilfreich, einige Punkte klarzustellen:
Switch Embedded Teaming (SET): Wichtig ist, dass SET nur an einem Single Logical Interface arbeitet und keine VLAN-Tagging-Konfiguration auf dem Switch erforderlich ist. Avoton erwähnte dies, aber es wäre gut, auf die möglichen Unterschiede beim Netzwerkverkehr im Vergleich zu LBFO hinzuweisen.
VLAN-Konfiguration: Bei SET sollten VLANs direkt den VMs zugewiesen werden, ohne den vSwitch mit einem VLAN zu konfigurieren. Dies vermeidet Missverständnisse bei der Netzwerksegmentierung.
Physische Switch-Konfiguration: Bei SET auf dem Switch sicherstellen, dass alle VLANs freigeschaltet und ohne Trunk definiert sind.
Damit wären alle Aspekte für eine erfolgreiche Implementierung sauber abgedeckt.
Als ich dann weiter gebohrt habe, meinte er:
Die Unterschiede zwischen LBFO (Load Balancing/Failover) und SET (Switch Embedded Teaming) liegen vor allem in der Architektur und Funktionsweise:
1. LBFO und SET Architektur: LBFO erlaubt eine flexiblere Trunking-Konfiguration, bei der VLAN-Tagging über den vSwitch und den physischen Switch gesteuert wird. Bei SET werden VLANs ausschließlich auf den VMs konfiguriert.
2. Leistungsoptimierung: SET ist besser integriert und optimiert für Windows Server ab 2016/2019, speziell für Hyper-V, und bietet bessere Skalierbarkeit und Performance.
3. Kompatibilität: Ab Server 2022 wird LBFO für Hyper-V nicht mehr unterstützt, daher muss auf SET gewechselt werden, was auch bessere Unterstützung für SDN und virtuelle Netzwerke bietet.
Avotons Antwort ist grundsätzlich korrekt, aber es wäre hilfreich, einige Punkte klarzustellen:
Switch Embedded Teaming (SET): Wichtig ist, dass SET nur an einem Single Logical Interface arbeitet und keine VLAN-Tagging-Konfiguration auf dem Switch erforderlich ist. Avoton erwähnte dies, aber es wäre gut, auf die möglichen Unterschiede beim Netzwerkverkehr im Vergleich zu LBFO hinzuweisen.
VLAN-Konfiguration: Bei SET sollten VLANs direkt den VMs zugewiesen werden, ohne den vSwitch mit einem VLAN zu konfigurieren. Dies vermeidet Missverständnisse bei der Netzwerksegmentierung.
Physische Switch-Konfiguration: Bei SET auf dem Switch sicherstellen, dass alle VLANs freigeschaltet und ohne Trunk definiert sind.
Damit wären alle Aspekte für eine erfolgreiche Implementierung sauber abgedeckt.
Als ich dann weiter gebohrt habe, meinte er:
Die Unterschiede zwischen LBFO (Load Balancing/Failover) und SET (Switch Embedded Teaming) liegen vor allem in der Architektur und Funktionsweise:
1. LBFO und SET Architektur: LBFO erlaubt eine flexiblere Trunking-Konfiguration, bei der VLAN-Tagging über den vSwitch und den physischen Switch gesteuert wird. Bei SET werden VLANs ausschließlich auf den VMs konfiguriert.
2. Leistungsoptimierung: SET ist besser integriert und optimiert für Windows Server ab 2016/2019, speziell für Hyper-V, und bietet bessere Skalierbarkeit und Performance.
3. Kompatibilität: Ab Server 2022 wird LBFO für Hyper-V nicht mehr unterstützt, daher muss auf SET gewechselt werden, was auch bessere Unterstützung für SDN und virtuelle Netzwerke bietet.
Danke für eure schnelle Hilfe.
Was ich aber noch nicht ganz verstehe, was ich nun auf dem physischen Switch auf den Ports einstelle. Kein LAG? OK, aber welche VLAN Konfig? Untagged mit welchem VLAN?
@SPOK71 Was meinst du mit " alle VLANs freigeschalet und ohne trunk definiert sind"?
Was ich aber noch nicht ganz verstehe, was ich nun auf dem physischen Switch auf den Ports einstelle. Kein LAG? OK, aber welche VLAN Konfig? Untagged mit welchem VLAN?
@SPOK71 Was meinst du mit " alle VLANs freigeschalet und ohne trunk definiert sind"?
aber welche VLAN Konfig? Untagged mit welchem VLAN?
Nein, die VLANs natürlich Tagged übertragen an beiden Ports, wo der HyperV dran hängt.
Alles, was du im HyperV bzgl VLAN einstellst, ist tagged.
In welchem VLAN untagged Traffic landen soll, weißt nur du ;)
Gruß,
Avoton
