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
Please also mark the comments that contributed to the solution of the article
Content-ID: 668996
Url: https://administrator.de/contentid/668996
Printed on: November 4, 2024 at 07:11 o'clock
7 Comments
Latest comment
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
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.