Proxmox VE as Forbidden Desktop

Operating Systems & Open Source Virtualization
, ,
1

Hi everyone,

I’m running Proxmox as VE. I run few VM’s, Ubuntu VM for work, Ubuntu headless VM for docker containers and Windows VM for gaming.
Recently I tried to use my Focusrite on my Windows VM and started experiencing sound pops and weird audio latency issues and all right audio cut offs.
I got whole USB controller passthrough to the VM. In the mean time I saw that doing “normal” stuff on Ubuntu VM greatly affected the Windows VM when gaming. Trying to solve all of this in got my self into CPU pinning.

I used this repo as an example.
GitHub - mattiarossi/pve-helpers: A set of Proxmox VE scripts that aids with suspend/resume and cpu pinning

Also I have also hugepages working.

Pinning 6 threads on my CPU to Windows VM, I noticed that when playing Battlefield 4 in my case, the VM CPU usage is over 80% almost all of the time when gaming, and the GPU usage rarely goes over 75%. And there are also FPS drops when there is alot of stuff going in the game.

My question is am I pushing the CPU to its max on single threaded?
But this kinda didn’t made sense because if I give 2 more threads to the VM,
GPU usage goes to 100% and CPU usage drops to 50-60%.
I guess ill need some guidance, to optimize my setup.

Thanks!

Hardware Specs:

CPU: Ryzen 5 3600
MB: Asus Rog Strix X570-F
RAM: 2 x 32gb @ 3200Mhz Kingston Renegade
GPU0: AMD Rx 580 4GB Gigabyte
GPU1: AMD ATI Radeon HD 3650 (its really old I know, but its still works :joy:)
SSDs: Samsung 860 evo (Proxmox installed here), 2 x Intel D3-S4510 960gb(for VMs)
HDDs: 4 x 3TB in ZFS (don’t know the models)

1 Like
ZVOL vs. file as VM backing - huge performance difference on nvme-based zpool
2

Qemu has a bug which only affects some systems. Hdd I/O while a virtual SCSI controller is active can stall the qemu process and greatly affect the latency and performance. Even if it’s not an intense workload and even if it is unrelated to the storage of your VMs or happening only on the host (migrating or backing up VMs). Simply set the two advanced storage option on every VM hdd to threaded and thread i/o (I have to look up the correct description) fixed it for me. If you already use virtual SCSI, the guest should be unaffected. Please be carefull if you used other option with your guest (emulated SATA / IDE for example) and change the virtual controller.

2 Likes
3

I’m using VirtIO SCSI single controller:

  • Cache: Write back,
  • IO thread checked,
  • Discard checked,
  • Backup checked,
  • Async IO default(io_uring)
4

Also all VM’s are on SSD

5

Getting inspired by your comment I moved the Windows VM to my NVME drive, same settings, and got quite an improvement. Next ill try to get Windows VM on whole drive passthough.

6

The problem I spoke of has nothing to do with the storage medium.

  • Async IO default(io_uring) -

change this to „threaded“ or „threads“ as well - if you have performance issues because of this, this should fix it.

As far as I know with the threaded settings you put storage access into separate threads and circumvent whatever issue qemu has.

2 Likes
7

Interesting. Do you have more info on this, e.g. a link to a bug report?

I’m seeing problems on one of my hosts that may or may not be related to this, so I’m interested in knowing more about it.

1 Like
8

Had to do a bit of digging:
https://bugzilla.proxmox.com/show_bug.cgi?id=1453
https://bugzilla.kernel.org/show_bug.cgi?id=199727

Original thread:

3 Likes
9

Moving the disk on Fast NVME or setting VirtIO SCSI Single / iothread=1 / aio=threads for my Windows VM greatly improve performance and fps drops, and CPU and GPU usage.

Here are some nice reads about this problem:
https://bugzilla.proxmox.com/show_bug.cgi?id=1453
https://bugzilla.kernel.org/show_bug.cgi?id=199727#c8

2 Likes
10

Thanks @Dratatoo for guiding me in the right direction. You saved my wallet from CPU upgrade :joy:

1 Like