# VIKINGS wiki

It's better when it's simple

User Tools

Site Tools

Trace:
virtualisation:proxmox_ve:vms_cts:vm_best_practices_modern_setup

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
virtualisation:proxmox_ve:vms_cts:vm_best_practices_modern_setup [2026/04/13 07:17] – reshuffle content for tl;dr thumvirtualisation:proxmox_ve:vms_cts:vm_best_practices_modern_setup [2026/05/05 14:59] (current) – adding tl;dr for Windows guests thum
Line 3: Line 3:
 Recommended settings for creating new VMs on Proxmox VE 9.x with modern guest operating systems. Recommended settings for creating new VMs on Proxmox VE 9.x with modern guest operating systems.
  
-===== TL;DR / Quick Reference =====+===== TL;DR / Quick Reference for Linux Guests=====
  
 ^ Component ^ Setting ^ ^ Component ^ Setting ^
Line 16: Line 16:
 | Skip Replication | ❌ | | Skip Replication | ❌ |
 | Network | ''VirtIO'' | | Network | ''VirtIO'' |
-| CPU Type | ''x86-64-v3'' (homogeneous) / ''x86-64-v2-AES'' (mixed) |+| CPU Type | ''host'' (homogeneous) / ''x86-64-v3-AES'' (mixed) / :!: see remarks below |
 | Allow KSM | ✅ | | Allow KSM | ✅ |
  
 +===== TL;DR / Quick Reference for Windows Guests =====
  
 +^ Component ^ Setting ^
 +| Machine | ''q35'' |
 +| BIOS | ''OVMF (UEFI)'' |
 +| TPM | ''v2.0'' (required for Win11 / Server 2025) |
 +| SCSI Controller | ''VirtIO SCSI single'' |
 +| Discard | ✅ |
 +| SSD Emulation | ✅ |
 +| IO Thread | ✅ |
 +| Cache | ''Write back'' (better performance for Windows than ''no cache'' (but also data loss risk when power outage)) |
 +| Async IO (Ceph) | ''native'' |
 +| Skip Replication | ❌ |
 +| Network | ''VirtIO'' (requires VirtIO driver ISO) |
 +| CPU Type | ''x86-64-v3-AES'' :!: do NOT use ''host'' (triggers VBS/Core Isolation in Windows) |
 +| Allow KSM | ✅ |
 +| QEMU Guest Agent | ✅ (install via ''virtio-win-guest-tools.exe'') |
 +| VirtIO Driver ISO | ✅ (attach as 2nd CD-ROM during installation) |
  
 ====== Details ====== ====== Details ======
Line 64: Line 81:
  
 VirtIO delivers the highest network performance of all available models. VirtIO delivers the highest network performance of all available models.
 +
  
 ===== CPU ===== ===== CPU =====
Line 69: Line 87:
 ^ CPU Type ^ Compatibility ^ Additional Flags ^ ^ CPU Type ^ Compatibility ^ Additional Flags ^
 | ''x86-64-v2-AES'' | Intel ≥ Westmere, AMD ≥ Opteron_G4 (~2010) | ''+aes'' | | ''x86-64-v2-AES'' | Intel ≥ Westmere, AMD ≥ Opteron_G4 (~2010) | ''+aes'' |
-| ''x86-64-v3'' | Intel ≥ Haswell, AMD ≥ EPYC (~2015) | ''+avx, +avx2, +bmi1, +bmi2, +fma, +xsave'' | +| ''x86-64-v3'' | Intel ≥ Haswell, AMD ≥ EPYC Zen 3 (~2015) | ''+avx, +avx2, +bmi1, +bmi2, +fma, +xsave'' | 
-| ''host'' | Identical hardware only | All host CPU features |+| ''x86-64-v4'' | Intel ≥ Skylake-SP/Icelake, AMD ≥ EPYC Zen 4 / Genoa (~2022) | ''+avx512f, +avx512bw, +avx512cd, +avx512dq, +avx512vl'' | 
 +| ''host'' | Identical hardware only | All host CPU features (passed through directly) |
  
   * ''x86-64-v2-AES'' is the Proxmox default — safest for mixed clusters with different CPU generations   * ''x86-64-v2-AES'' is the Proxmox default — safest for mixed clusters with different CPU generations
   * ''x86-64-v3'' is **recommended** if all hosts support it (most CPUs ≥ 2015 do) — notable gains in compression, cryptography and modern workloads via AVX2   * ''x86-64-v3'' is **recommended** if all hosts support it (most CPUs ≥ 2015 do) — notable gains in compression, cryptography and modern workloads via AVX2
-  * ''host'' gives maximum performance but prevents live migration between different CPU models+  * ''x86-64-v4'' requires AVX-512 support — only available on AMD EPYC Zen 4 (Genoa, ~2022) or newer and Intel Skylake-SP/Icelake server CPUs; **not** supported on AMD EPYC Zen 3 (Milan/7R13) or most Intel consumer CPUs (Alder Lake and later have AVX-512 disabled) 
 +  * ''host'' gives maximum performance by passing all host CPU flags directly to the VM, but **live migration is only possible between nodes with identical CPU models and microcode versions** — adding a node with a different CPU generation will break live migration for affected VMs 
 +  * **Optional: manual CPU flag additions — provided **all nodes in the cluster** support these flags
  
 **Recommendation:** **Recommendation:**
-  * Homogeneous cluster or single node → ''x86-64-v3'' or ''host''+  * Fully homogeneous cluster (same CPU model on all nodes) → ''host'' for maximum performance 
 +  * Homogeneous cluster, migration compatibility desired, or new nodes with different CPUs expected → ''x86-64-v3''
   * Mixed cluster with different CPU generations → ''x86-64-v2-AES''   * Mixed cluster with different CPU generations → ''x86-64-v2-AES''
 +  * Changing from ''host'' to ''x86-64-v3'' is non-destructive and only requires a VM reboot
 +  * :!: Do mind the remarks about Windows VMs below
 +
 +
 +==== Windows VMs ====
 +
 +  * **Avoid ''host'' with Windows 11 / Windows Server 2025:** Known issue in PVE 8.4+ where ''host'' causes severe performance degradation (CPU pegged at 100%, I/O stalls) due to interactions with Windows core isolation and Virtualization-Based Security (VBS/HVCI) features — use ''x86-64-v3'' instead [web:1][web:9]
 +  * **''x86-64-v3'' is the recommended CPU type for Windows VMs** — stable, performant, and avoids the above issues [web:9]
 +  * **Windows internalizes CPU features at first boot:** Once a Windows VM has booted with a richer CPU type (e.g. ''host'' on a Zen 4 node), migrating it to a node with fewer CPU features can cause boot failures or crashes — Windows kernel structures are built around the CPU flags seen at first boot [web:54]
 +  * **Backup/restore vs. live migration:** Changing CPU type between ''host'' and a generic type (e.g. ''x86-64-v3'') and restoring from backup works fine for Windows VMs; live migration across different CPU types does not [web:30]
  
 ===== Memory ===== ===== Memory =====
Line 94: Line 126:
 ===== See also ===== ===== See also =====
  
-* [[virtualisation:proxmox_ve:vms_cts:initial_debugging_vm_created_best_practices|Initial Debugging VM]]+  * [[virtualisation:proxmox_ve:vms_cts:initial_debugging_vm_created_best_practices|Initial Debugging VM]] 
 +  * https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines#qm_virtual_machines_settings 
          
virtualisation/proxmox_ve/vms_cts/vm_best_practices_modern_setup.1776064655.txt.gz · Last modified: by thum