Proxmox VM performance tuning: CPU, disk and network settings

Default Proxmox settings are safe but not always the fastest. A few changes to CPU type, disk controller and network model often give noticeably better Proxmox VM performance, especially for databases and busy web servers.

Before you start

• A backup or snapshot of the VM.
• A way to measure: for example fio for disk and iperf3 for network, run before and after.
• Most changes need a full stop and start of the VM.

CPU

• CPU type: host exposes all CPU features for best speed. In clusters with mixed CPUs, use a common model such as x86-64-v2-AES or newer so live migration works.
• Cores vs sockets: use one socket with several cores unless you need NUMA.
• NUMA: enable it for large VMs on multi-socket hosts.
• Do not give a VM more vCPUs than it uses; extra idle vCPUs can add scheduling overhead.

Disk

1. Set the SCSI controller to VirtIO SCSI single (Hardware → SCSI Controller).
2. On each disk, enable IO thread so each disk gets its own I/O thread.
3. Enable Discard on SSD/thin storage and SSD emulation so the guest trims freed blocks.
4. Cache: Default (No cache) is the safe choice. Write back is faster but can lose recent writes on a host crash unless the storage has power-loss protection.
5. Keep VM disks on fast storage; NVMe and ZFS mirrors beat RAIDZ for random I/O.

Network

• Use the VirtIO (paravirtualized) model.
• Set Multiqueue on the network device to the number of vCPUs (up to 8 is common) for high-traffic VMs.
• Check the host NIC and bridge are not the bottleneck with iperf3 between VMs and from outside.

Memory

• Ballooning: lets Proxmox reclaim unused guest RAM; disable it for latency-sensitive databases if you see stalls.
• Avoid overcommitting RAM to the point the host swaps; that hurts every VM (ballooning, KSM and hugepages).

Check afterwards

• Repeat your fio and iperf3 tests and compare.
• Watch the host with top and iostat -x 2 under load.

Troubleshooting

• VM will not boot after changing controller: Windows needs the VirtIO SCSI driver installed first.
• No improvement: the bottleneck may be host storage or CPU contention, not VM settings.

Frequently asked questions

Is write back cache safe?

Only with reliable power protection or when you accept losing the last seconds of writes on a crash.

Should I pin CPUs?

Only for special cases like real-time or gaming VMs (CPU pinning).

Does ballooning slow VMs?

Normally not, but disable it if a database shows memory pauses.

Next steps

• QEMU guest agent
• Storage types
• CPU pinning and overcommit