Hyper-V Cluster: Hardware-Tausch mit Hyper-V-Upgrade
Hallo Kollegen!
Es geht um ein bestehendes Windows Server 2016 (Datacenter) Hyper-V-Cluster mit drei Knoten (ohne SCVMM).
Die Hardware aller drei Knoten wird ausgetauscht (HPE DL380 Gen9 => Dell R7615).
Alle Daten / VMs liegen auf einem SAN (iSCSI). Gesichert werden die VMs durch Veeam.
Ziel ist es auch, das bestehende Cluster (final) auf Server 2025 zu aktualisieren.
Geplant ist aktuell folgendes Vorgehen:
Auf folgende Infos bin ich bisher gestossen:
https://learn.microsoft.com/en-us/windows-server/failover-clustering/clu ...
Inplace-Upgrade Server W2K16 Hyper-V nach W2K22
Muss zwingend das Cluster-Function-Level Schritt für Schritt erhöht werden?
Hat jemand vielleicht schon versucht, ein derartiges Cluster direkt von 2016 auf 2025 umzustellen?
Sind Probleme bekannt wenn eine VM, die unter der Hyper-V-Rolle Server 2016
gesichert wurde, unter Hyper-V-Rolle Server 2025 wiederhergestellt wird?
Es geht um ein bestehendes Windows Server 2016 (Datacenter) Hyper-V-Cluster mit drei Knoten (ohne SCVMM).
Die Hardware aller drei Knoten wird ausgetauscht (HPE DL380 Gen9 => Dell R7615).
Alle Daten / VMs liegen auf einem SAN (iSCSI). Gesichert werden die VMs durch Veeam.
Ziel ist es auch, das bestehende Cluster (final) auf Server 2025 zu aktualisieren.
Geplant ist aktuell folgendes Vorgehen:
- Ersten Knoten komplett aus dem Rennen nehmen (VMs umziehen, Remove-ClusterNode, etc.)
- Knoten auf neuer Hardware unter Server 2019 vollständig aufsetzen
- Neuen Knoten ins Cluster nehmen, VMs wieder zurück unziehen
- Cluster-Function-Level für VMs auf dem Hypervisor erhöhen
- Prozedur für zweiten und dritten Knoten wiederholen
- inplace-Upgrade auf Server 2022 für Knoten 1 bis 3 (von der Prozedur her fast gleich wie oben)
- inplace-Upgrade auf Server 2025 ...
Auf folgende Infos bin ich bisher gestossen:
https://learn.microsoft.com/en-us/windows-server/failover-clustering/clu ...
Inplace-Upgrade Server W2K16 Hyper-V nach W2K22
Muss zwingend das Cluster-Function-Level Schritt für Schritt erhöht werden?
Hat jemand vielleicht schon versucht, ein derartiges Cluster direkt von 2016 auf 2025 umzustellen?
Sind Probleme bekannt wenn eine VM, die unter der Hyper-V-Rolle Server 2016
gesichert wurde, unter Hyper-V-Rolle Server 2025 wiederhergestellt wird?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672561
Url: https://administrator.de/forum/hyper-v-cluster-hardware-tausch-mit-hyper-v-upgrade-672561.html
Ausgedruckt am: 12.05.2025 um 01:05 Uhr
11 Kommentare
Neuester Kommentar
Korrektur
Ne Migration kannst du vergessen, man kann Intel und AMD in einem Cluster nicht mischen. Daher neuen Cluster daneben bauen und dann offline die VMs migrieren.
- Ersten Knoten komplett aus dem Rennen nehmen (VMs umziehen, Remove-ClusterNode, etc.)
- Knoten auf neuer Hardware unter Server 2019 vollständig aufsetzen
- Neuen Knoten ins Cluster nehmen, VMs wieder zurück unziehen
- Cluster-Function-Level für VMs auf dem Hypervisor erhöhen
- Prozedur für zweiten und dritten Knoten wiederholen
* inplace-Upgrade auf Server 2022 für Knoten 1 bis 3 (von der Prozedur her fast gleich wie oben)
Ich würde die Knoten auch für die weiteren Upgrades neu installieren. Für das Inplace Upgrade mußt du die Knoten eh aus dem Cluster nehmen und für die paar Settings kann man sich ja ein Powershell Script schreiben..- inplace-Upgrade auf Server 2025 ...
Muss zwingend das Cluster-Function-Level Schritt für Schritt erhöht werden?
Ja, der Cluster unterstützt bei den OS Versionen nur n+1Hat jemand vielleicht schon versucht, ein derartiges Cluster direkt von 2016 auf 2025 umzustellen?
Das funktioniert nicht (weil n+1)Sind Probleme bekannt wenn eine VM, die unter der Hyper-V-Rolle Server 2016
gesichert wurde, unter Hyper-V-Rolle Server 2025 wiederhergestellt wird?´
Kannst du machen, du mußt halt anschließend auch hier die Configuration Version erhöhengesichert wurde, unter Hyper-V-Rolle Server 2025 wiederhergestellt wird?´
Wenn es vom Storage her paßt würde ich den Cluster neu neben dem alten Cluster installieren und die VMs migrieren.
/Thomas
Kannst du machen, du mußt halt anschließend auch hier die Configuration Version erhöhen
Laut der Tabelle hier kann ich mir damit Zeit lassen (vorausgesetzt, dass alle VMs auf Verison 8.0 sind),
solange ich nicht neue Features verwenden möchte - richtig?
Wenn es vom Storage her paßt würde ich den Cluster neu neben dem alten Cluster installieren und die VMs migrieren.
Vielen Dank für den Tipp!
Mir scheint das auch der sauberere Weg zu sein.
Ich werd´ mich wieder melden und von meinen Erfahrungen berichten.
Frohe Ostern!
Moin @Th0mKa,
ja, in einem produktiven Betrieb sollte man das nicht machen und es ist auch nicht offiziell supportet, aber,
technisch sollte das jedoch funktionieren.
Was jedoch ganz sicher nicht funktioniert, ist Live-Migration von Intel zu AMD. 🙃
Wenn man die VM's vorher jedoch komplett herunterfährt, dann sollte man diese ohne Probleme von einem Intel Node auf einen AMD Node, sprich, offline verschieben können.
Danach muss man die VM's vielleicht etwas nachkonfigurieren, weil z.B. eine andere vNIC erkannt wurde, ansonsten sehe ich, zumindest was Windows VM's angeht, nicht wirklich grössere Probleme.
Ich würde mir jetzt als nächstes eines der neuen Systeme schnappen und auf diesem Server 2019 installieren.
Danach würde ich diesen Hyper-V 2019er Node mal in das bestehende Cluster mit reinhängen und dann mit einer unkritischen VM das versuchen, was ich oben beschrieben habe, sprich, die VM ausschalten, auf den neuen Node schieben und dort wieder einschalten.
Wenn das funktioniert, dann kann der TO auch die restlichen neuen Nodes, erstmal mit Server 2019 installiert in das bestehende 2016er Cluster dazu packen und im nächsten Schritt, quasi erstmal von Intel zu AMD und von HV-2016 auf HV-2019 migrieren. Wenn alle VM's von den alten HV's verschoben sind und die alten HV's aus dem Cluster entfernt wurden, sollte man das bestehende Cluster auch auf 2019er Level heraufstufen können.
Und im nächsten Schritt/Meilenstein, würde ich dann hingehen und versuchen das neue/alte Cluster, auf HV-2022 oder gar gleich HV-2025 anzuheben, aber genau so wie du beschrieben hast, sprich, durch eine Neuinstallation der Nodes und auf keinen Fall ein Inplace-Upgrade.
So spart sich der TO die Einrichtung und die Migration in ein komplett neues Cluster was auch nicht wenig an Aufwand verursacht.
Zudem muss er in diesem Fall dann auch keine zusätzliche Storage-Kapazitäten für die Migration bereitstellen, sondern kann die bestehenden LUN's quasi einfach weiternutzen.
Gruss Alex
Ne Migration kannst du vergessen, man kann Intel und AMD in einem Cluster nicht mischen.
ja, in einem produktiven Betrieb sollte man das nicht machen und es ist auch nicht offiziell supportet, aber,
technisch sollte das jedoch funktionieren.
Was jedoch ganz sicher nicht funktioniert, ist Live-Migration von Intel zu AMD. 🙃
Wenn man die VM's vorher jedoch komplett herunterfährt, dann sollte man diese ohne Probleme von einem Intel Node auf einen AMD Node, sprich, offline verschieben können.
Danach muss man die VM's vielleicht etwas nachkonfigurieren, weil z.B. eine andere vNIC erkannt wurde, ansonsten sehe ich, zumindest was Windows VM's angeht, nicht wirklich grössere Probleme.
Ich würde mir jetzt als nächstes eines der neuen Systeme schnappen und auf diesem Server 2019 installieren.
Danach würde ich diesen Hyper-V 2019er Node mal in das bestehende Cluster mit reinhängen und dann mit einer unkritischen VM das versuchen, was ich oben beschrieben habe, sprich, die VM ausschalten, auf den neuen Node schieben und dort wieder einschalten.
Wenn das funktioniert, dann kann der TO auch die restlichen neuen Nodes, erstmal mit Server 2019 installiert in das bestehende 2016er Cluster dazu packen und im nächsten Schritt, quasi erstmal von Intel zu AMD und von HV-2016 auf HV-2019 migrieren. Wenn alle VM's von den alten HV's verschoben sind und die alten HV's aus dem Cluster entfernt wurden, sollte man das bestehende Cluster auch auf 2019er Level heraufstufen können.
Und im nächsten Schritt/Meilenstein, würde ich dann hingehen und versuchen das neue/alte Cluster, auf HV-2022 oder gar gleich HV-2025 anzuheben, aber genau so wie du beschrieben hast, sprich, durch eine Neuinstallation der Nodes und auf keinen Fall ein Inplace-Upgrade.
So spart sich der TO die Einrichtung und die Migration in ein komplett neues Cluster was auch nicht wenig an Aufwand verursacht.
Zudem muss er in diesem Fall dann auch keine zusätzliche Storage-Kapazitäten für die Migration bereitstellen, sondern kann die bestehenden LUN's quasi einfach weiternutzen.
Gruss Alex
Moin @Uwe.at.Home:
du solltest schon die Version der VM's auch mit anheben.
Denn du wirst wahrscheinlich, wenn nicht schon geschehen, feststellen, dass neue Hardware nicht auch gleich eine bessere Performance bedeutet und wenn du das Level der VM's nicht mit anhebst, dann können die VM's die neuen CPU's nicht wirklich optimal ansprechen, was zu noch mehr Performancefrust führen kann. 😔
Sollte das mit der schlechte Performance bei dir zutreffen, dann kann ich dir jetzt schon verraten, dass dies nicht wirklich an dem Wechsel von Intel zu AMD liegt, sondern eher an dem Wechsel von 2016 auf 2025.
Denn insbesondere ab Hyper-V 2019, haben diese Redmond Microsoftianer, leider auch vieles verschlimmbessert. 🙃
Gruss Alex
Laut der Tabelle hier kann ich mir damit Zeit lassen (vorausgesetzt, dass alle VMs auf Verison 8.0 sind),
solange ich nicht neue Features verwenden möchte - richtig?
solange ich nicht neue Features verwenden möchte - richtig?
du solltest schon die Version der VM's auch mit anheben.
Denn du wirst wahrscheinlich, wenn nicht schon geschehen, feststellen, dass neue Hardware nicht auch gleich eine bessere Performance bedeutet und wenn du das Level der VM's nicht mit anhebst, dann können die VM's die neuen CPU's nicht wirklich optimal ansprechen, was zu noch mehr Performancefrust führen kann. 😔
Sollte das mit der schlechte Performance bei dir zutreffen, dann kann ich dir jetzt schon verraten, dass dies nicht wirklich an dem Wechsel von Intel zu AMD liegt, sondern eher an dem Wechsel von 2016 auf 2025.
Denn insbesondere ab Hyper-V 2019, haben diese Redmond Microsoftianer, leider auch vieles verschlimmbessert. 🙃
Gruss Alex
Denn insbesondere ab Hyper-V 2019, haben diese Redmond Microsoftianer, leider auch vieles verschlimmbessert. 🙃
Oh je - nicht schon wieder - was ist denn alles konkret schlimmer geworden?
Gibt es dafür Workarounds, die ich gleich bei der Installation berücksichtigen kann?
Moin @Uwe.at.Home,
https://community.spiceworks.com/t/server-2019-network-performance/72496 ...
und hier werden nur einige von ganz vielen Punkten angesprochen. 😔
Ja, aber die sind extrem Harwareabhängig und eventuell muss du auch die Hardware nachrüsten.
Denn wass du auf keinen Fall machen solltest, ist z.B. bei einer >= 10G Broadcom NIC die mehrere Ports hat, einen davon für einen vSwitch zu verwenden und einen anderen ohne vSwitch, sprich, nativ z.B. für die iSCSI Anbindung.
Denn bei allen => 10G Broadcom NIC's die ich bisher in den Fingern hatte, kann man in deren BIOS entweder alle Ports auf nativen Betrieb konfigurieren oder für einen SDN Betrieb, sprich, mit SR-IOV, DCB, RDMA aber nicht wirklich im Mix, sprich, z.B. Port 1 mit SDN Umterstützung und Port 2 nativ mit nur RSS oder RDMA. 😔
Und das ist nur eine von ganz vielen Dingen, die man heutzutage bei einer Hypervisor-Umgebung alleine Hardwaretechnisch beachten muss und zwar ganz unabhängig von dem verwendeten Hypervisor. 😭
Bei Intel und auch Mellanox NIC's muss man selbiges übrigens nicht beachten, dafür aber andere Dinge.
Was sind den genau für NIC's in deinen neuen Systemen verbaut und wie möchtest du diese genau verwenden?
Gruss Alex
Oh je - nicht schon wieder - was ist denn alles konkret schlimmer geworden?
https://community.spiceworks.com/t/server-2019-network-performance/72496 ...
und hier werden nur einige von ganz vielen Punkten angesprochen. 😔
Gibt es dafür Workarounds, die ich gleich bei der Installation berücksichtigen kann?
Ja, aber die sind extrem Harwareabhängig und eventuell muss du auch die Hardware nachrüsten.
Denn wass du auf keinen Fall machen solltest, ist z.B. bei einer >= 10G Broadcom NIC die mehrere Ports hat, einen davon für einen vSwitch zu verwenden und einen anderen ohne vSwitch, sprich, nativ z.B. für die iSCSI Anbindung.
Denn bei allen => 10G Broadcom NIC's die ich bisher in den Fingern hatte, kann man in deren BIOS entweder alle Ports auf nativen Betrieb konfigurieren oder für einen SDN Betrieb, sprich, mit SR-IOV, DCB, RDMA aber nicht wirklich im Mix, sprich, z.B. Port 1 mit SDN Umterstützung und Port 2 nativ mit nur RSS oder RDMA. 😔
Und das ist nur eine von ganz vielen Dingen, die man heutzutage bei einer Hypervisor-Umgebung alleine Hardwaretechnisch beachten muss und zwar ganz unabhängig von dem verwendeten Hypervisor. 😭
Bei Intel und auch Mellanox NIC's muss man selbiges übrigens nicht beachten, dafür aber andere Dinge.
Was sind den genau für NIC's in deinen neuen Systemen verbaut und wie möchtest du diese genau verwenden?
Gruss Alex
Was sind den genau für NIC's in deinen neuen Systemen verbaut und wie möchtest du diese genau verwenden?
Zweimal "Intel X710-T4L" (4 Port 10 GbE).
Je ein Port pro NIC für iSCSI, Cluster-Kommunikation, Server-Netz (mit Backup u. Administration) und Client-Netz.
Zweimal "Intel X710-T4L" (4 Port 10 GbE).
OK - die kommen auch nicht unbedingt gut weg...
https://www.borncity.com/blog/2023/03/11/hyper-v-vms-und-host-hngen-sich ...
Das kann ja lustig werden...
Je ein Port pro NIC für iSCSI, Cluster-Kommunikation, Server-Netz (mit Backup u. Administration) und Client-Netz.
iSCSI mit MPIO (über Treiber des SAN) / Jumbo Frames
Cluster-Kommunikation: (bisher LBFO =>) SET / Jumbo Frames
Server-Netz: (bisher LBFO =>) SET / Jumbo Frames
Client-Netz: (bisher kein Teaming =>) SET
Moin @Uwe.at.Home,
muss gleich zum Kunden, daher jetzt nur die Kurzfassung.
OK - die kommen auch nicht unbedingt gut weg...
https://www.borncity.com/blog/2023/03/11/hyper-v-vms-und-host-hngen-sich ...
Das kann ja lustig werden...
Ohh, den Beitrag vom Günter kannte ich bisher noch gar nicht. 🙃
Die darin beschriebene Probleme kenne ich dafür umso besser und nein,
nicht alles was in diesem Beitrag beschrieben wurde, ist auch Intel anzulasten.
Vieles davon hat auch Microsoft, mit deren absolut bescheuerten Default verbockt.
Das abschalten von VMQ, hätte hier übrigens das Problem wahrscheinlich beseitigt.
Was ich auch bestätigen kann, ist dass die Mellanox NIC's am stresslosesten, jedoch nicht auch problemlos laufen.
iSCSI mit MPIO (über Treiber des SAN) / Jumbo Frames
Hier bitte aber auch wirklich MPIO und nicht nur Multisession benutzen.
SET kannst du bei => 10G eigentlich knicken, weil es mit VMQ oder SR-IOV nicht rund läuft und ohne VMQ oder SR-IOV, kannst du wiederum die Performance einer an einem vSwitch hängenden => 10G NIC knicken, respektive, nicht mal ansatzweise ausreizen. 😔
Ich habe selber schon seit Monaten ein Ticket bei Intel offen, wo es um einen BUG in Verbundung mit VMMQ geht und der sowohl die X7xx als auch die E8xx NIC's betrifft. Solage du jedoch keine > 64 vNIC's über einen vSwitch mit VMMQ betreiben möchtest, wird dich das Problem nicht betrreffen.
Das in einem der Kommentare in dem oberen Artikel erwähnte Problem mit SR-IOV und Veeam kann ich übrigens auch bestätigen. 😭
Aus diesem Grund mussten wir bei allen unseren Kunden, SR-IOV auf den vNIC's, auch leider wieder deaktivieren. 🤢🤮
Gruss Alex
muss gleich zum Kunden, daher jetzt nur die Kurzfassung.
Zweimal "Intel X710-T4L" (4 Port 10 GbE).
OK - die kommen auch nicht unbedingt gut weg...
https://www.borncity.com/blog/2023/03/11/hyper-v-vms-und-host-hngen-sich ...
Das kann ja lustig werden...
Ohh, den Beitrag vom Günter kannte ich bisher noch gar nicht. 🙃
Die darin beschriebene Probleme kenne ich dafür umso besser und nein,
nicht alles was in diesem Beitrag beschrieben wurde, ist auch Intel anzulasten.
Vieles davon hat auch Microsoft, mit deren absolut bescheuerten Default verbockt.
Das abschalten von VMQ, hätte hier übrigens das Problem wahrscheinlich beseitigt.
Was ich auch bestätigen kann, ist dass die Mellanox NIC's am stresslosesten, jedoch nicht auch problemlos laufen.
Je ein Port pro NIC für iSCSI, Cluster-Kommunikation, Server-Netz (mit Backup u. Administration) und Client-Netz.
iSCSI mit MPIO (über Treiber des SAN) / Jumbo Frames
Hier bitte aber auch wirklich MPIO und nicht nur Multisession benutzen.
Cluster-Kommunikation: (bisher LBFO =>) SET / Jumbo Frames
Server-Netz: (bisher LBFO =>) SET / Jumbo Frames
Client-Netz: (bisher kein Teaming =>) SET
Server-Netz: (bisher LBFO =>) SET / Jumbo Frames
Client-Netz: (bisher kein Teaming =>) SET
SET kannst du bei => 10G eigentlich knicken, weil es mit VMQ oder SR-IOV nicht rund läuft und ohne VMQ oder SR-IOV, kannst du wiederum die Performance einer an einem vSwitch hängenden => 10G NIC knicken, respektive, nicht mal ansatzweise ausreizen. 😔
Ich habe selber schon seit Monaten ein Ticket bei Intel offen, wo es um einen BUG in Verbundung mit VMMQ geht und der sowohl die X7xx als auch die E8xx NIC's betrifft. Solage du jedoch keine > 64 vNIC's über einen vSwitch mit VMMQ betreiben möchtest, wird dich das Problem nicht betrreffen.
Das in einem der Kommentare in dem oberen Artikel erwähnte Problem mit SR-IOV und Veeam kann ich übrigens auch bestätigen. 😭
Aus diesem Grund mussten wir bei allen unseren Kunden, SR-IOV auf den vNIC's, auch leider wieder deaktivieren. 🤢🤮
Gruss Alex
SET kannst du bei => 10G eigentlich knicken
wenn ich es richtig lese, dann ist ab Hyper-V 2025 ganz schluss mit LBFO:
https://learn.microsoft.com/en-us/answers/questions/2240966/windows-serv ...
Dann also eine Zeit lang bei Server 2022 bleiben und mittelfristig zu Proxmox wechseln 🙄
Moin @Uwe.at.Home,
das was FAMO1403 in seinem Beitrag hier als Fehlverhalten beschreibt, ist seit je her eigentlich das Standardverhalten vom Hyper-V. 🙃
Die LBFO-Unterstützung ist übrigens nur das SDN betreffend abgekündigt, jedoch nicht generell.
Sprich, wenn du das Team nicht in einem vSwitch verwenden möchtest, dann kannst du weiterhin auch LBFO mit RSS verwenden.
Der Grund dafür, warum LBFO eigentlich schon seit Server 2019 im SDN nicht mehr supportet ist, ist, dass LBFO nicht VMMQ, SR-IOV, vRSS oder RDMA fähig ist. Ohne die zuvor genannten Features, kann man eine physische => 10G Anbindung, jedoch nicht wirklich effektiv an die VM’s „durchreichen“, da der Overhead des in dem Fall komplett in Software laufenden vSwitches, schlichtweg zu gross ist. 😔
Das was ich zu den => 10G NIC’s und SDN geschrieben habe, sprich, dass man für deren Auslastung oder auch effiziente Benutzung, in einer virtualisierten Umgebung entweder VMMQ oder SR-IOV benötigt, gilt nicht nur für Hyper-V, sondern für jeglichen Hypervisor.
Aber, bei Hyper-V sind die entsprechenden Features meiner Erfahrung nach, zumindest technisch gesehen, bisher mit am besten umgesetzt. Die Konfiguration dieser ist beim Hyper-V per Default jedoch eher grauenhaft und zum Teil auch nicht lauffähig, weshalb viele damit auch massive Probleme haben.
Wenn man die NIC’s und die vSwitche und die vNIC’s jedoch korrekt konfiguriert und auch die richtige pNIC‘s wählt, diese auch in die richtigen PCI-E Slots steckt, dann funktioniert VMMQ oder SR-IOV, zumindest beim Hyper-V eigentlich ganz gut. 🙃
Was man bei VMMQ oder SR-IOV jedoch auch beachten sollte, ist die Tatsache, dass diese Technologien nur begrenzte Ressourcen bereitstellen, die auch je nach NIC sehr variieren können.
Sprich, über machen pNIC’s kannst du nur ein paar VM’s mit VMMQ oder SR-IOV beschleunigten vNIC’s (VF‘s) bereitstellen und bei den neueren sind theoretisch hunderte pro pNIC-Port möglich.
Gruss Alex
wenn ich es richtig lese, dann ist ab Hyper-V 2025 ganz schluss mit LBFO:
https://learn.microsoft.com/en-us/answers/questions/2240966/windows-serv ...
https://learn.microsoft.com/en-us/answers/questions/2240966/windows-serv ...
das was FAMO1403 in seinem Beitrag hier als Fehlverhalten beschreibt, ist seit je her eigentlich das Standardverhalten vom Hyper-V. 🙃
Die LBFO-Unterstützung ist übrigens nur das SDN betreffend abgekündigt, jedoch nicht generell.
Sprich, wenn du das Team nicht in einem vSwitch verwenden möchtest, dann kannst du weiterhin auch LBFO mit RSS verwenden.
Der Grund dafür, warum LBFO eigentlich schon seit Server 2019 im SDN nicht mehr supportet ist, ist, dass LBFO nicht VMMQ, SR-IOV, vRSS oder RDMA fähig ist. Ohne die zuvor genannten Features, kann man eine physische => 10G Anbindung, jedoch nicht wirklich effektiv an die VM’s „durchreichen“, da der Overhead des in dem Fall komplett in Software laufenden vSwitches, schlichtweg zu gross ist. 😔
Dann also eine Zeit lang bei Server 2022 bleiben und mittelfristig zu Proxmox wechseln 🙄
Das was ich zu den => 10G NIC’s und SDN geschrieben habe, sprich, dass man für deren Auslastung oder auch effiziente Benutzung, in einer virtualisierten Umgebung entweder VMMQ oder SR-IOV benötigt, gilt nicht nur für Hyper-V, sondern für jeglichen Hypervisor.
Aber, bei Hyper-V sind die entsprechenden Features meiner Erfahrung nach, zumindest technisch gesehen, bisher mit am besten umgesetzt. Die Konfiguration dieser ist beim Hyper-V per Default jedoch eher grauenhaft und zum Teil auch nicht lauffähig, weshalb viele damit auch massive Probleme haben.
Wenn man die NIC’s und die vSwitche und die vNIC’s jedoch korrekt konfiguriert und auch die richtige pNIC‘s wählt, diese auch in die richtigen PCI-E Slots steckt, dann funktioniert VMMQ oder SR-IOV, zumindest beim Hyper-V eigentlich ganz gut. 🙃
Was man bei VMMQ oder SR-IOV jedoch auch beachten sollte, ist die Tatsache, dass diese Technologien nur begrenzte Ressourcen bereitstellen, die auch je nach NIC sehr variieren können.
Sprich, über machen pNIC’s kannst du nur ein paar VM’s mit VMMQ oder SR-IOV beschleunigten vNIC’s (VF‘s) bereitstellen und bei den neueren sind theoretisch hunderte pro pNIC-Port möglich.
Gruss Alex
