wie viele virtuelle CPU's?

[pluto09]

Hallo Forengemeinde,

vermutlich gibts meine Frage schon x-mal, aber mit der Suche hier bin ich genausowenig fündig geworden wie mit dem Kollegen Google. Daher mal einfach frei raus...

Wie viele virtuelle CPU's kann und darf ich eigentlich vergeben? Gibt es da überhaupt ein Limit? Ist das von den physikalischen CPU's abhängig? Hab hier einen ESXi 7.0 Update 3 Server mit 32 logischen Prozessoren, 1 Socket und 16 Kerne pro Socket.

Danke für jeden Hinweis und schöne Grüße

Franz

[mcdaniels]

Servus,

soweit ich das mittlerweile beurteilen kann.

Bestenfalls wohl maximal 3vCPUs:1pCPU

As a guideline, the following vCPU:pCPU ratios can be considered a good starting point for a design:
o 1:1 to 3:1 is not typically an issue
o With 3:1 to 5:1, you might begin to see performance degradation
o 6:1 or greater is often going to cause a significant problem for VM performance

Quelle: https://download3.vmware.com/vcat/vmw-v ... 1.019.html

Wobei man pro VM wohl erstmal ganz unten anfängt bei der CPU-Zuordnung und sich dann langsam hochhangelt, sofern die Performence der VM nicht passt und es auf zu wenige vCPU-Ressourcen zurückzuführen ist.

[irix]

...
Wie viele virtuelle CPU's kann und darf ich eigentlich vergeben? Gibt es da überhaupt ein Limit? Ist das von den physikalischen CPU's abhängig? Hab hier einen ESXi 7.0 Update 3 Server mit 32 logischen Prozessoren, 1 Socket und 16 Kerne pro Socket.

Dafuer gibt es die tolle Seite https://configmax.esp.vmware.com/guest? ... gories=2-0 wo man links auswaehlen muss in welchem Bereich man gucken will. Es ist nicht ganz einfach zwischen Host und VM zu unterscheiden und somit beide angucken. Des Weiteren aendern sich die Werte mit den Versionen.

Die Antwort auf deine Frage ist max. 768 vCPU pro VM bzw. max. 896 logische CPUs im Host.

Gruss
Joerg

[irix]

...Ist das von den physikalischen CPU's abhängig?

Ja, eine VM kann niemals mehr vCPUs haben als der Host logische CPUs bereit stellt.

Gruss
Joerg

[mcdaniels]

...Ist das von den physikalischen CPU's abhängig?

Ja, eine VM kann niemals mehr vCPUs haben als der Host logische CPUs bereit stellt.

Gruss
Joerg

D.h. der TE kann auf einer VM maximal 32 Prozessoren zuordnen. Mit Betonung EINER?

Hätte er 2 VMs könnte er pro VM auch 32 Prozessoren zuordnen. Wäre dann zwar eine Überbuchung. Die ist aber im Rahmen?

[irix]

...Ist das von den physikalischen CPU's abhängig?

Ja, eine VM kann niemals mehr vCPUs haben als der Host logische CPUs bereit stellt.

Gruss
Joerg

D.h. der TE kann auf einer VM maximal 32 Prozessoren zuordnen. Mit Betonung EINER?

Ja. Das mit der Betonung verstehe ich aber nicht ganz da er jeder weiteren auch 32 vCPU geben kann.

Hätte er 2 VMs könnte er pro VM auch 32 Prozessoren zuordnen. Wäre dann zwar eine Überbuchung. Die ist aber im Rahmen?

Yupp, er kann je VM 32 vCPU zu ordnen bis er das max. von 768 erreicht.

Ob das im Rahmen ist muss dann jeder fuer sich selber herausfinden. Sobald eine Ueberbuchung stattfindet werde die VMs halt langsamer. Um wie viel haengt von weitere Faktoren ab und dann kommt noch die individuelle Akzeptanz der Benutzer dazu.

Ich habe Umgebungen da ist das Verhaeltnis max. 1:1 sprich es darf keine Ueberbuechung geben.

Gruss
Joerg

[JustMe]

Naja, ZUORDNEN kann man (je nach Lizenz) schon mehr. Aber die VM laesst sich dann auf diesem Rechner nicht mehr starten.

Und NEIN, die genannte Ueberbuchung ist (in diesem Fall) NICHT "im Rahmen". I.A. benoetigt der Hypervisor zur Ausfuehrung einer VM so viele *freie* Kerne wie ihr als vCPUs zugewiesen sind. D.h., dass in diesem Fall die beiden VMs mit jeweils 32 Kernen nur noch sozusagen ineinander verschachtelt (time slice) ausgefuehrt werden koennen. Und das auch nur, wenn nicht gerade der Kernel auch mal gerne was tun moechte, wie z.B. Netzwerkpakete bearbeiten.

Mit der Anzahl der VM-Kerne EINER VM in den Bereich der physisch vorhandenen zu gehen, ist eigentlich IMMER eine schlechte Idee (ausser natuerlich bei den gehosteten Virtualisierern wie Workstation usw., wo sich dann das Host-OS um die Zeitscheibenzuteilung kuemmert).

[irix]

Naja, ZUORDNEN kann man (je nach Lizenz) schon mehr. Aber die VM laesst sich dann auf diesem Rechner nicht mehr starten

Aeh...... evtl. lese ich es nur falsch aber.
1. Man kann ueber die GUI nicht mehr vCPU verkonfigurieren als der Host logische CPU hat und somit kann man nicht mehr zuordnen
2. Der kostenfreie Hypervisor hat eine Einschraenkung welche das max. limit pro VM auf 8 vCPU limitiert auch wenn der Host mehr hat

Gruss
Joerg

[JustMe]

1. Korrekt; das GUI versucht, dem Benutzer hier ein wenig Denkarbeit abzunehmen. Aber das hindert ja niemanden (wie auch in einem anderen aktuellen Thread vorgeschlagen), die Einschraenkungen des GUI per manueller .vmx-Bearbeitung zu umgehen.
2. Ich hatte doch geschrieben "(je nach Lizenz)".

[mcdaniels]

Ja, eine VM kann niemals mehr vCPUs haben als der Host logische CPUs bereit stellt.

Gruss
Joerg

D.h. der TE kann auf einer VM maximal 32 Prozessoren zuordnen. Mit Betonung EINER?

Ja. Das mit der Betonung verstehe ich aber nicht ganz da er jeder weiteren auch 32 vCPU geben kann.

Hätte er 2 VMs könnte er pro VM auch 32 Prozessoren zuordnen. Wäre dann zwar eine Überbuchung. Die ist aber im Rahmen?

Yupp, er kann je VM 32 vCPU zu ordnen bis er das max. von 768 erreicht.

Ob das im Rahmen ist muss dann jeder fuer sich selber herausfinden. Sobald eine Ueberbuchung stattfindet werde die VMs halt langsamer. Um wie viel haengt von weitere Faktoren ab und dann kommt noch die individuelle Akzeptanz der Benutzer dazu.

Ich habe Umgebungen da ist das Verhaeltnis max. 1:1 sprich es darf keine Ueberbuechung geben.

Gruss
Joerg

Ich meinte damit das, was du hier dann schreibst: Pro VM maximal 32 vProzessoren.

1:1 wäre dann sozusagen der "Optimalfall". (ist irgendwie auch logisch)

[JustMe]

Nein, das ist nicht der Optimalfall, und schon gleich gar nicht "logisch".
Wie bereits erwaehnt, kann die VM in einem solchen Falle nur dann weiter ausgefuehrt werden, wenn nicht gerade der Kernel und seine Gehilfen was Besseres zu tun haben.

Wer mag, kann's ja einfach mal ausprobieren, und sich in esxtop z.B. die %RDY-Werte anschauen. Zugegeben: Die VM(s) sollte(n) schon auch ein wenig mehr tun als nur den Windows-Desktop anzeigen oder im Linux den Eingabeprompt.

[irix]

Ich meinte damit das, was du hier dann schreibst: Pro VM maximal 32 vProzessoren.

1:1 wäre dann sozusagen der "Optimalfall". (ist irgendwie auch logisch)

Beim Verhaeltnis meinen wir die Summe aller vCPU zu den pCores und nicht bezogen auf einzelne VMs. Der OP fragt nach den technischen Limits und die Frage wurde beantwortet. Die Frage was im "Rahmen" liegt kann nie beantwortet werden da der "Rahmen" fuer jeden anders ist.

Ich habe Custer bei dem das Gesamtverhaeltnis 1:1 nicht uebersteigen darf und es somit keine Ueberbuchung gibt.. Der Normalfall wird dann wohl so 2:1 oder auch mal ein 3:1 sein. Ich hatte Kunden mit 6:1 und es war untragbar.... der Kunde machte schon Jahre damit rum und wollte mir nicht glauben das er ein CPU Problem hat. Die Anzeige was CPU angeht im vSphere Client ist "falsch".

1. Viele kleine VMs mit geringen vCPU koennen durchaus 5:1 oder noch mehr haben und es liegt innerhalb des "Rahmens". Typische VDI Umgebungen haben eine hohe Ueberbuchung
2. Wenige VMs mit vielen vCPU liegen evtl. bei einem 2:1 schon nicht mehr im "Rahmen" gerade wenn der Host wenig pCores hat. Terminalserver sind solche VMs oder SQL Monster.

Das ganze hat damit zu tun das die meisten ein falsches Verstaendis haben was der ESXi da tut. Sobald ein GuestOS eine vCPU beschaeftigen will so muss der Hypervisor fuer alle diese vCPUs dieser einen VM entsprechende freie vCore suchen. Wenn er die nicht findet bekommt die komplette VM keine Rechenleistung und muss warten. Wenn eine grosse VM dann mal dran ist muessen alle andern VMs evtl. warten.
Die Annahme das mehrere VMs auf ein und dem selben pCore laufen ist falsch. Es macht denn da auch keine Rolle ob die VM 100 oder 2500MHZ verbraet weil bekommen wuerde sie die 2500Mhz wenn sie die denn haben wollte. Letzeres ist zwar nicht ganz richtig aber der ESXi regelt dies ueber die Dauer wie lange er eine VM ausfuehrungszeit zugesteht.

Gruss
Joerg

[mcdaniels]

Ich meinte damit das, was du hier dann schreibst: Pro VM maximal 32 vProzessoren.

1:1 wäre dann sozusagen der "Optimalfall". (ist irgendwie auch logisch)

Beim Verhaeltnis meinen wir die Summe aller vCPU zu den pCores und nicht bezogen auf einzelne VMs. Der OP fragt nach den technischen Limits und die Frage wurde beantwortet. Die Frage was im "Rahmen" liegt kann nie beantwortet werden da der "Rahmen" fuer jeden anders ist.

Ich habe Custer bei dem das Gesamtverhaeltnis 1:1 nicht uebersteigen darf und es somit keine Ueberbuchung gibt.. Der Normalfall wird dann wohl so 2:1 oder auch mal ein 3:1 sein. Ich hatte Kunden mit 6:1 und es war untragbar.... der Kunde machte schon Jahre damit rum und wollte mir nicht glauben das er ein CPU Problem hat. Die Anzeige was CPU angeht im vSphere Client ist "falsch".

1. Viele kleine VMs mit geringen vCPU koennen durchaus 5:1 oder noch mehr haben und es liegt innerhalb des "Rahmens". Typische VDI Umgebungen haben eine hohe Ueberbuchung
2. Wenige VMs mit vielen vCPU liegen evtl. bei einem 2:1 schon nicht mehr im "Rahmen" gerade wenn der Host wenig pCores hat. Terminalserver sind solche VMs oder SQL Monster.

Das ganze hat damit zu tun das die meisten ein falsches Verstaendis haben was der ESXi da tut. Sobald ein GuestOS eine vCPU beschaeftigen will so muss der Hypervisor fuer alle diese vCPUs dieser einen VM entsprechende freie vCore suchen. Wenn er die nicht findet bekommt die komplette VM keine Rechenleistung und muss warten. Wenn eine grosse VM dann mal dran ist muessen alle andern VMs evtl. warten.
Die Annahme das mehrere VMs auf ein und dem selben pCore laufen ist falsch. Es macht denn da auch keine Rolle ob die VM 100 oder 2500MHZ verbraet weil bekommen wuerde sie die 2500Mhz wenn sie die denn haben wollte. Letzeres ist zwar nicht ganz richtig aber der ESXi regelt dies ueber die Dauer wie lange er eine VM ausfuehrungszeit zugesteht.

Gruss
Joerg

ich glaube wir reden bzgl. vCPU zu pCPU aneinander vorbei, meinen aber das Gleiche. (Ich hab dich jedenfalls verstanden).

Vielen Dank auch für die ausführlichen Infos. Das von dir Geschilderte ist mir jetzt (aufgrund einer aktuellen Problemlage) mehr als klar.