CPU-Topology

[s24!]

Hi,

ich betreibe mit SolusVM einige VMs unter KVM. Dort kann man die CPU-Topology einstellen (siehe Anhang). Leider ist mir auch nach Lesen einiger Lektüre nicht klar, was genau es damit auf sich hat. libvirt.org sagt:

topology
    The topology element specifies requested topology of virtual CPU provided to the guest. [...]

Das müsste im Falle meiner auf dem Screenshot gezeigten Einstellungen ja eigentlich bedeuten, dass die VM zwölf Kerne sieht. Tut sie aber nicht, und soll sie auch nicht - sie hat ja bewusst nur zwei Kerne zugewiesen bekommen (zu sehen unter "Processors").

=> Wie ist die CPU-Topology richtig einzustellen? Muss sie dem Host angepasst sein? Irgendwas anderes? Ich sehe den Wald vor lauter Bäumen nicht.


Viele Grüße
Tim

 

[Valentin]

Die CPU-Topology bezeichnet hier, wie der Gast die virtuellen CPU(s) sieht.

Beispiele:
Du kannst einer KVM-VM eine vCPU in dieser Toplogy zuweisen..
* 1 vSocket
* Darauf sitzt 1 vCPU
* Diese vCPU besitzt einen vCore
* Dieser vCore besitzt einen vThread

Oder auch..
* 1 vSocket
* Darauf sitzen 2 vCPUs
* Beide vCPUs besitzen je zwei vCores
* Beide vCores besitzen je 2 vThreads ("HT")

Im letzteren Beispiel sieht das OS demnach 2 CPUs mit insgesamt 4 Kernen mit insgesamt 8 Threads.

Auf KVM-Hosts wird pro vCPU ein Prozess gespawnt; je nach Settings bedeutet das durch cGroups mehr Ressourcen/Performance für die VM.

Hilft das?

 

[s24!]

Ja, danke dir. Habe dann auch irgendwann nach langem Suchen eine im Nebensatz erwähnte Empfehlung seitens Red Hat gelesen, dass man in den meisten Anwendungsfällen die beste Performance durch mehrere Sockets statt der anderen Parameter erhält.

Mein falsches Verständnis war halt in erster Linie, dass ich davon ausgegangen bin, dass eine Anpassung an den Host notwendig wäre.

 

[s24!]

Sorry, ich muss doch noch mal in die Runde fragen: Hat jemand praktische Erfahrungen damit gemacht, welche Konfigurationen sich für welche Anwendungsfälle eignen?

 

[Valentin]

Ja, danke dir. Habe dann auch irgendwann nach langem Suchen eine im Nebensatz erwähnte Empfehlung seitens Red Hat gelesen, dass man in den meisten Anwendungsfällen die beste Performance durch mehrere Sockets statt der anderen Parameter erhält.

Das ist genau das, was ich schreibe - ein Socket ist unter KVM = 1 vCPU.
Durch per default aktive cGroups und die Art, wie KVM arbeitet, bedeutet das übrigens auch bessere I/O-Performance.
Im Klartext:
* 1 KVM-VM mit 1 vCPU hat I/O-Performance X
* 1 KVM-VM mit 4 vCPUs hat I-O-Performance 4x
Voraussetzung ist, dass das Hostsystem genug Ressourcen bereit stellen kann.

Mein falsches Verständnis war halt in erster Linie, dass ich davon ausgegangen bin, dass eine Anpassung an den Host notwendig wäre.

Du verwechselst das womöglich auch mit dem CPU-Model. Unter LibVirt/KVM kannst du für eine vCPU einen CPU-Typ festelgen (z. B. Westmere, Nehalem, Qemu..) - wenn du da einfach "Host" auswählst, legt KVM-Qemu automatisch ein CPU-Model an, welches der Host-CPU am nächsten kommt. Das bedeutet die best möglichste Performance.

Achtung bei Virtualisierungs-Clustern: Wenn du VMs mit vCPU-Type = Host fährst, müssen alle anderen Virtualisierungs-Hosts in deinem Virtualisierungs-Cluster die gleiche CPU besitzen. Ansonsten wird's Probleme geben

Die vCPU mit der schlechtesten Performance aber höchsten Portabilität lautet "Qemu".