Hyper-V - Konfiguration Netzwerk - VMQ, RSS

[wznutzer 35]

Guten Tag,

 

beim Rumspielen mit einem neuen Server ist mir folgendes aufgefallen:

 

W2K22 - alle Updates

Lenovo SR665 2 CPUs - alles aktuell (Firmware, Treiber)

NIC: Broadcom SFP28 57454 4 Ports

kein Teaming, für jeden Port ein separater vSwitch

Es wurden bisher keine Parameter verändert.

 

Es funktioniert auch alles, aber es sind halt diese Fehler im Log.

 

Es treten diese Events auf:

Event 280

VMS Utilization Plan Vport QueuePairs wurde von angeforderter Anzahl (16) auf aktuell (4) angepasst. Grund:Auf die nächstgelegene Zweierpotenz abgerundet. NIC-Name: /DEVICE/{9A08C856-FC4D-4E6F-A66A-59F34813E3B0} (Anzeigename: Broadcom 57454 10/25GbE SFP28 4-port OCP Ethernet Adapter #2).

 

Event 281

VMS Utilization Plan Vport QueuePairs: Fehler. Grund: QP ist nicht mehr verfügbar. Status: Nicht ausreichend Systemressourcen, um die API abzuschließen.. NIC-Name: /DEVICE/{9A08C856-FC4D-4E6F-A66A-59F34813E3B0} (Anzeigename: Broadcom 57454 10/25GbE SFP28 4-port OCP Ethernet Adapter #2).

 

Event 113

Failed to allocate VMQ for NIC 7F18CB75-1D9D-416F-AEBA-CE494BD9E487--1C5FC570-55E6-47F0-B2D8-0BF21D378BE5 (Friendly Name: Netzwerkkarte) on switch 857A8E05-3258-4F41-B120-4C27D3BD7F88 (Friendly Name: SFP28OCP_01). Reason - Der Auslastungsplan kann nicht ausgewertet werden. Status = Nicht ausreichend Systemressourcen, um die API abzuschließen.

 

1)

Oft wird empfohlen VMQ einfach abzuschalten, aber das kommt mir falsch vor. VMQ sorgt ja dafür, dass die Last schön auf alle CPU-Kerne verteilt wird.

 

2)

Warum diese Fehler auftreten ist mir nicht ganz klar. Es ist ja die Standardkonfiguration von W2K22 und Hyper-V und die sollte doch ohne Fehler funktionieren.

Ist es nicht nur "best practices" sonder ist es notwendig, auch ohne NIC-Teams, VMQ und RSS extra zu konfigurieren? Mit konfigurieren meine ich die ganzen Anleitungen mit denen jeder einzelne NIC-Port einem CPU-Kern zugewiesen wird, damit nicht alles auf Kern 0 läuft?

 

Vielen Dank für eure Meinungen.

 

[Nobbyaushb 1.473]

Moin,

 

warum hast du 4 Vswitche?

Über welche Karte läuft das Management vom Hyper-V?

 

Broadcom macht gerne mal Probleme, hast du noch irgendwo eine Intel-NIC rumliegen (zum Test...)

RDMA machen die ja eh nicht...

Nachtrag - wurde der Server mit installiertem OS geliefert?

Was sagt der Hersteller dazu?

[wznutzer 35]

vor 40 Minuten schrieb Nobbyaushb:

warum hast du 4 Vswitche?

Die NIC hat 4 Ports, jeder Port ein vSwitch. Jeder 10GB Port geht auf ein 10 GB Port auf den Switch. Ich verteile die VMs so manuell auf die Ports. Ist das falsch und die Ursache für Ärger?

vor 40 Minuten schrieb Nobbyaushb:

Über welche Karte läuft das Management vom Hyper-V?

Über eine zusätzliche Intel-NIC (X710). Der Server hat 6x 10GB SFP28 Ports.

 

vor 44 Minuten schrieb Nobbyaushb:

Nachtrag - wurde der Server mit installiertem OS geliefert?

Nein, über den LXPM von Lenovo installiert. Das ist notwendig, weil sonst Lenovo UpdateXpress nicht alle Treiberaktualisierungen findet.

vor 45 Minuten schrieb Nobbyaushb:

Was sagt der Hersteller dazu?

Lenovo oder Microsoft? Habe ich noch nicht gefragt, bin bisher von einer Unwissenheit meinerseits ausgegangen.

[NorbertFe 2.050]

vor 20 Minuten schrieb wznutzer:

Ich verteile die VMs so manuell auf die Ports. Ist das falsch und die Ursache für Ärger?

Was heißt falsch, was machst du eigentlich bei 57VMs? 57 virtuelle Switches auf 57 Netzwerkkarten des Hosts? Mensch, mensch, mensch. ;) Ein virtueller Switch der aus x Netzwerkkarten besteht reicht üblicherweise aus. Den Rest kann man meist mit VLAN Trennung erreichen.

 

Bye

Norbert

[wznutzer 35]

vor 29 Minuten schrieb NorbertFe:

Was heißt falsch, was machst du eigentlich bei 57VMs? 57 virtuelle Switches auf 57 Netzwerkkarten des Hosts?

Ich habe nicht so eine Umgebung. Am Ende werden da 11 VMs verteilt auf 3 vSwitche drauf laufen und die meiste Zeit würde für den Traffic wahrscheinlich sogar ein vSwitch mit 10GB-Anbindung ausreichen. Alles was ich nicht unbedingt brauche, nutze ich nicht. Was ich nicht nutze kann keinen Fehler verursachen. Das ist die Denke dahinter. Ich habe hier alles etwas kleiner als das was die meisten hier wohl so haben.

 

Das was ich mit Konfiguration von VMQ meine, ist hier gut beschrieben:

https://blog.apps.id.au/hyper-v-and-vmqs-mythbusting/

 

Unabhängig davon, ob das meine Fehler im Log beseitigt, liest sich das so, als ob die Standardkonfiguration eher "bad practice" ist und das immer individuell konfiguriert werden muss.

 

Da würde mich eben interessieren ob Ihr das immer so macht oder nur im Ausnahmefall?

 

Wenn ein NIC-Team Probleme löst, anstatt zu verursachen, mache ich das schon.

 

Edit: Ergänzung, sollte ein separater Post werden, die Forumssoftware hängt das aber an den letzten Post.

bearbeitet 1. Februar 2023 von wznutzer

[NorbertFe 2.050]

vor 28 Minuten schrieb wznutzer:

Alles was ich nicht unbedingt brauche, nutze ich nicht.

Und warum dann 4 virtuelle SWITCHE? Das ist doch total gaga. Stellst du an jeden PC auch einen Switch der sich dann mit dem nächsten Switch unterhält? ;)

vor 30 Minuten schrieb wznutzer:

Am Ende werden da 11 VMs verteilt auf 3 vSwitche drauf laufen

Warum dann nicht 11 NICs und 11 virtuelle Switche? ;) (SCNR)

[wznutzer 35]

vor 8 Minuten schrieb NorbertFe:

Und warum dann 4 virtuelle SWITCHE?

Weil ich das 1. nicht besser wusste und 2. auf das Teaming verzichten kann. Teaming ist eine Funktion die evtl. Ärger machen kann und darauf verzichte ich, wenn ich das nicht benötige. Um in Deiner Analogie zu bleiben, wäre der separate Switch für jeden PC unnötig und somit würde ich das nicht nutzen, wenn ich noch einen Port zum Patchfeld frei hätte. Habe ich keinen Port frei, nutze ich den Switch und nehme die zusätzliche Fehlerquelle in Kauf, weil es einen Nutzen bringt.

 

Ich nehme mit, dass Teaming (auch wenn man das nicht braucht) als "best practice" angesehen wird. Das habe ich gelernt. Aber was mir noch nicht klar ist, wird VMQ, RSS auch immer  speziell konfiguriert und nie "out of the box" genutzt?

[NilsK 2.940]

Moin,

 

ich würde auch zunächst auf Treiberprobleme tippen. 

Alle weiteren Fragen - also welche Workarounds in Frage kommen - könnte man nur betrachten, wenn man weiß, was ihr da genau vorhabt. Das führt möglicherweise in einem Forum zu weit.

 

Zu der Frage mit der Anzahl der Switche: Worauf Norbert hinauswill, ist die unnötige Komplexität, die du mit vier vSwitches verursacht. Separate vSwitches braucht man nur dann, wenn sie jeweils zu Netzen führen, die voneinander getrennt sind. Das scheint bei dir nicht der Fall zu sein. Dann reicht ein einziger vSwitch aus. Wenn der bei dir nur einen Port braucht, dann nutze auch nur einen. So einfach kann es sein.

 

Gruß, Nils

 

[wznutzer 35]

vor 13 Minuten schrieb NilsK:

Dann reicht ein einziger vSwitch aus. Wenn der bei dir nur einen Port braucht, dann nutze auch nur einen. So einfach kann es sein.

Ja, genau so ist es ja auch. Der eine vSwitch mit dem einen Port wird genutzt. Die anderen sind ungenutzt vorhanden. Mit zwei mache ich jetzt halt testweise mal ein Team und probiere etwas rum, so lerne ich ja was.

 

Aber alle Anleitungen, auch die verlinkte, zu VMQ, RSS gehen ja von einem Teaming aus. Also das was jeder macht. Und unabhängig von meinen Fehler im Log würde ich gerne lernen, ob die Ports der NIC-Teams jeder speziell so konfiguriert wie das oft zu lesen ist. So wie sich das liest ist es ja essentiell wichtig dafür zu sorgen, dass CPU-Kern 0 niemals genutzt wird.

 

Da wir nun beim NIC-Teaming sind. Es gibt Software der NIC-Hersteller um das zu konfigurieren oder ist es inzwischen problemlos das in W2K22 (z. B. im Servermanager) zu machen?

 

Vor langer Zeit W2K12R2 habe ich beim experimentieren mit https://www.cfos.de/en/ping/ping.htm gesehen, dass einzelne vSwitche (einer pro Port ) bessere Laufzeiten hatte als ein Team. Warum auch immer, ich habe keine Erklärung dafür, das auch nur am Rand.

 

Grüße

[NorbertFe 2.050]

Bei 2019 und 2022 solltest du lieber SET Switch Embedded Teaming konfigurieren. Ab 2022 geht das nur bisherig LBFO nur noch per Powershell für Hyper-V zu konfigurieren. Viel Spaß beim Lesen. :)

[NilsK 2.940]

Moin,

 

du widersprichst dir. Oben hast du behauptet, dass du alle vier Switches nutzt und die VMs darauf verteilst. Nun ist das nicht mehr so? Nicht ganz einfach, dann zu Aussagen zu kommen.

Ich würde jedenfalls weder ungenutzte vSwitches anlegen noch irgendwelche Tests auf einem Produktionssystem machen. Aber ist ja auch nicht mein Netzwerk, das muss jeder selbst wissen.

 

"Laufzeiten" sind wie alle Benchmarks kaum jemals vergleichbar. Außerdem hast du ja angegeben, dass Netzwerkdurchsatz gar nicht der Punkt ist, den du lösen willst. Also ist das doch wohl irrelevant. Es führt auch alles irgendwie vom Thema weg, ursprünglich ging es doch hier um Fehlermeldungen. Ich würde jetzt halt schauen, ob neuere Treiber das Problem lösen. Und wenn nicht, würde ich anhand von Web-Fundstellen prüfen, ob manuelle Konfigurationen was verbessern. So riesig wird der Aufwand ja nicht sein. Zumal es offenbar um einen einzelnen, eher "kleinen" Host geht.

 

Dass eine Default-Konfiguration nicht zu Fehlern im Betrieb führen sollte, liegt auf der Hand. Irgendwas ist da also nicht so, wie es sein sollte. Viel mehr kann man dazu jetzt nicht beitragen.

 

Gruß, Nils

 

[wznutzer 35]

vor 4 Stunden schrieb NilsK:

du widersprichst dir. Oben hast du behauptet, dass du alle vier Switches nutzt und die VMs darauf verteilst. Nun ist das nicht mehr so? Nicht ganz einfach, dann zu Aussagen zu kommen.

Beides ist richtig. Es sind 4 vSwitche angelegt. 11 VMs sollen auf 3 vSwitche, so wie geschrieben, aufgeteilt werden. Einer davon ist ein Beinchen in einem anderen Netz. *Derzeit* sind 5 VMs drauf die 1 vSwitch nutzen. Somit trat der Fehler mit der einfachen Konfig auf.

 

vor 5 Stunden schrieb NorbertFe:

Bei 2019 und 2022 solltest du lieber SET Switch Embedded Teaming konfigurieren. Ab 2022 geht das nur bisherig LBFO nur noch per Powershell für Hyper-V zu konfigurieren. Viel Spaß beim Lesen. :)

Danke.

 

Ich fasse zusammen, dass man zwar nicht pro NIC ein vSwitch anlegt, stattdessen lieber ein Team macht, das aber auch nicht zu Fehlern führt. Bei Performance-Problemen sollte man sich aber durchaus VMQ, RSS, LSO usw. anschauen.

 

Aber egal, die Fehler sind weg. Nach einem Restart des LXCC (nicht das OS, das Servermanagement) werden diese Fehler nicht mehr geloggt. Treiber waren natürlich aktuell.

 

[wznutzer 35]

Am 1.2.2023 um 15:25 schrieb NorbertFe:

Bei 2019 und 2022 solltest du lieber SET Switch Embedded Teaming konfigurieren.

Für alle die hier auch noch am lernen sind, Veeam hat das in gewohnter Qualität beschrieben.

https://www.veeam.com/blog/hyperv-set-management-using-powershell.html

 

Lt. meinen Tests ist die Kommunikation der VMs untereinander schneller, wenn diese an so einem vSwitch hängen, als bei einzelnen vSwitchen, somit alles prima.

 

Nach „außen“, also nicht die VMs am vSwitch untereinander“, bleibt einen Ticken langsamer als ohne Teaming 🤷‍♂️.

bearbeitet 4. Februar 2023 von wznutzer