Two Proxmox settings fixed the lag in my VMs, and the performance difference is instant

Published Oct 3, 2026, 9:00 AM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. When you create a VM in Proxmox, it makes a lot of the choices for you, and most of them are sensible. For the environment it's normally used in, these defaults make a lot of sense, but in a home lab environment with only a handful of VMs and maybe a couple of nodes, it's not the most optimal. Changing just a couple settings can make a huge difference, and you can do it in just a few minutes. Setting the CPU type to host An easy way to make your VM feel better to actually use When you create a VM in the Proxmox web interface, the CPU type defaults to x86-64-v2-AES, which is a generic virtual processor model. It requires an Intel Westermere chip or newer, meaning it can boot on almost anything. That compatibility covers most modern chips, but it comes at a performance cost. The guest can only see instructions that those processors can handle, so my 6700K's AVX, AVX2, FMA, and BMI extensions are lost, and as far as the VM is concerned, it's running on a very old processor. Switching the type to host removes that filter. The VM gets the same CPU flags as the physical chip, and software inside it can use them, and while the performance increases aren't noticeable across all workloads, it does show up in heavier moments, like unpacking large archives of files, installing updates, and browsing the web with many tabs. Addtionally, without a real GPU, anything in the guest that needs OpenGL falls back on Mesa's software renderer, which generates its code at runtime for whatever CPU it finds. A more capable processor gives it more to work with, which in turn should mean a snappier experience when using the VM. This is obviously null and void if you're passing through a full-fat GPU. Host isn't always the slot-in choice for every VM; passing through every flag can cause issues with Windows guests specifically. Windows 11 specifically runs poorly with the CPU set to host because it sees those extensions and turns on all its virtualization-based security features, running a fully fledged hypervisor inside the VM, which hurts performance further. Switching the display fixed the lag SPICE is a better way to interact with your VMs The CPU change helped, but the lag that bothered me more was the trail that followed the cursor and the windows smearing when dragged. That has nothing to do with compute and everything to do with what display is selected in Proxmox. By default, a Proxmox VM gets a standard VGA adapter, a basic emulated card, and I had been viewing it through the noVNC console in a browser tab. That's fine for installing an operating system or checking on a server, but it's a poor way to actually use a desktop interface. Setting the display to SPICE swaps the emulated card for QXL, a paravirtualized graphics device, and turns on the SPICE protocol for the VM. The console button now sends me a file that opens in Remote Viewer, and that's what I use to interface with my VMs. The difference is obvious immediately. The cursor actually tracks properly and behaves more like a local machine. If you run the SPICE agent inside the guest itself, it also grants you the ability to use a shared clipboard. The defaults are set for perfectly good reasons SPICE and host CPU aren't the best for compatibility across all hosts and guests Proxmox wasn't made to run in a home lab, and the aforementioned CPU default is a great example of that. In a cluster where a VM might be live-migrated from one node to another, if it's attached to a machine with a specific processor, there's no guarantee everything will still work. There's a middle road here that isn't skipping straight to host, too: the x86-64-v3 model exposes AVX2 and the other newer extensions while staying portable across anything Broadwell or newer, and for most people that'll be enough. SPICE comes with its own set of downsides, mainly practical ones. If you're planning on accessing the VM from multiple different clients, every machine you connect will need a client application instead of being able to interface straight from the web UI. QXL is also the older of the paravirtualized options. VirtIO-GPU is the one usually recommended for current Linux desktops, and Proxmox will open a SPICE session for a VirtIO-GPU display as well, so the two aren't mutually exclusive. For a guest running Wayland, QXL is not where I would start. Proxmox can be made so much better with just these two tweaks Proxmox's defaults are tuned for compatibility, and that makes sense for what it's normally used for. It's honestly very usable out of the box, but working within a VM can be optimized better for home use with just these small changes to CPU and Display. On one node with one desktop VM, they were the easiest performance gains I've found in Proxmox.