11
Hyper-V 2019 LANs in VM konfigurieren
Hallo, allen einen freudigen 1. Mai !
Bezugnehmend auf meinen letzten Thread:
Zwei Windows Server 2019 auf einer Maschine
Habe den HOST installiert und die beiden VM's angelegt.
Was ich nicht ganz hinbekomme:
Das Servermainboard hat 2 Intel 10 Gbit Schnittstellen onBoard.
Zusätzlich eine PCIe 1 Gbit Realtek Karte hinzugefügt.
Die Realtek ist nur für den HOST.
Statische IP: 192.168.0.3
Gateway: 192.168.0.100
Die OnBoard sollen so konfiguriert sein, dass die erste VM (wird der Domänencontroller mit AD)
eine Netzwerkkarte 10 Gbit zugewiesen bekommt.
Statische IP: 192.168.0.1
Die 2. VM die zweite Netzwerkkarte 10 Gbit zugewiesen bekommt.
Statische IP: 192.168.0.2
Bekomm das nicht hin.
Könnt ihr mir bitte behilflich sein?
Vielen Dank!
Bezugnehmend auf meinen letzten Thread:
Zwei Windows Server 2019 auf einer Maschine
Habe den HOST installiert und die beiden VM's angelegt.
Was ich nicht ganz hinbekomme:
Das Servermainboard hat 2 Intel 10 Gbit Schnittstellen onBoard.
Zusätzlich eine PCIe 1 Gbit Realtek Karte hinzugefügt.
Die Realtek ist nur für den HOST.
Statische IP: 192.168.0.3
Gateway: 192.168.0.100
Die OnBoard sollen so konfiguriert sein, dass die erste VM (wird der Domänencontroller mit AD)
eine Netzwerkkarte 10 Gbit zugewiesen bekommt.
Statische IP: 192.168.0.1
Die 2. VM die zweite Netzwerkkarte 10 Gbit zugewiesen bekommt.
Statische IP: 192.168.0.2
Bekomm das nicht hin.
Könnt ihr mir bitte behilflich sein?
Vielen Dank!
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: 2657364540
Url: https://administrator.de/forum/hyper-v-2019-lans-in-vm-konfigurieren-2657364540.html
Ausgedruckt am: 25.12.2024 um 13:12 Uhr
11 Kommentare
Neuester Kommentar
Moin,
Warum eine statsiche Zuweisung der Netzwerkadapter? Ich hätte eine NIC-Teaming Windows-Server eingerichtet dies funktioniert auch wenn der Switch kein LACP beherrscht. Somit hättest du gleich eine Redundanz wenn der Link mal aus unbegreiflichen Dingen wegfallen sollte. Aber ansonsten geht das auch wie du es vor hast. Du legst dir einfach im Hyper-V Manger zwei virtuelle Switche an mit der jeweiligen Karte und machst den Haken bei Hostkommunikation raus. Dann hast du die 2 x 10Gbit/s ausschließlich für die VM‘s und die Realtek bedient den Host.
Grüße
Niklas
Warum eine statsiche Zuweisung der Netzwerkadapter? Ich hätte eine NIC-Teaming Windows-Server eingerichtet dies funktioniert auch wenn der Switch kein LACP beherrscht. Somit hättest du gleich eine Redundanz wenn der Link mal aus unbegreiflichen Dingen wegfallen sollte. Aber ansonsten geht das auch wie du es vor hast. Du legst dir einfach im Hyper-V Manger zwei virtuelle Switche an mit der jeweiligen Karte und machst den Haken bei Hostkommunikation raus. Dann hast du die 2 x 10Gbit/s ausschließlich für die VM‘s und die Realtek bedient den Host.
Grüße
Niklas
Moin MKW,
schau dir mal dieses Tutorial an. 😉
https://www.youtube.com/watch?v=3rjWcv3RRK8
Beste Grüsse aus BaWü
Alex
P.S.
Bitte KEIN NIC-Teaming verwenden, ausser du stehst besonders auf Masochismus. 🤪
LBFO wird seit Server 2016 nicht mehr weiterentwickelt und oder getestet und SET
funktioniert nur mit bestimmten Adaptern korrekt, aber auch nur, wein man händisch massiv nachjustiert hat. 😔
schau dir mal dieses Tutorial an. 😉
https://www.youtube.com/watch?v=3rjWcv3RRK8
Beste Grüsse aus BaWü
Alex
P.S.
Bitte KEIN NIC-Teaming verwenden, ausser du stehst besonders auf Masochismus. 🤪
LBFO wird seit Server 2016 nicht mehr weiterentwickelt und oder getestet und SET
funktioniert nur mit bestimmten Adaptern korrekt, aber auch nur, wein man händisch massiv nachjustiert hat. 😔
Moin,
auch ich würde Teaming einsetzen. Habe damit bisher keine schlechten Erfahrungen gemacht.
Ansonsten aber wie @niklasschaefer schrieb. Du legst im HV-Manager einfach zwei vSwitche an und koppelst daran jeweils einen der Ports und deaktivierst den "gemeinsamen Zugriff" mit der Host-Maschine. Diese weist du dann den entsprechenden VMs zu. Die Netzwerkkonfiguration der VMs nimmst du, wie gehabt, in den VMs selbst vor.
Gruß
auch ich würde Teaming einsetzen. Habe damit bisher keine schlechten Erfahrungen gemacht.
Ansonsten aber wie @niklasschaefer schrieb. Du legst im HV-Manager einfach zwei vSwitche an und koppelst daran jeweils einen der Ports und deaktivierst den "gemeinsamen Zugriff" mit der Host-Maschine. Diese weist du dann den entsprechenden VMs zu. Die Netzwerkkonfiguration der VMs nimmst du, wie gehabt, in den VMs selbst vor.
Gruß
Moin arnonymous,
Ähm, MKW möchte der VM-A die IP 192.168.0.1 verpassen und der VB-B die IP 192.168.0.2, sprich, beide VM sind im selben Segment. Warum sollte man in dieser Konstellation zwei vSwitche erstellen?
@MKW
Erstelle einen vSwitch mit zuerst nur einem physikalischen NIC-Port als Uplink und hänge beide VM's an diesen vSwitch und schon bist du am Ziel.
Beste Grüsse aus BaWü
Alex
auch ich würde Teaming einsetzen. Habe damit bisher keine schlechten Erfahrungen gemacht.
versuche es mal ohne, vor allem wenn du Server =>2019 verwendest. 😉Ansonsten aber wie @niklasschaefer schrieb. Du legst im HV-Manager einfach zwei vSwitche an und koppelst daran jeweils einen der Ports und deaktivierst den "gemeinsamen Zugriff" mit der Host-Maschine. Diese weist du dann den entsprechenden VMs zu. Die Netzwerkkonfiguration der VMs nimmst du, wie gehabt, in den VMs selbst vor.
Ähm, MKW möchte der VM-A die IP 192.168.0.1 verpassen und der VB-B die IP 192.168.0.2, sprich, beide VM sind im selben Segment. Warum sollte man in dieser Konstellation zwei vSwitche erstellen?
@MKW
Erstelle einen vSwitch mit zuerst nur einem physikalischen NIC-Port als Uplink und hänge beide VM's an diesen vSwitch und schon bist du am Ziel.
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Ähm, MKW möchte der VM-A die IP 192.168.0.1 verpassen und der VB-B die IP 192.168.0.2, sprich, beide VM sind im selben Segment. Warum sollte man in dieser Konstellation zwei vSwitche erstellen?
Ansonsten aber wie @niklasschaefer schrieb. Du legst im HV-Manager einfach zwei vSwitche an und koppelst daran jeweils einen der Ports und deaktivierst den "gemeinsamen Zugriff" mit der Host-Maschine. Diese weist du dann den entsprechenden VMs zu. Die Netzwerkkonfiguration der VMs nimmst du, wie gehabt, in den VMs selbst vor.
Ähm, MKW möchte der VM-A die IP 192.168.0.1 verpassen und der VB-B die IP 192.168.0.2, sprich, beide VM sind im selben Segment. Warum sollte man in dieser Konstellation zwei vSwitche erstellen?
Ähm, weil ich es so versanden hatte, dass er jeder VM einen dedizierten Port zuweisen möchte.
Sollte das nicht so sein, reicht natürlich auch ein vSwitch aus, klar.
@MysticFoxDE: Also NIC Teaming benutze ich mit LACP an Cisco Switchen bei Server 2016 und Server 2022 ohne Probleme.
Wüsste nicht warum er darauf verzichten sollte.
Ansonsten schrieb er doch, er möchte jeder VM eine NIC zuweisen. Deswegen zwei virtuelle Switche und jeder VM weist er einen zu.
Wüsste nicht warum er darauf verzichten sollte.
Ansonsten schrieb er doch, er möchte jeder VM eine NIC zuweisen. Deswegen zwei virtuelle Switche und jeder VM weist er einen zu.
Zitat von @Xaero1982:
@MysticFoxDE: Also NIC Teaming benutze ich mit LACP an Cisco Switchen bei Server 2016 und Server 2022 ohne Probleme.
Wüsste nicht warum er darauf verzichten sollte.
@MysticFoxDE: Also NIC Teaming benutze ich mit LACP an Cisco Switchen bei Server 2016 und Server 2022 ohne Probleme.
Wüsste nicht warum er darauf verzichten sollte.
Ich konfiguriere hier gerade einen neuen Hyper-V Host mit Server 2022 und wollte ebenfalls auf NIC Teaming setzen um entsprechende Redundanz zu haben - ist ja auch äußerst praktisch.
Ich wüsste nun auch mal gern warum das mit 2019/2022 nicht gemacht werden soll, vor allem da Microsoft die Funktion auch bei 2022 aufweist:
https://docs.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfote ...
Ich scheitere allerdings gerade daran ein Team fürs Management einzurichten, dort mag er mir keine IP-Adresse in der Powershell annehmen und ich kann Dhcp per Powershell nicht deaktivieren (letzteres allerdings unabhängig von Teaming)... mal sehen.
Edit: ich glaube was @MysticFoxDE meint ist, dass LBFO nicht mehr existent ist, dafür gibt es aber SET mit Hyper-V: https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
...damit habe ich die über den Server-Manager angelegten Teams erstmal gekillt, das läuft wohl noch über LBFO.
Hallo,
danke für die Infos von euch.
Habe die beiden Intel OnBoard LANs als Team eingerichtet.
Das läuft bei mir nicht stabil.
Setzte ich ein Ping auf die andere VM oder den Host funktioniert es mal, dann wieder nicht.
Egal, von welcher VM oder Host ich den Ping sende.
Ich trenne das mal und setzte die Intels als eigene Switche
danke für die Infos von euch.
Habe die beiden Intel OnBoard LANs als Team eingerichtet.
Das läuft bei mir nicht stabil.
Setzte ich ein Ping auf die andere VM oder den Host funktioniert es mal, dann wieder nicht.
Egal, von welcher VM oder Host ich den Ping sende.
Ich trenne das mal und setzte die Intels als eigene Switche
Hallo,
habe die Netzwerkkarten jetzt als einzelne Switche konfiguriert.
Jetzt funktioniert alles einwandfrei, so wie ich das wollte.
Danke an alle für Eure Mühe, habe viel Input erhalten !
habe die Netzwerkkarten jetzt als einzelne Switche konfiguriert.
Jetzt funktioniert alles einwandfrei, so wie ich das wollte.
Danke an alle für Eure Mühe, habe viel Input erhalten !
Moin MKW,
du benötigst keine zwei vSwitche um zwei VM's in Netz zu lassen, hänge beide einfach an denselben vSwitch, ist performancetechnisch in den meisten Fällen eh besser.
Beste Grüsse aus BaWü
Alex
habe die Netzwerkkarten jetzt als einzelne Switche konfiguriert.
du benötigst keine zwei vSwitche um zwei VM's in Netz zu lassen, hänge beide einfach an denselben vSwitch, ist performancetechnisch in den meisten Fällen eh besser.
Beste Grüsse aus BaWü
Alex
Moin dertowa,
Wenn das Teaming bei MS zum Teil nicht massiv Performance kosten würde, dann wäre ich zu 100% bei dir.
Ja, der Server 2022 unterstützt noch LBFO aber nicht was das SDN angeht, zumindest möchte MS nicht,
dass man es beim SDN verwendet, weil die LBFO seit Server 2012R2, schlichtweg nicht mehr weiterentwickelt haben und es seit dem einfach nur ungetestet mitschleifen. 🤮
Bitte sehr, musst nur noch InterfaceIndex durch den Wert von dem entsprechenden Team ersetzen. 😉
Ohh, ich sehe du hast meine englischen MS-Lästergeschichten bei Spiceworks ausgegraben. 😀🤪
Ja, LBFO haben die bei SDN des Server 2022 gekillt, so halb zumindest.
Wie du aus meinem letzten Post erkennen kannst ...
https://community.spiceworks.com/topic/post/9451679
kannst du ein LBFO-Team per PowerShell und einem undokumentierten Zusatzparameter,
dann aber doch einem vSwitch als Uplink unterjubeln. 🙃
Die PN beantworte ich, nachdem ich meine Akkus wieder etwas aufgeladen habe.
Beste Grüsse aus BaWü
Alex
Ich konfiguriere hier gerade einen neuen Hyper-V Host mit Server 2022 und wollte ebenfalls auf NIC Teaming setzen um entsprechende Redundanz zu haben - ist ja auch äußerst praktisch.
Wenn das Teaming bei MS zum Teil nicht massiv Performance kosten würde, dann wäre ich zu 100% bei dir.
Ich wüsste nun auch mal gern warum das mit 2019/2022 nicht gemacht werden soll, vor allem da Microsoft die Funktion auch bei 2022 aufweist:
https://docs.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfote ...
https://docs.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfote ...
Ja, der Server 2022 unterstützt noch LBFO aber nicht was das SDN angeht, zumindest möchte MS nicht,
dass man es beim SDN verwendet, weil die LBFO seit Server 2012R2, schlichtweg nicht mehr weiterentwickelt haben und es seit dem einfach nur ungetestet mitschleifen. 🤮
Ich scheitere allerdings gerade daran ein Team fürs Management einzurichten, dort mag er mir keine IP-Adresse in der Powershell annehmen und ich kann Dhcp per Powershell nicht deaktivieren (letzteres allerdings unabhängig von Teaming)... mal sehen.
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\$((Get-NetAdapter -InterfaceIndex 5).InterfaceGuid)” -Name EnableDHCP -Value 0
Remove-NetIpAddress -InterfaceIndex 5 -AddressFamily IPv4
Remove-NetRoute -InterfaceIndex 5 -AddressFamily IPv4 -Confirm:$false
New-NetIpAddress -InterfaceIndex 5 -IPAddress 192.168.0.10 -PrefixLength 24 -DefaultGateway 192.168.0.254 -AddressFamily IPv4
Set-DnsClientServerAddress -InterfaceIndex 5 -ServerAddresses ("192.168.0.1", "192.168.0.1") Bitte sehr, musst nur noch InterfaceIndex durch den Wert von dem entsprechenden Team ersetzen. 😉
Edit: ich glaube was @MysticFoxDE meint ist, dass LBFO nicht mehr existent ist, dafür gibt es aber SET mit Hyper-V: https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
...damit habe ich die über den Server-Manager angelegten Teams erstmal gekillt, das läuft wohl noch über LBFO.
...damit habe ich die über den Server-Manager angelegten Teams erstmal gekillt, das läuft wohl noch über LBFO.
Ohh, ich sehe du hast meine englischen MS-Lästergeschichten bei Spiceworks ausgegraben. 😀🤪
Ja, LBFO haben die bei SDN des Server 2022 gekillt, so halb zumindest.
Wie du aus meinem letzten Post erkennen kannst ...
https://community.spiceworks.com/topic/post/9451679
kannst du ein LBFO-Team per PowerShell und einem undokumentierten Zusatzparameter,
dann aber doch einem vSwitch als Uplink unterjubeln. 🙃
Die PN beantworte ich, nachdem ich meine Akkus wieder etwas aufgeladen habe.
Beste Grüsse aus BaWü
Alex
