Proxmox CPU problem, VM very slow

[rapture]

Hi,

I have a Proxmox with some VM and the CPU is going creazy but I can't understand why.
The VM inside has normal parameters

Someone could help?

root@plutone:~# lshw
plutone                  
    description: Rack Mount Chassis
    product: ThinkSystem SR250 -[7Y52CTO1WW]- (7Y52CTO1WW)
    vendor: Lenovo
    version: 04
    serial: S4BXE464
    width: 64 bits
    capabilities: smbios-3.2.0 dmi-3.2.0 smp vsyscall32
    configuration: boot=normal chassis=rackmount family=ThinkSystem sku=7Y52CTO1WW uuid=6E9C5667-5ED7-EA11-B494-7E8AE1CAD34B
  *-core
       description: Motherboard
       product: -[7Y52CTO1WW]-
       vendor: Lenovo
       physical id: 0
       version: none
       serial: C3KS03K00MR
       slot: none
     *-firmware
          description: BIOS
          vendor: Lenovo
          physical id: 0
          version: -[ISE128D-2.70]-
          date: 12/03/2021
          size: 64KiB
          capacity: 16MiB
          capabilities: pci pnp upgrade shadowing cdboot bootselect edd int14serial acpi usb biosbootspecification uefi
     *-cpu
          description: CPU
          product: Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz
          vendor: Intel Corp.
          physical id: 43
          bus info: cpu@0
          version: Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz
          serial: none
          slot: CPU 1
          size: 4676MHz
          capacity: 4900MHz
          width: 64 bits
          clock: 100MHz
          capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities cpufreq
          configuration: cores=6 enabledcores=6 threads=12

root@plutone:~# pveversion -v
proxmox-ve: 6.3-1 (running kernel: 5.4.106-1-pve)
pve-manager: 6.4-4 (running version: 6.4-4/337d6701)
pve-kernel-5.4: 6.4-1
pve-kernel-helper: 6.4-1
pve-kernel-5.4.106-1-pve: 5.4.106-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.2-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.8
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.4-1
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.4-2
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.2-1
libpve-storage-perl: 6.4-1
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.1.5-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.5-3
pve-cluster: 6.4-1
pve-container: 3.3-5
pve-docs: 6.4-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.3-1
pve-qemu-kvm: 5.2.0-6
pve-xtermjs: 4.7.0-3
qemu-server: 6.4-1
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.4-pve1

root@plutone:~# ps auxfw
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1330 16.9 11.8 9603988 7803896 ?     Sl   Apr05 8547:38 /usr/bin/kvm -id 103 -name NPV0029 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/103.qmp,
root      1369  7.4  6.3 7013784 4148940 ?     Sl   Apr05 3775:20 /usr/bin/kvm -id 104 -name NEPTS0029 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/104.qm
root      1407 21.3  6.4 9418124 4220616 ?     Sl   Apr05 10753:53 /usr/bin/kvm -id 105 -name CI-SERVER -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/105.q
root       912  0.0  0.0   9604  2120 ?        Ss   Apr05   0:08 /usr/sbin/xinetd -pidfile /run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
root      1703 11.9 12.7 10678124 8364172 ?    Sl   Apr05 6002:33 /usr/bin/kvm -id 100 -name BIZ-0029 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/100.qmp
statd    31722  0.0  0.0  57900 17964 ?        Ss   Apr05   0:00 /sbin/rpc.statd --no-notify
root     26824 12.9  6.3 6938996 4174008 ?     Sl   Apr26 2619:25 /usr/bin/kvm -id 102 -name VM2-0029 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp
root      8106  0.0  0.0  86172  2076 ?        Ssl  00:00   0:01 /usr/sbin/pvefw-logger
root     12431  0.0  0.0  21396  8936 ?        Ss   08:33   0:00 /lib/systemd/systemd --user
root     12432  0.0  0.0 172172  2836 ?        S    08:33   0:00  \_ (sd-pam)
www-data 14228  0.0  0.1 365972 96596 ?        S    08:37   0:00 pveproxy worker (shutdown)
root     18489 43.6 12.8 9785992 8428364 ?     Sl   08:47  23:45 /usr/bin/kvm -id 106 -name VM1-0029 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/106.qmp,

Thank youuuuuuuuu!!!!

 

[datschlatscher]

According to the Windows guest the CPU usage seems quite normal.

Is this a fresh Windows install? Did you see a sudden increase in CPU utilization with this VM or is it always using this amount of system resources?

Your htop output suggests that the KVM thread for this machine uses about 45% of one thread. Please note that the CPU% column of htop displays the usage per CPU thread, not the total CPU usage of your system. That's why htop sometimes exceeds 100% and displays values like 150%, i.e. when a process uses more than one thread. 150% would be equivalent to 1,5 threads used at capacity.
The mismatch of values from VM to host most likely stem from the overhead of Qemu to run, well, a whole Windows machine. While Qemu uses 45% of one thread to virtualize "a whole other computer", the Windows VM used just 5% of what was reserved by and given to it by Qemu.

 

[rapture]

The problem is the machine is unusable...

When I click on an icon I can go take a shower before the application opens.

Any ideas?

 

[shrdlicka]

What CPU type have you set for your VM?

 

[rapture]

 

[Spoonman2002]

Your PVE host has only 1 socket with max 6 cores.
In the vm 106 config, set sockets to: 1
and cores max 6 (or less)

 

[rapture]

Your PVE host has only 1 socket with max 6 cores.
In the vm 106 config, set sockets to: 1
and cores max 6 (or less)

Where have you seen the PVE host has only 1 socket?

I'll set like you said...

Thank you!

 

[Spoonman2002]

Where have you seen the PVE host has only 1 socket?

I'll set like you said...

Thank you!

specs Xeon 2276G

and: 1-socket Intel® Xeon® E-2200-processoren, max. 6 cores @ 95W (from Lenovo website)

 

[rapture]

Hi!

Same problem... th vm is very slow to use...

I'll try to upgrade virtio...

 

[Spoonman2002]

I would advise to use virtio-win-0.1.215.iso (not virtio-win-0.1.217.iso).
And maybe you can upgrade PVE to latest version 7.2, or is there a reason you are on 6.3 ?
- maybe you can (as a test) create a new vm with correct socket and cores and see if this responds better..

 

[datschlatscher]

Proxmox has a handy guide on best practices for configuring your Windows VM.

maybe you can (as a test) create a new vm with correct socket and cores and see if this responds better..

While more is generally better, you don't have to necessarily assign your VM as much cores as threads are present in your CPU. From what I could gather, 4 cores for this CPU should already be sufficient to run a standard installation of Windows. I've certainly seen it perform on much worse hardware.

I'm thinking that the CPU is maybe not the culprit here at all (Especially because it seems to not be utilized very strongly in the VM). Is the OS generally unresponsive if you click on a program or do something similar, or does the program just take very long to load, while the rest of the GUI stays perfectly usable?
If it is the former, and the whole Windows VM comes to a crawl where it goes unresponsive for seconds (or more) at a time it might actually have to do with RAM usage. Your task manager shows nearly 50% memory utilization, are you running any memory intensive programs that max out the Ram? Windows, like other OSes starts writing to the disk when it has no RAM left which usually results in a very slow user experience.