Setting up Proxmox Linux containers (LXC) and virtual machines (VMs) is what makes this hypervisor an invaluable tool for home labs. It’s powerful, light, and fast, but there are a few tweaks one can make to make it even better. One is to enable community updates, unless you have a subscription, of course. But another may not be too obvious, especially if you’re just starting out with your first Proxmox deployment. I’m talking CPU passthrough to VMs and how selecting the right one (“host”) can improve performance.
What is a host CPU?
Table of Contents
Back to bare metal
When running QEMU/ KVM through something like Proxmox, the CPU is usually passed through directly for Linux containerssince these run on the node itself. Virtual machines are a different matter since they can be configured within the virtual environment with a whole host of variables, one being the CPU. By default, Proxmox will set the CPU type to x86-64-v2-AES, a generic type which is the same on every platform, regardless of Proxmox version and hardware configuration — I’m sure you can already see the benefits of using this.
Using such a generic type essentially allows the VM to copy the host CPU and use specific sets and extensions, making it possible to hop between nodes within a cluster without encountering any compatibility issues. But doing so usually comes at a cost of performance, since you’re not directly passing through the CPU to the VM. You’re not fully utilizing all the benefits and new technologies the CPU may support, which essentially leaves performance on the table for no reason, especially if you don’t plan to hop between different systems.
Think of it like running your favorite game through an emulator instead of natively.
By switching the CPU type to “host”, QEMU/KVM is instructed to expose the instruction set of your physical processor, not some generic virtual component. That allows the VM to use every extension. I’m talking AVX, AVX512, and AES-NI, many of which are invaluable for loads such as running large language models (LLMs), dealing with big data, and launching more demanding environments. It removes an emulation layer since Proxmox has to run everything through that generic x86-64-v2-AES processor, which doesn’t physically exist.
Think of it like running your favorite game through an emulator instead of natively. And because you’re likely running Proxmox continuously without any downtime, being able to more efficiently run loads on modern CPU architectures will help reduce required cycles and power. You can now go wild with video encoding, compression, encryption, and other resource-intensive tasks. Finally, using the host CPU type within Proxmox will run software within VMs as if they were running on bare metal on the host itself, completely removing any potential inconsistencies.
How to switch the CPU to host
It’s easier than you think
Making the change is usually best when creating the VM since you can be sure everything will work thereafter as the change isn’t occurring while things are already configured on x86-64-v2-AES. So long as you take a backup prior to changing the CPU type, we shouldn’t have any issues. When creating the new VMin the CPU tab, simply click the type drop-down menu and type or select “host”. You’re done! Continue creating the VM as usual and it’ll then start up with your physical processor ready to roll.
And if you already have a VM up and running but want to see if you can enjoy better performance and efficiency with this single setting change, shut down the VM. When offline, go to VM > Hardware and select Processors. Click Edit and change the type to “host”. Fire up the VM again and see if all is well with whatever you may have running on the OS. If it’s fairly processor-intensive, you should notice a considerable uptick in performance since it can now make use of everything the physical CPU has to offer.
Using more generic virtual CPU types can cause increased latency as more overhead is required for handling the emulation of specific CPU functions.
When not to use host CPU
It’s not a solution for everyone
This isn’t some miracle setting that works for everything, which is why Proxmox doesn’t enable it by default. As touched on already, using the host CPU type can cause issues with live migration between nodes. Proxmox supports clustering, which can leverage different hardware to form a powerful pool of resources for running VMs and more. Doing so requires the software to effectively manage these instances across the cluster, requiring cross-platform support, which may not work with the host CPU type. If you have different CPUs and platforms, switching to “host” may cause problems.
If two of your nodes have CPUs that do not support the same instruction sets, you may encounter system instability or crashes as Proxmox attempts to use instructions not found on the new host system. This is why more generic CPU types such as x86-64-v2-AES and kvm64 are used within clusters so everything works across all nodes. This is moot if you have a cluster with identical hardware, since all CPUs will support the same instruction sets. It’s only when migrating to hosts with CPUs from a different generation, SKU, or brand could cause problems.
Another reason you may not wish for the CPU type to be switched to host is for security. The setting itself isn’t inherently bad, but should the CPU your Proxmox host uses has known vulnerabilities, these will affect everything running on the system with the type set to “host”. I’m sure you’ve read about Spectre and Meltdown. Then again, your PC could be infected through the same vulnerabilities, so it depends on how sensitive the data is on the server.
