Proxmox VE Performance Tuning: Optimization Guide

Getting More from Your Proxmox Hardware

Proxmox VE works well out of the box, but default configurations are designed for compatibility, not peak performance. With some targeted tuning, you can squeeze significantly more performance from the same hardware — reducing VM latency, improving disk throughput, lowering memory overhead, and handling more concurrent workloads. This guide covers the most impactful optimizations for production Proxmox environments.

CPU Optimization

CPU Type Selection

By default, Proxmox VMs use the kvm64 CPU type, which is a minimal CPU model designed for maximum compatibility. For better performance, switch to host to pass through your actual CPU features, or use x86-64-v2-AES for a good balance of compatibility and performance across cluster nodes.

# Set CPU type to 'host' for maximum performance (single-node setups)
qm set 100 --cpu host

# For clusters with mixed CPU generations, use a compatible type
qm set 100 --cpu x86-64-v2-AES

CPU Pinning

CPU pinning (affinity) assigns specific physical CPU cores to a VM, preventing the scheduler from moving vCPUs between cores. This reduces cache misses and context-switching overhead, which is especially important for latency-sensitive workloads like databases and game servers.

# Pin VM 100's vCPUs to physical cores 2-5
qm set 100 --affinity 2-5

# Verify the pinning
taskset -cp $(cat /run/qemu-server/100.pid)

Be careful not to overcommit pinned cores. If two VMs are pinned to the same cores, they compete for CPU time and performance degrades. Reserve cores 0-1 for the Proxmox host itself.

NUMA Configuration

On multi-socket servers or AMD EPYC/Threadripper processors, NUMA (Non-Uniform Memory Access) topology matters significantly. When NUMA is enabled, Proxmox ensures each VM's memory is allocated on the same NUMA node as its assigned CPU cores, avoiding expensive cross-node memory access.

# Enable NUMA for a VM
qm set 100 --numa 1

# Verify NUMA topology on the host
numactl --hardware

Hugepages

Standard Linux uses 4KB memory pages. For VMs with large memory allocations, the overhead of managing millions of small pages becomes significant. Hugepages (2MB or 1GB pages) reduce this overhead and improve TLB (Translation Lookaside Buffer) hit rates.

# Allocate 16GB of 2MB hugepages
echo 8192 > /proc/sys/vm/nr_hugepages

# Make it persistent across reboots
echo "vm.nr_hugepages = 8192" >> /etc/sysctl.conf

# Enable hugepages for a specific VM in its config
# Edit /etc/pve/qemu-server/100.conf and add:
# hugepages: 2

Disk I/O Optimization

VirtIO Drivers

VirtIO is a paravirtualized I/O framework that provides near-native disk and network performance. Always use VirtIO for Linux guests. For Windows guests, you need to install the VirtIO drivers — download the latest ISO from the Fedora project and install during Windows setup.

# Set disk bus to VirtIO Block for best performance
qm set 100 --scsi0 local-lvm:vm-100-disk-0,iothread=1,discard=on

# Enable IO threads (one per disk for optimal performance)
qm set 100 --scsihw virtio-scsi-single

I/O Scheduler

The I/O scheduler on the Proxmox host affects all guest disk operations. For SSDs and NVMe drives, the none (or noop) scheduler is best since the device handles its own optimization. For HDDs, mq-deadline provides better performance.

# Check current scheduler
cat /sys/block/sda/queue/scheduler

# Set to 'none' for SSDs (temporary)
echo none > /sys/block/sda/queue/scheduler

# Make permanent via udev rule
cat > /etc/udev/rules.d/60-scheduler.rules <<EOF
ACTION=="add|change", KERNEL=="sd*[!0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd*[!0-9]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/scheduler}="none"
EOF

SSD TRIM and Discard

TRIM allows the SSD to know which blocks are no longer in use, maintaining write performance over time. Enable discard on your VM disks to pass TRIM commands through to the underlying SSD.

# Enable discard on a VM disk
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on

# For LVM-thin storage, ensure issue_discards is enabled
# In /etc/lvm/lvm.conf:
# thin_pool_discards = "passdown"

# Run fstrim periodically inside the VM
# Add to guest's crontab:
# @weekly /usr/sbin/fstrim -av

Memory Optimization

Memory Ballooning

Ballooning allows Proxmox to reclaim unused memory from VMs and make it available to other guests. A VM might be allocated 8GB but only using 3GB — the balloon driver inflates to reclaim the unused 5GB. This is essential for overcommitting memory safely.

# Enable ballooning with a minimum of 2GB and maximum of 8GB
qm set 100 --memory 8192 --balloon 2048

# Check current balloon status
qm monitor 100 -c "info balloon"

The ballooning driver must be installed in the guest OS. Linux guests include it by default. Windows guests need the VirtIO balloon driver.

KSM (Kernel Same-page Merging)

KSM scans memory for identical pages across VMs and deduplicates them. If you run 10 VMs with the same operating system, large portions of their memory will be identical. KSM merges these pages, significantly reducing total memory usage.

# Check KSM status
cat /sys/kernel/mm/ksm/run
cat /sys/kernel/mm/ksm/pages_shared
cat /sys/kernel/mm/ksm/pages_sharing

# Enable KSM
echo 1 > /sys/kernel/mm/ksm/run

# Tune scan rate (pages per scan cycle)
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 20 > /sys/kernel/mm/ksm/sleep_millisecs

Note that KSM consumes CPU cycles for scanning and can introduce side-channel risks. Enable it when memory savings outweigh these costs — typically in environments running many similar VMs.

Network Optimization

VirtIO Network

Always use VirtIO network adapters instead of emulated Intel E1000 or Realtek adapters. VirtIO provides significantly higher throughput with lower CPU overhead.

# Set network adapter to VirtIO
qm set 100 --net0 virtio,bridge=vmbr0

# Enable multiqueue for better multi-core performance
qm set 100 --net0 virtio,bridge=vmbr0,queues=4

Host Network Tuning

# Increase network buffer sizes
cat >> /etc/sysctl.conf <<EOF
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 5000
EOF
sysctl -p

Monitoring Performance Changes with ProxmoxR

After applying performance tuning changes, you need to verify they are actually working. This is where monitoring becomes critical. ProxmoxR provides real-time performance graphs on your phone, making it easy to compare before-and-after metrics without sitting at a desk.

A practical workflow for performance tuning with ProxmoxR:

1. Baseline — Check current CPU, memory, disk I/O, and network metrics for the VM you are tuning using ProxmoxR's graphs.
2. Apply changes — Implement one optimization at a time (e.g., switch to VirtIO, enable hugepages).
3. Monitor — Use ProxmoxR to watch the metrics in real time as the VM runs under normal load. Compare against your baseline.
4. Iterate — If the change improved performance, keep it. If not, revert and try the next optimization.

ProxmoxR's multi-cluster support is especially useful here — you can compare performance between a tuned and untuned node without switching between browser tabs.

Quick-Reference Tuning Checklist

• CPU: Use host CPU type, enable NUMA on multi-socket systems, pin CPUs for latency-sensitive VMs
• Disk: Use VirtIO-SCSI with IO threads, enable discard, set none scheduler for SSDs
• Memory: Enable ballooning, consider hugepages for large VMs, enable KSM if running similar guests
• Network: Use VirtIO NICs with multiqueue, tune kernel buffer sizes
• Monitor: Use ProxmoxR for mobile performance tracking, Grafana for historical analysis

Important: Always change one thing at a time and measure the result. Performance tuning is iterative — what works for one workload may not work for another. Benchmark before and after every change.