2
ESX 6.7 CU3 - Fehler beim Einschalten wenn SRIO-V als Netzwerkadapter aktiviert ist
Moin, vielleicht kann mir jemand weiterhelfen...
ich hab einen ESX 6.7 CU3 Server, und der beherbergt so um die 30 VMs. 2 CPUs mit je 16 Threads, 256 GB RAM.
Hier mal zur Vereinfachung hab ich die Threads "core" genannt. ESX unterscheidet das auch nicht.
Bei zwei VMs hab ich SQL Server drin, bei denen hatte ich SRIO-V am Netzwerkadapter aktiviert. Und eine läuft.
Obwohl das eigentlich für physishce Adapter gedacht ist, hat es auch positive Auswirkungen beim Datenverkehr zweier VMs untereinander gehabt.
Dann eine dritte VM erstellt, 8 Cores, SRIOV als Netzwerkadapter, einschalten, installieren, fertig.
Bei der vierten VM weigert sich VMware, diese einzuschalten. Ohne jeglichen Hinweis, und wenn ich den Netzwerkadapter entferne und neu hinzufüge, dann fehlt die SRIO-V Option, es ist nur noch E1000 und VMXNET 3 übrig.
SRIO-V erfordert 100% Arbeitsspeicherreservierung und 100% CPU-Reservierung... sprich man kann kein Overprovisioning machen aber die ein VM mit SRIO-V belegt nur 8 Cores und 16 GB (von 256), da sollten also noch 24 Cores frei sein und reichlich Ram...
Oder hab ich da irgendwelche Limits übersehen? Wieviele SRIO-V Adapter kann so ein ESX? Ist das irgendwo limitiert?
Vom Prinzip her kann ich meinen Test (SQL 2012 vs 2017) auch mit VMXNET 3 machen, aber dann müßte ich eine VM umstellen. Bei Workloads mit massenhaften Mikrotransaktionen war SRIO-V nämlich um 30% besser als VMXNET3, aber die Workloads die ich nun untersuchen muß haben SQL-Befehle, die mal so eben 2 Seiten A4 vollmachen, deren Problem dürfte eher die untershciedlichen Optimierungsmöglichkeiten der beiden SQL Server Versionen sein wo ich den 2012 im Verdacht hab, daß er extrem viel länger braucht.
Deshalb wäre SRIO-V nicht unbedingt kriegsentscheidend, aber die Frage bleibt schon...
ich hab einen ESX 6.7 CU3 Server, und der beherbergt so um die 30 VMs. 2 CPUs mit je 16 Threads, 256 GB RAM.
Hier mal zur Vereinfachung hab ich die Threads "core" genannt. ESX unterscheidet das auch nicht.
Bei zwei VMs hab ich SQL Server drin, bei denen hatte ich SRIO-V am Netzwerkadapter aktiviert. Und eine läuft.
Obwohl das eigentlich für physishce Adapter gedacht ist, hat es auch positive Auswirkungen beim Datenverkehr zweier VMs untereinander gehabt.
Dann eine dritte VM erstellt, 8 Cores, SRIOV als Netzwerkadapter, einschalten, installieren, fertig.
Bei der vierten VM weigert sich VMware, diese einzuschalten. Ohne jeglichen Hinweis, und wenn ich den Netzwerkadapter entferne und neu hinzufüge, dann fehlt die SRIO-V Option, es ist nur noch E1000 und VMXNET 3 übrig.
SRIO-V erfordert 100% Arbeitsspeicherreservierung und 100% CPU-Reservierung... sprich man kann kein Overprovisioning machen aber die ein VM mit SRIO-V belegt nur 8 Cores und 16 GB (von 256), da sollten also noch 24 Cores frei sein und reichlich Ram...
Oder hab ich da irgendwelche Limits übersehen? Wieviele SRIO-V Adapter kann so ein ESX? Ist das irgendwo limitiert?
Vom Prinzip her kann ich meinen Test (SQL 2012 vs 2017) auch mit VMXNET 3 machen, aber dann müßte ich eine VM umstellen. Bei Workloads mit massenhaften Mikrotransaktionen war SRIO-V nämlich um 30% besser als VMXNET3, aber die Workloads die ich nun untersuchen muß haben SQL-Befehle, die mal so eben 2 Seiten A4 vollmachen, deren Problem dürfte eher die untershciedlichen Optimierungsmöglichkeiten der beiden SQL Server Versionen sein wo ich den 2012 im Verdacht hab, daß er extrem viel länger braucht.
Deshalb wäre SRIO-V nicht unbedingt kriegsentscheidend, aber die Frage bleibt schon...
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: 613467
Url: https://administrator.de/forum/esx-6-7-cu3-fehler-beim-einschalten-wenn-srio-v-als-netzwerkadapter-aktiviert-ist-613467.html
Ausgedruckt am: 06.04.2025 um 22:04 Uhr
2 Kommentare
Neuester Kommentar
SRIO-V erfordert 100% Arbeitsspeicherreservierung und 100% CPU-Reservierung... sprich man kann kein Overprovisioning machen aber die ein VM mit SRIO-V belegt nur 8 Cores und 16 GB (von 256), da sollten also noch 24 Cores frei sein und reichlich Ram...
Wie kommst du darauf? Du hast doch auch die anderen VM da drauf und dort Cores bereits zugewiesen.
Haben alle VM die gleiche VM Version?
Sind die SRIO-V alles die gleichen Netzwerkadapter?
Pro Host kannst du bei 6.7 maximal 8 physische 10 G NICS anschließen ...nachzulesen hier VMware Configuration Maximums
unter bestimmten Konstellationen muß der Gast 100% der für ihn zugewiesenen vCPU auch reserviert kriegen, und zwar genau dann wenn alle Cores in einem Socket sind. In meinem Fall also 16 Cores pro Socket und 16 vCPU. Damit hab ich gewissermaßen eine CPU bzw.NUMA Node Affinität erzwungen.
Bei "kleineren" VMs ist das nicht erforderlich und auch dann nicht, wenn man (wie VMware empfiehlt) ein Core pro Socket einstellt. Stand in irgendeinem ESX Whitepaper so drin... und war früher auch mal genau andersherum definiert. Aber effektiv sind VMs mit viel Multithreading ca. 20% performanter wenn man VMware die konkrete Zuteilung von Threads zu vCores überläßt.
Sind übrigens alle VMs mit demselben virutellen Switch verbunden, und ich hab 6x 1 GBit und alle VMs haben denselben Stand vom OS und virutelle Hardwareversion, alle haben die VMware tools der 6.7 CU3 installiert.
Bei "kleineren" VMs ist das nicht erforderlich und auch dann nicht, wenn man (wie VMware empfiehlt) ein Core pro Socket einstellt. Stand in irgendeinem ESX Whitepaper so drin... und war früher auch mal genau andersherum definiert. Aber effektiv sind VMs mit viel Multithreading ca. 20% performanter wenn man VMware die konkrete Zuteilung von Threads zu vCores überläßt.
Sind übrigens alle VMs mit demselben virutellen Switch verbunden, und ich hab 6x 1 GBit und alle VMs haben denselben Stand vom OS und virutelle Hardwareversion, alle haben die VMware tools der 6.7 CU3 installiert.
