[KVM/libvirt] Ubuntu Threadripper Virtualisierung langsam und zu wenig cores

[alter_Bekannter]

Problem 1: Furchtbar langsam, selbst für einen Kern ist alles viel zu langsam.
Problem 2: Die Gäste nutzen nur 2 Cores.

Zu Problem1:

Spoiler

[src=text]
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
... (soweit ich das sehe wiederholt sich das korrekt für jeden Thread mit alterniereden Farben, das erspar ich uns hier mal.)
[/src]

[src=text]lsmod | grep kvm
kvm_amd 90112 0
kvm 647168 1 kvm_amd
irqbypass 16384 1 kvm
ccp 86016 1 kvm_amd
[/src]
sudo modprobe kvm_amd
Kein Fehler, keine Änderung.

Zu Problem 2:

Spoiler

libvirt monitor behandelt die VMs entsprechend ihrem zugeordneten core count.
Also
8 zugewiesen, 2 werden "100%" genutzt => 25% Auslastung
2 zugewiesen, 2 werden "100%" genutzt => 100% Auslastung

SVM habe ich im uefi aktiviert, keine Besserung.

Beide Probleme:

Spoiler

-betreffen alle getesteten System(Debian, FreePBX Image, Win7, WinXP)

Sonst kann ich keine Auffälligkeiten feststellen.

 

[alter_Bekannter]

Die Antwort war CPU Topographie. der Default ist mittlerweile dümmst möglich. Jeder Kern wird als Single Core Prozessor auf eigenem Sockel deklariert.

Das richtig einzustellen löst das Problem.
In der GUI:
Threads meint Threads pro Kern.
für aktuelle Prozessoren also immer 2.

 

[M-M-C]

Mal ne blöde Frage von jemanden, der schon einige Jahre aus den "großen" Virtualisierungsumgebungen raus ist:
Ist die CPU-Beschränkung nicht zu 99% der Fälle nur für eine (live) Migration gedacht? Mein ultra-schrottiges Proxmox-Homelab-Ding läuft mit Abstand am performantesten, wenn ich die CPU-Features einfach nur auf "host" stelle. Den Rest regele ich dann nur noch über die Kerne-Anzahl, und die knalle ich auf Grund der besseren Lastenverteilung einfach auf Maximum.
So vor ca. 10 Jahren habe ich mich mit Server-Migrationen rumschlagen müssen, ESXi Migrationen über verschiedene Intel-CPU-Generationen hinweg und so. Da nimmt man eben den kleinsten gemeinsamen Nenner, damit das nicht in der VM knallt.
Aber wenn man die VM zwischendrin einfach ausschalten und auf dem neuen Host wieder einschalten kann, sie also nicht absolut kritisch ist, dann ist das eh egal.

Ich würde gerne einfach gerne wissen wie und warum das andere lösen. Und ja, die default sind müll. Ist aber bei Proxmox an einigen Stellen genau so, ist wohl eine legacy-compatibility Sache. Da hat wohl jemand in Dev-Team Angst, das eine Anno-Dazumal-VM nach einem Software-Upgrade nicht mehr ordentlich startet. Stattdessen bremst man lieber alles andere aus.

 

[alter_Bekannter]

Das Preset Ist mit Sicherheit Legacy Kompatiblität heute machts wenig Sinn.

Und aus dem Aspekt kann ich es nachvollziehen, ist halt ein sehr einfacher Fall von RTFM. Und die Option ist ja wie gesagt sogar in der GUI. Will heißen wenn ich da verantwortlich wäre. Dann würde ich es auch nicht anfassen mit genau diesem Grund. IBM Prozessoren haben übrigens 8 Threads pro Core

You do not have permission to view link please Anmelden or Registrieren

, klar das ist für die meisten nicht relevant. Aber damit will ich sagen: Im absoluten minum heisst das: "Es ist plausibel das sich der Standard jederzeit ändern kann." Worst case: Niemand will der sein der den alten default ändert kurz bevor das passiert.

Ist halt für ein Neuling erstmal irritierend. Bis er sich die Optionen vernünftig anguckt... Und das denke ich muss man voraussetzen können.

Thema CPU Beschränkung: Das ist auch zur Eindämmung von Fehlern. Sonst gibts leicht böse Kettenreaktionen nur weil eine Maschine durchdreht. Das ist wie implizierte Konvertierungen in C. Das dir das in einem scheiße zu diagnostizierenden Szenario um die Ohren fliegt. Das ist nur eine Frage des "wann", nicht "ob". Daher immer am unteren Ende dessen definieren was man erwartet aber so das es gut läuft. Limit später erhöhen, der Bedarf fällt auf. Welches System dir alles lahmlegt, das ist eventuell nicht offensichtlich.

Ich sehe das so: Ich fordere das Schicksal niucht heraus indem ich potentielle edge cases sammele. Und CPU bottlenecks mögen gängig sein. Sind aber trotzdem ein weniger getestetes Szenario. Erst recht wenn der Scheduler des Betriebssystems nichts davon weiss.

Oder ganz kurz:
Ich limitiere lieber vorneherein die potentiellen Problemquellen.

Und die eingermaßen zu isolieren ist doch auch ein schöner Vorteil von VMs. Warum den nicht nutzen?