VM Configuration Best Practices
VM Configuration Best Practices
Photo by Brett Sayles on Pexels
Creating a VM that works is easy. Creating a VM that performs well, uses resources efficiently, and is easy to maintain takes a bit more thought. In this lesson, we'll cover the configuration choices that separate a well-built VM from a problematic one.
CPU Configuration
Choosing the CPU Type:
host: Passes through your CPU's native features. Best performance but VMs can only be migrated to hosts with the same or newer CPU.x86-64: Maximum compatibility. Works on any x86-64 CPU but loses some performance optimizations.kvm64: A middle ground — compatible with most CPUs and includes basic virtualization features.
Rule of thumb: Use host for single-node deployments. Use x86-64 if you plan to live-migrate between nodes with different CPU generations.
How Many Cores?
Don't over-allocate. A common mistake is assigning 8 vCPUs to a web server that only needs 2. Each vCPU consumes host CPU time even when idle (due to scheduling overhead). Start with:
- 1-2 vCPUs for lightweight services (DNS, monitoring agents, small web apps)
- 2-4 vCPUs for databases, application servers, and build servers
- 4+ vCPUs only for workloads that genuinely need parallel processing
Proxmox allows CPU overcommit (assigning more vCPUs than physical cores), but keep the ratio under 2:1 for production. A 4-core host running VMs with a total of 8 vCPUs is generally fine; 16 vCPUs will cause contention.
Memory Configuration
Ballooning: Proxmox supports memory ballooning — the VM can dynamically give back unused RAM to the host. Enable it by setting minimum memory lower than the maximum. For example, set max to 4096MB and min to 2048MB. The VM starts with 4GB and can shrink to 2GB if the host needs memory elsewhere.
Sizing guidelines:
- Minimal Linux server (DNS, reverse proxy): 512MB-1GB
- General Linux server (web server, file server): 2-4GB
- Database server: 4-8GB (allocate based on your dataset size)
- Windows desktop VM: 4-8GB minimum
Storage Configuration
Storage is often the performance bottleneck. Choose the right bus type and storage backend:
| Disk Bus Type | Performance | When to Use |
|---|---|---|
| VirtIO Block | Best | Linux guests with virtio drivers (all modern Linux) |
| SCSI (VirtIO SCSI) | Excellent | When you need TRIM/discard support or multiple disks |
| SATA | Good | Windows guests or OSes without virtio drivers |
| IDE | Poor | Never — use only for legacy compatibility |
Storage backends:
- local-lvm: Default thin-provisioned storage. Good for single-node setups. Fast on SSD.
- ZFS: Best for data integrity. Supports compression, snapshots, and RAID-Z. Requires ECC RAM for production use.
- LVM-thin: Similar to local-lvm but can span multiple disks. Good for SSD-only setups.
- NFS/iSCSI: For shared storage in clusters. Enables live migration.
Enable discard (TRIM): If using SSDs, enable the "Discard" option on your virtual disk. This tells the underlying storage which blocks are unused, improving SSD lifespan and performance.
Network Configuration
Use VirtIO network: The VirtIO (paravirtualized) network card offers 5-10x better performance than emulated Intel/Realtek cards. All modern Linux distributions include the virtio-net driver. For Windows, download the VirtIO drivers ISO from Fedora.
VLAN tagging: If you use VLANs on your network, set the VLAN tag in the VM's network configuration. This avoids needing a separate bridge per VLAN.
Multi-queue: For high-network-throughput VMs, set the number of queues equal to the number of vCPUs. This distributes network interrupt processing across cores.
Security Best Practices
- Install the QEMU guest agent in every VM — it enables proper graceful shutdown, IP reporting, and snapshot quiescing.
- Disable unused hardware: Remove the floppy drive, serial ports, and USB controllers you don't use. Less attack surface.
- Use UEFI/OVMF for new VMs: While SeaBIOS works fine, OVMF (UEFI) enables Secure Boot and is recommended for new deployments.
- Keep your VMs updated: Apply security patches regularly inside each guest OS. Proxmox manages the VM, but the guest OS manages its own security.
Performance Checklist
- Use VirtIO for disk and network
- Use CPU type "host" for single-node deployments
- Enable ballooning for memory efficiency
- Enable discard on SSD-backed disks
- Install QEMU guest agent in every VM
- Don't over-allocate vCPUs — 2:1 overcommit max
- Use ZFS for storage if you have the RAM for it
Key Takeaways
- VirtIO for disk and network is the single biggest performance win
- Start with fewer resources than you think you need — you can always add more later
- Ballooning and CPU overcommit let you run more VMs, but monitor for contention
- ZFS provides the best storage integrity and features if your hardware supports it
VM Configuration Best Practices
Photo by Brett Sayles on Pexels
Creating a VM that works is easy. Creating a VM that performs well, uses resources efficiently, and is easy to maintain takes a bit more thought. In this lesson, we'll cover the configuration choices that separate a well-built VM from a problematic one.
CPU Configuration
Choosing the CPU Type:
host: Passes through your CPU's native features. Best performance but VMs can only be migrated to hosts with the same or newer CPU.x86-64: Maximum compatibility. Works on any x86-64 CPU but loses some performance optimizations.kvm64: A middle ground — compatible with most CPUs and includes basic virtualization features.
Rule of thumb: Use host for single-node deployments. Use x86-64 if you plan to live-migrate between nodes with different CPU generations.
How Many Cores?
Don't over-allocate. A common mistake is assigning 8 vCPUs to a web server that only needs 2. Each vCPU consumes host CPU time even when idle (due to scheduling overhead). Start with:
- 1-2 vCPUs for lightweight services (DNS, monitoring agents, small web apps)
- 2-4 vCPUs for databases, application servers, and build servers
- 4+ vCPUs only for workloads that genuinely need parallel processing
Proxmox allows CPU overcommit (assigning more vCPUs than physical cores), but keep the ratio under 2:1 for production. A 4-core host running VMs with a total of 8 vCPUs is generally fine; 16 vCPUs will cause contention.
Memory Configuration
Ballooning: Proxmox supports memory ballooning — the VM can dynamically give back unused RAM to the host. Enable it by setting minimum memory lower than the maximum. For example, set max to 4096MB and min to 2048MB. The VM starts with 4GB and can shrink to 2GB if the host needs memory elsewhere.
Sizing guidelines:
- Minimal Linux server (DNS, reverse proxy): 512MB-1GB
- General Linux server (web server, file server): 2-4GB
- Database server: 4-8GB (allocate based on your dataset size)
- Windows desktop VM: 4-8GB minimum
Storage Configuration
Storage is often the performance bottleneck. Choose the right bus type and storage backend:
| Disk Bus Type | Performance | When to Use |
|---|---|---|
| VirtIO Block | Best | Linux guests with virtio drivers (all modern Linux) |
| SCSI (VirtIO SCSI) | Excellent | When you need TRIM/discard support or multiple disks |
| SATA | Good | Windows guests or OSes without virtio drivers |
| IDE | Poor | Never — use only for legacy compatibility |
Storage backends:
- local-lvm: Default thin-provisioned storage. Good for single-node setups. Fast on SSD.
- ZFS: Best for data integrity. Supports compression, snapshots, and RAID-Z. Requires ECC RAM for production use.
- LVM-thin: Similar to local-lvm but can span multiple disks. Good for SSD-only setups.
- NFS/iSCSI: For shared storage in clusters. Enables live migration.
Enable discard (TRIM): If using SSDs, enable the "Discard" option on your virtual disk. This tells the underlying storage which blocks are unused, improving SSD lifespan and performance.
Network Configuration
Use VirtIO network: The VirtIO (paravirtualized) network card offers 5-10x better performance than emulated Intel/Realtek cards. All modern Linux distributions include the virtio-net driver. For Windows, download the VirtIO drivers ISO from Fedora.
VLAN tagging: If you use VLANs on your network, set the VLAN tag in the VM's network configuration. This avoids needing a separate bridge per VLAN.
Multi-queue: For high-network-throughput VMs, set the number of queues equal to the number of vCPUs. This distributes network interrupt processing across cores.
Security Best Practices
- Install the QEMU guest agent in every VM — it enables proper graceful shutdown, IP reporting, and snapshot quiescing.
- Disable unused hardware: Remove the floppy drive, serial ports, and USB controllers you don't use. Less attack surface.
- Use UEFI/OVMF for new VMs: While SeaBIOS works fine, OVMF (UEFI) enables Secure Boot and is recommended for new deployments.
- Keep your VMs updated: Apply security patches regularly inside each guest OS. Proxmox manages the VM, but the guest OS manages its own security.
Performance Checklist
- Use VirtIO for disk and network
- Use CPU type "host" for single-node deployments
- Enable ballooning for memory efficiency
- Enable discard on SSD-backed disks
- Install QEMU guest agent in every VM
- Don't over-allocate vCPUs — 2:1 overcommit max
- Use ZFS for storage if you have the RAM for it
Key Takeaways
- VirtIO for disk and network is the single biggest performance win
- Start with fewer resources than you think you need — you can always add more later
- Ballooning and CPU overcommit let you run more VMs, but monitor for contention
- ZFS provides the best storage integrity and features if your hardware supports it
There are no comments for now.
to be the first to leave a comment.