9
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
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: 62228032050
Url: https://administrator.de/contentid/62228032050
Ausgedruckt am: 24.11.2024 um 16:11 Uhr
9 Kommentare
Neuester Kommentar
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
1
@c.r.s.
Genau so habe ich es jetzt auch gemacht. Die Idee mit der Aufsplittung ist nämlich genau an dem Denkfehler gescheitert, dass ich dem Switch ja keine IP, VLANs etc zuweisen kann. So eine Aufteilung muss dann wohl wieder auf VM Ebene stattfinden, wenn ich den Switch an eine VM dranhänge. Aber das würde das Setup ins Absurde verkomplizieren. Da die Backups eh von einem anderen Device aus gemacht werden, passiert alles Andere dann auch dort.
Danke
Genau so habe ich es jetzt auch gemacht. Die Idee mit der Aufsplittung ist nämlich genau an dem Denkfehler gescheitert, dass ich dem Switch ja keine IP, VLANs etc zuweisen kann. So eine Aufteilung muss dann wohl wieder auf VM Ebene stattfinden, wenn ich den Switch an eine VM dranhänge. Aber das würde das Setup ins Absurde verkomplizieren. Da die Backups eh von einem anderen Device aus gemacht werden, passiert alles Andere dann auch dort.
Danke
Zu früh gefreut. Nachdem ein paar tage alles gut lief hat mir heute der Host nach einem restart einen BSOD geworfen. Dachte erst es wäre nur ein Treiber gewesen, aber am Ende konnte ich das Problem nur lösen indem ich den SET Switch gelöscht habe und die VMs direkt mit den i350ern verbinde. Sobald ich wieder einen SET Switch generiere und verbinden will -> boom BSOD :/
Zitat von @preysa:
Zu früh gefreut. Nachdem ein paar tage alles gut lief hat mir heute der Host nach einem restart einen BSOD geworfen. Dachte erst es wäre nur ein Treiber gewesen, aber am Ende konnte ich das Problem nur lösen indem ich den SET Switch gelöscht habe und die VMs direkt mit den i350ern verbinde. Sobald ich wieder einen SET Switch generiere und verbinden will -> boom BSOD :/
VMQ ist deaktiviert?
1
Wahrscheinlich und RSS wahrscheinlich auch. Zumindest hatte ich wo gelesen, dass das hier auch Probleme machen kann. Hatte jetzt aber nicht mehr die Nerven mich mit mehr Bluescreens und boot loops rumzuärgern. Das Ding soll einfach mal stabil laufen. Vielleicht geb ich dem ganzen nochmal am Wochenende eine Chance 😅
So, ich habe mich heute noch mal ran getraut und VMQ bei allen Adaptern deaktiviert. Danach den SET Switch wieder erstellt und mit den VMs verbunden -> Kein Bluescreen 😅 Ich hoffe das bleibt auf Dauer so. Teu teu teu 😅
1
