4
Hyper-V vSwitches Frage
Hallo,
es geht mal wieder um das Thema vSwitches im Hyper-V. Da ich von VMware komme, war ich da die einfache plug&play Funktion eines default Switches gewohnt.
Jetzt möchte ich sowas in Hyper-V nachbilden.
Der Host hat ein dedicated LAN Port fürs Management(RDP, etc).
Es gibt noch 4 x 1GB Intel NIC Loms.
Von denen würde ich gerne 2 Anschlüße für VMs und 2 Anschlüße für Backup(später eventuell Live Migration oder Replikation) nutzen.
Aktuell sieht Microsoft hier SET Switches vor. Man kann zwar per bypass noch das alte Teaming benutzen, wenn man aber in die Zukunft schaut wird sowas in Server 2025 schon nicht mehr toleriert(Powershell lehnt die Konfiguration ab).
Wenn man hier die Beiträge durchsucht, wird von Problemen mit SET Switches berichtet. Wie muss ich mir das vorstellen? Sind die in meiner kleinen Umgebung von Bedeutung?
Auf dem Hyper-V laufen eigentlich nur Server System, welche alle im selben VLAN sind. Die VLANs sind auch am CISCO Switch konfiguriert. Eine Firewall kümmert sich um das Regelwerk.
Prinzipiell stell ich mir das so vor(ausgehend von unserer Konfiguration auf dem noch aktiven ESXi):
VM<-->External Switch(SET Teaming o.ä.)<-->CISCO Switch<-->Firewall<-->restliches Netz
Hyper-V<-->External Switch(SET Teaming o.ä.)<-->CISCO Switch<-->Firewall<-->Backup(evtl. Live Migration, Replikation)
Auf unserem ESXi habe ich die LANs nicht so aufgeteilt. Es hing einfach alles am default Switch. Hat auch super funktioniert. Bei Hyper-V ist es aber nach Recherche besser das aufzusplitten?
Ist die Konfiguration, wie ich sie mir vorstelle so logisch und machbar? Was würdet ihr mir empfehlen bezüglich Teaming?
Zur Info:
Der ESXi soll später auch auf Hyper-V umgestellt werden(darum die erwähnte Live Migration
)
Vielen Dank im Voraus.
Grüße
es geht mal wieder um das Thema vSwitches im Hyper-V. Da ich von VMware komme, war ich da die einfache plug&play Funktion eines default Switches gewohnt.
Jetzt möchte ich sowas in Hyper-V nachbilden.
Der Host hat ein dedicated LAN Port fürs Management(RDP, etc).
Es gibt noch 4 x 1GB Intel NIC Loms.
Von denen würde ich gerne 2 Anschlüße für VMs und 2 Anschlüße für Backup(später eventuell Live Migration oder Replikation) nutzen.
Aktuell sieht Microsoft hier SET Switches vor. Man kann zwar per bypass noch das alte Teaming benutzen, wenn man aber in die Zukunft schaut wird sowas in Server 2025 schon nicht mehr toleriert(Powershell lehnt die Konfiguration ab).
Wenn man hier die Beiträge durchsucht, wird von Problemen mit SET Switches berichtet. Wie muss ich mir das vorstellen? Sind die in meiner kleinen Umgebung von Bedeutung?
Auf dem Hyper-V laufen eigentlich nur Server System, welche alle im selben VLAN sind. Die VLANs sind auch am CISCO Switch konfiguriert. Eine Firewall kümmert sich um das Regelwerk.
Prinzipiell stell ich mir das so vor(ausgehend von unserer Konfiguration auf dem noch aktiven ESXi):
VM<-->External Switch(SET Teaming o.ä.)<-->CISCO Switch<-->Firewall<-->restliches Netz
Hyper-V<-->External Switch(SET Teaming o.ä.)<-->CISCO Switch<-->Firewall<-->Backup(evtl. Live Migration, Replikation)
Auf unserem ESXi habe ich die LANs nicht so aufgeteilt. Es hing einfach alles am default Switch. Hat auch super funktioniert. Bei Hyper-V ist es aber nach Recherche besser das aufzusplitten?
Ist die Konfiguration, wie ich sie mir vorstelle so logisch und machbar? Was würdet ihr mir empfehlen bezüglich Teaming?
Zur Info:
Der ESXi soll später auch auf Hyper-V umgestellt werden(darum die erwähnte Live Migration
)Vielen Dank im Voraus.
Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 62228032050
Url: https://administrator.de/contentid/62228032050
Printed on: July 27, 2024 at 11:07 o'clock
4 Comments
Latest comment
Hi.
zunächst mal legst du für jede physische NIC einen VSwitch an...
Ob und wie bzw. wieviele vSwitche/VNics du deinen VMs zuordnest ist dann das nächste ... prinzipiell kannst du mehrere VSwitche aka VNics mehreren VMs zuordnen ...
... und natürlich können die VMs diese dann im Rahmen ihrer Möglichkeiten, also z.B. Teaming, nutzen ...
zunächst mal legst du für jede physische NIC einen VSwitch an...
Ob und wie bzw. wieviele vSwitche/VNics du deinen VMs zuordnest ist dann das nächste ... prinzipiell kannst du mehrere VSwitche aka VNics mehreren VMs zuordnen ...
... und natürlich können die VMs diese dann im Rahmen ihrer Möglichkeiten, also z.B. Teaming, nutzen ...
Moin,
schaust du dir das mal an, da wird alles erklärt.
Hol dir ggf. noch das Windows Admin Center, dann kannst du auch SET Switche in einer GUI erstellen.
Grüße
schaust du dir das mal an, da wird alles erklärt.
Hol dir ggf. noch das Windows Admin Center, dann kannst du auch SET Switche in einer GUI erstellen.
Grüße
Zitat von @preysa:
Ist die Konfiguration, wie ich sie mir vorstelle so logisch und machbar? Was würdet ihr mir empfehlen bezüglich Teaming?
Ich sehe da keinen Hinderungsgrund. Einfach via PowerShell erstellen und die Maschinen daran anbinden.
1
Hallo,
SET-spezifische Probleme sind mir bislang nicht begegnet. Evtl. hängen sie mit einem gleichzeitigen Wechsel von LACP auf Switch-unabhängiges Teaming zusammen. Das dynamische Balancing kann je nach Anwendungsfall und vernetzter Hardware ungeeignet sein. Der Hyper-V-Port-Modus sollte aber immer stabil laufen.
Die Aufteilung der Teams erscheint mir sinnlos, wenn sie nicht eine physische Struktur widerspiegelt. Hier enden sie ja offenbar auf demselben Switch/Stack. Im Allgemeinen würde man die gleichwertigen, d.h. gleich schnellen oder zumindest typgleichen, Adapter in ein Team zusammenfassen. Wenn der Gedanke ist, den Host mit dedizierten Schnittstellen besserzustellen als eine einzelne VM, sollte er die beiden Links ohne vSwitch und Teaming erhalten, damit sie für Multichanneling verwendet werden können. Natürlich kann auch ein zweiter Hostadapter hinzugefügt werden, um dasselbe ausgehend über ein Team zu erreichen, insbesondere an einem mit den VMs geteilten vSwitch. Ein nur vom Host verwendeter vSwitch ist aber überflüssig.
Grüße
Richard
SET-spezifische Probleme sind mir bislang nicht begegnet. Evtl. hängen sie mit einem gleichzeitigen Wechsel von LACP auf Switch-unabhängiges Teaming zusammen. Das dynamische Balancing kann je nach Anwendungsfall und vernetzter Hardware ungeeignet sein. Der Hyper-V-Port-Modus sollte aber immer stabil laufen.
Die Aufteilung der Teams erscheint mir sinnlos, wenn sie nicht eine physische Struktur widerspiegelt. Hier enden sie ja offenbar auf demselben Switch/Stack. Im Allgemeinen würde man die gleichwertigen, d.h. gleich schnellen oder zumindest typgleichen, Adapter in ein Team zusammenfassen. Wenn der Gedanke ist, den Host mit dedizierten Schnittstellen besserzustellen als eine einzelne VM, sollte er die beiden Links ohne vSwitch und Teaming erhalten, damit sie für Multichanneling verwendet werden können. Natürlich kann auch ein zweiter Hostadapter hinzugefügt werden, um dasselbe ausgehend über ein Team zu erreichen, insbesondere an einem mit den VMs geteilten vSwitch. Ein nur vom Host verwendeter vSwitch ist aber überflüssig.
Grüße
Richard