Virtualization on NateBent.com

Proxmox Best Practices - Guest Storage

Nathan Bent — Mon, 11 May 2026 01:00:00 +0000

Why this post exists

Every time I built a new VM I found myself re-litigating the same disk settings: cache mode, aio, whether iothread was worth it, discard on or off. The answers are scattered across forum threads, half of them stale, and a fair number of them wrong for the storage I actually run. So I sat down and worked out a set of defaults I could stop thinking about, then validated them against my own cluster.

This is that reference. The one idea it all hangs on:

Really Interesting!

The right disk settings are decided by how a VM is used, not by the OS inside it. Two questions settle almost everything: can this VM move to another host, and what kind of storage is under it? Answer those and the rest falls out.

I validated everything below against my own three-node cluster. The version baseline matters more than usual here, because io_uring fallback behavior, ZFS Direct I/O, and ARC defaults are all version-dependent. If you are far from this baseline, re-check the assumptions flagged at the end.

Validated against

Component	Version
Proxmox VE	9.2.4
Kernel	7.0.14-2-pve
pve-qemu-kvm	11.0.2
qemu-server	9.1.18
OpenZFS	2.4.3

Two consequences worth stating up front. First, this kernel and QEMU are well past the era where io_uring had rough edges on iSCSI and LVM, so io_uring is safe as a universal default. Second, OpenZFS gained Direct I/O in the 2.3 line, so on a plain file cache=none now actually honors O_DIRECT instead of the older behavior of quietly failing the open. That last point has a catch that bit an assumption I had, and I get into it below.

The short version

Everything here collapses to two storage lanes and a small set of universal guest settings.

The shared, HA lane is network iSCSI. Any VM that must be able to move between nodes, whether HA-managed or just live-migratable, lives here. Mobility forces cache=none for coherency and aio=io_uring for safety. No writeback, ever, because host page cache is per-node and is not coherent across a migration.

The pinned, local lane is local ZFS (or a local dir). Any VM tied to specific hardware through GPU or other PCIe passthrough is pinned here and cannot live-migrate anyway. On ZFS this is still cache=none plus io_uring, because ARC is already the cache. The only place writeback is ever correct is a pinned, disposable VM on a non-ZFS local disk.

Universal settings, every VM, both lanes, both OSes:

SCSI controller: virtio-scsi-single
iothread=1
cache=none (the default; do not override except the one documented writeback case)
aio=io_uring (the default; only consider native on pinned raw-block disks, never on ZFS or qcow2)
discard=on
ssd=1 (SSD emulation) on any SSD-backed tier
Guest agent installed; balloon off for anything memory-sensitive (domain controllers, AI boxes)

Cache: why none, and the one exception

Proxmox cache modes are combinations of O_DIRECT and O_DSYNC semantics. The practical summary:

Mode	Host page cache	Data-loss risk on host crash	Use
`none` (default)	Bypassed (`O_DIRECT`); guest write cache reported present	Low; guest flushes go to storage	Everything here
`writeback`	Used for read and write	In-flight async writes lost on power loss	Narrow: pinned, disposable, non-ZFS
`writethrough`	Used for read; writes sync	Low, but slow writes	Rare
`directsync`	Bypassed; writes sync	Lowest; slowest	Guests that never flush; rarely needed
`writeback (unsafe)`	Used; ignores guest flushes	Total	Throwaway and templating only

Why none wins on ZFS

With cache=none, QEMU opens the disk with O_DIRECT and the Linux host page cache is not used. On ZFS, reads are served from ARC and async writes buffer in the ZFS dirty cache, which flushes on its own timer (about 5 seconds by default). Sync and flush writes are honored and go to the ZIL or SLOG. ZFS is, in effect, already doing writeback-style buffering internally, and doing it safely.

Turning on writeback stacks the host page cache on top of ARC and the ZFS dirty cache. The same data then lives in the guest, the host page cache, and ARC at once. That inflates RAM usage, and the kernel will happily fill free memory with page cache and start swapping. On ZFS, writeback is a straight loss with added crash risk for no gain.

Here is the catch I mentioned, and the part I had wrong in my head at first. Direct I/O in OpenZFS is a dataset feature, and it does not apply to zvols:

QuoteOpenZFS, zfsprops(7)

Direct I/O is “not supported with zvols.” So on a zvol, cache=none never bypasses ARC. It bypasses the host page cache, and ARC does the caching, which is exactly what you want anyway.

So for the great majority of VMs here, which sit on zvols under zfspool storage, cache=none was always the right call and its behavior has not changed. Where Direct I/O actually matters is a raw or qcow2 file sitting on a ZFS dataset, and that is the one place the 2.3 change fixes an old headache. More on that in the Windows template example.

Why none wins on shared iSCSI

Two reasons. The backing store here is a TrueNAS box, which is itself ZFS with its own ARC and ZIL, so writeback at the QEMU layer would double-cache across the network for zero gain. More importantly, writeback holds data in per-node host page cache, which is not coherent across a live migration.

Caution

Any cache mode other than none on storage a VM can migrate across is a known corruption vector. The host page cache is per-node, nothing keeps it coherent across a live migration, and nothing warns you. It works fine right up until a migration eats a VM. Mobile VMs stay on none, full stop.

The one legitimate writeback case

The official Windows guest best-practices guidance does suggest writeback for performance, and a hardware RAID controller with a battery or PLP-backed cache handles writeback fine. Both assume storage with no other caching layer underneath. In a ZFS-heavy environment that describes exactly one situation: a pinned (passthrough) VM whose disk sits on a plain non-ZFS local device (an ext4 or LVM dir store, or a dedicated passed-through SSD), holding disposable data where losing a few seconds of in-flight writes on a crash is an annoyance, not a loss. A Parsec or VDI gaming VM is the textbook fit. On a disk like that, writeback (or even writeback (unsafe) for a pure scratch disk) is correct. The moment that disk is on ZFS, revert to none.

aio: why io_uring, and when native or threads

aio selects the async I/O submission path. The headline benchmark finding: native and io_uring land within a few percent of each other, native has a slight edge at QD1 latency, and io_uring degrades a little less gracefully only under extreme load. So native looks marginally better on paper, but it comes with a hard constraint.

aio=native may only be used on unbuffered, O_DIRECT, raw block storage with cache=none. If anything in the I/O path can block on submission, native blocks the whole submission syscall. That rules it out for:

ZFS (copy-on-write, can block) : use io_uring
qcow2 (metadata lookups block) : use io_uring
thin LVM (virtual-to-physical metadata) : use io_uring

aio=native is only safe on directly-mapped raw block: a raw iSCSI LUN, thick LVM with no overlay, NVMe, or Ceph and RBD, always with cache=none.

Here is why this environment uses io_uring everywhere anyway. The shared iSCSI storage is thick LVM, which on its own would tolerate native. But it has snapshot-as-volume-chain enabled, and that layers a qcow2 overlay on top of the LV whenever a snapshot exists, including during every PBS backup run. Once the active image is qcow2, native blocks. So io_uring is the correct, durable choice for the iSCSI lane, and this qcow2-in-the-chain behavior during backups is a very plausible cause of the intermittent iSCSI I/O oddities I chased a while back. For local ZFS, io_uring is mandatory regardless.

aio=threads is the traditional pairing with cache=writeback (buffered, non-O_DIRECT). It is valid but generally slower than io_uring, which also supports buffered I/O. For the one writeback VM, io_uring is fine and slightly faster; threads is acceptable and harmless. Go with io_uring.

The four-quadrant matrix

The OS quadrants still govern guest-side tuning: drivers, balloon, cluster size. Storage placement collapses to the two lanes, generalized on shared iSCSI and passthrough on local.

Setting	Generalized Linux (DNS, Zabbix, Caddy, Ansible, code-server)	Specialty Linux (AI, other passthrough)	Generalized Windows (DC, PKI)	Specialty Windows (VDI, Parsec)
Lane / storage	Shared iSCSI (HA)	Local ZFS SSD (pinned)	Shared iSCSI (HA)	Local, non-ZFS pinned
Controller	virtio-scsi-single	virtio-scsi-single	virtio-scsi-single	virtio-scsi-single
iothread	1	1	1	1
cache	none	none	none	writeback (only if non-ZFS local and disposable)
aio	io_uring	io_uring	io_uring	io_uring (or threads)
discard	on	on	on	on
ssd	1	1	1	1
balloon	ok	off	off	off
Notes	Already the fleet default	Align data disks	Fixed RAM, virtio drivers	Writeback only if backing is non-ZFS; this box is on ZFS, so none

Real examples from the cluster

I have genericized the hostnames and VM IDs below, but the configs and the deltas I found are the real ones.

Generalized Linux, app-01 (201) and app-02 (202). Already correct: virtio-scsi-single, iothread=1, discard=on, ssd=1, inheriting cache=none and aio=io_uring. No changes. These are the reference implementation for the lane. One of them runs the same code-server setup I wrote up separately, which is a good example of the generalized Linux profile in practice.

Specialty Linux, ai-01 (701). Core is correct: on the SSD-r10 ZFS pool, cache=none and io_uring inherited, balloon=0, NUMA-pinned, GPU passthrough. One delta: scsi0 has discard=on,ssd=1 but the scsi2 256G data disk had neither. Align it:

qm set 701 --scsi2 SSD-r10:vm-701-disk-1,discard=on,ssd=1,iothread=1

For large sequential model storage, a bigger volblocksize (64K to 128K) on that disk’s zvol would compress better and read faster than the 16K default. That requires recreating the zvol, which I cover under ZFS Foundations.

Generalized Windows, domain controllers and PKI (prescriptive; I do not have a live example captured). Same as generalized Linux plus Windows guest tuning: bios=ovmf, machine=q35, the VirtIO SCSI driver loaded at install, qemu-guest-agent, and fixed RAM with balloon off (AD and a CA behave poorly under memory pressure). Do not apply the generic Windows writeback advice here: this data is integrity-critical and lives on shared iSCSI, so cache=none is mandatory.

Specialty Windows, win11-gpu-template (1903), my Windows 11 template. On local dir storage (a .raw file), GPU passthrough, ostype=win11, and it was running aio=threads,cache=writeback,discard=on,ssd=1. This is the case that caught me. local on this node turned out to be a ZFS dataset (rpool/var-lib-vz), so despite the VM being pinned and disposable, the writeback branch does not apply: the .raw sits on ZFS, and writeback just double-caches on top of ARC. The correct config is cache=none plus aio=io_uring:

qm set 1903 --scsi0 local:1903/vm-1903-disk-1.raw,aio=io_uring,cache=none,discard=on,ssd=1,iothread=1

Because this is the template for the whole quadrant, test-boot after the change; every future clone inherits it.

Why it was threads plus writeback originally: on older OpenZFS, cache=none on a file on a ZFS dataset failed to open with O_DIRECT (the classic could not open disk image), and buffered I/O via writeback and threads was the working fallback. OpenZFS 2.3 added Direct I/O on files, and 2.4.3 here has it, so O_DIRECT on a file opens cleanly and the workaround is no longer needed. If O_DIRECT is still somehow rejected, do the architecturally correct thing instead: VM disks on ZFS belong on zvols (zfspool storage), not raw files on dir storage. Migrating this disk to a zvol-backed store (or the node’s local-ssd-2tb-qvo thin-LVM pool) gives native cache=none plus io_uring with no caveats, and puts the box cleanly in the local ZFS pinned lane. Worth noting, since Direct I/O does not touch zvols, moving to a zvol is not about O_DIRECT at all; it just sidesteps the whole file-on-dataset problem.

ZFS foundations

Guest disk settings sit on top of these. Getting them wrong causes slow, invisible degradation over months, which is exactly why they belong in any storage doc you intend to trust.

Current state

ashift=12 (4K sectors) on all pools. Correct for these drives, and since ashift is immutable it is locked in well.
volblocksize=16K on all zvols (the PVE 8.1+ default). All pools are mirrors or striped mirrors, so there is no RAIDZ parity-padding penalty; 16K is an efficient general default here.
compression=lz4 everywhere. Keep it; it is effectively free and often a net throughput gain.
sync=standard everywhere. Correct. It honors guest flushes and batches async writes via the transaction group. Do not set sync=disabled (unsafe) or sync=always (slow) as a blanket policy.
logbias=latency, ARC c_max=64G on 251G RAM (currently around 28G). Healthy and deliberate, and well clear of the PVE default 10% cap.

volblocksize alignment

volblocksize sets the ZFS record size for a zvol and cannot be changed in place; it is fixed at creation, so changing it means creating a new disk. Alignment guidance:

General Linux guests (ext4, xfs): the 16K default is fine. Leave it.
Windows guests: NTFS defaults to 4K clusters. A 4K guest write against a 16K zvol block forces a 16K read-modify-write, up to 4x write amplification on small random writes. Mitigations, in order of preference: format Windows data volumes with 16K or 64K NTFS clusters to match or exceed volblocksize; or leave the OS volume default and accept the modest overhead (SSD plus lz4 make it tolerable). Do not lose sleep over this on the SSD tiers, but do care about it for write-heavy Windows workloads.
Large sequential data (AI models, media): a 64K to 128K volblocksize compresses better and streams faster than 16K. Worth doing on dedicated data zvols, not OS disks.

Storage-level thin provisioning

local-zfs-hdd-8tb-r10 has sparse 1 (thin). local-zfs-ssd-8tb-r10 does not, so new disks there are created thick with a refreservation, which blunts thin provisioning and discard reclaim on the best pool. Add it (affects new disks only):

# via GUI: Datacenter > Storage > local-zfs-ssd-8tb-r10 > Thin provision = yes
# existing thick disks stay thick until recreated

TRIM

autotrim=off on all pools. The guest discard chain (fstrim to discard=on to the zvol) frees blocks inside ZFS, but nothing TRIMs the physical SSDs unless autotrim is on or a scheduled trim runs. I prefer a scheduled monthly trim over autotrim=on, since scheduled trim avoids the latency spikes continuous autotrim can cause:

# monthly zpool trim via systemd timer (create on each node with SSD pools)
systemctl enable --now zfs-trim-monthly@local-zfs-sas-ssd-r10.timer   # if using a template unit
# or a simple cron: 0 3 1 * *  /sbin/zpool trim local-zfs-sas-ssd-r10

SLOG note

The 8TB HDD pool’s SLOG is a consumer SSD with no power-loss protection. A SLOG without PLP can lose the in-flight sync writes it exists to protect on a power event. That is acceptable for a homelab, but it is a known weak point: an enterprise PLP SSD (or the enterprise SAS SSDs already in the box) would be the upgrade path. On UPS, the practical risk narrows to kernel panics and hardware faults.

Guest-side checklists

Linux

VirtIO SCSI single controller, iothread=1, discard=on.
Enable periodic TRIM inside the guest: systemctl enable --now fstrim.timer.
Modern ext4 and xfs honor barriers and flushes by default; nothing to do.
qemu-guest-agent installed and running (agent: 1) for clean quiesce, backup, and shutdown.

Windows

bios=ovmf, machine=q35, TPM as needed.
Load the VirtIO SCSI driver from the virtio-win ISO during install; install the full virtio guest tools plus qemu-guest-agent afterward.
ssd=1 so Windows treats the disk as SSD (disables scheduled defrag, enables Retrim). discard=on so UNMAP reaches the backend.
Balloon off with fixed RAM on infrastructure (DCs, CA). The balloon driver can cause slowdowns and memory pressure that AD and PKI dislike.
Where volblocksize matters (write-heavy data volumes), format NTFS with a 16K or larger cluster size.

Health and hygiene findings

These sit outside the per-VM settings. Ordered by urgency:

local-zfs-hdd-3tb-mirror is around 94% full and doubles as the PBS datastore. ZFS write performance and fragmentation degrade sharply past roughly 80 to 85% full. This undermines everything on that pool regardless of VM settings. Reclaim space or relocate the PBS datastore first.
No physical TRIM scheduled (autotrim off, no zpool trim timer). Add a monthly scheduled trim on the SSD pools.
local-zfs-ssd-8tb-r10 missing sparse 1. New disks on the best pool are thick. Enable thin provisioning; convert existing thick disks opportunistically.
Consumer non-PLP SLOG on the 8TB pool. Document the risk; plan a PLP replacement.
Cosmetic: recordsize=16K set at the SSD pool root is inert for zvols (it governs file datasets, not volumes). Harmless, noted so it is not mistaken for VM tuning.

What to re-verify when things change

This doc is durable, not eternal. Re-check these when the environment shifts:

On a PVE major upgrade: confirm the default aio is still io_uring and that no new io_uring or storage fallback was introduced. Re-read the qemu-server changelog for disk-default changes, and confirm the ARC default cap has not moved under you.
On an OpenZFS major upgrade: re-check Direct I/O behavior and any change to the default volblocksize for newly created disks.
If the TrueNAS or iSCSI fabric is rebuilt (say, proper 10GbE): re-confirm whether the presentation is still thick LVM with snapshot-as-volume-chain. If it ever becomes thin, native was already ruled out, but re-verify io_uring is still the default. If you move to a non-ZFS SAN with BBU cache, the writeback calculus changes for pinned VMs on it.
If any pinned Windows VM moves onto ZFS: drop writeback back to cache=none.
If you add a dedicated SLOG or L2ARC, or change ashift on a rebuild: revisit the sync and volblocksize notes.

Quick reference

Universal:      scsihw=virtio-scsi-single  iothread=1  discard=on  ssd=1
Shared iSCSI:   cache=none  aio=io_uring                 (HA / mobile)
Local ZFS:      cache=none  aio=io_uring                 (pinned)
Local non-ZFS,  cache=writeback  aio=io_uring            (pinned + disposable ONLY)
 disposable:
Never:          aio=native on ZFS/qcow2/thin-LVM; writeback on ZFS or shared/mobile
Windows infra:  balloon off, fixed RAM, virtio drivers

References and further reading

Proxmox, Storage: LVM (snapshots as volume chains). Confirms that snapshot-as-volume-chain layers qcow2 on top of the LV, which is what rules out aio=native on the iSCSI lane during snapshots and backups.
OpenZFS, zfsprops(7). The direct, sync, and volume properties, including that Direct I/O bypasses ARC on datasets and is not supported on zvols.
OpenZFS, 2.4.0 release notes. The Direct I/O line and the uncached-I/O fallback behavior referenced above.
Proxmox, Proxmox VE 9.2 release notes. The version baseline this doc was validated against (kernel 7.0, QEMU 11.0, ZFS 2.4).

Proxmox Best Practices - Guest CPU Types

Nathan Bent — Mon, 04 May 2026 01:00:00 +0000

Context

Every time I build a VM on the Proxmox cluster I hit the same menu, and for a while I overthought it. The Processor dropdown offers host, a stack of x86-64-vN types, a long list of named models like Broadwell-noTSX-IBRS or EPYC-Milan, and whatever custom models I have defined. Most guides frame the choice as stability versus performance, and that framing is exactly the part I had wrong in my head at first.

The lever is not stability versus performance. It is portability versus CPU feature exposure.

Feature exposure is how many host CPU flags (AVX2, AES-NI, AVX-512, and so on) the guest can see and use. More flags means feature-heavy code runs faster, and host hands the guest everything the physical CPU has. Portability is whether a running VM can live-migrate to another node. A VM that advertises a flag to its guest and then lands on a host without that flag does not degrade gracefully: the QEMU process stops. The fixed virtual types exist to advertise a stable, lowest-common feature set so the VM boots and migrates identically everywhere.

So a VM set to host is not less stable on its home node. It is just non-portable. That is the real cost, and once I framed it that way the rest fell out of one question per VM.

Really Interesting!

The Proxmox CPU type menu is not a stability versus performance slider. It is a portability versus feature-exposure trade. host gives the guest every flag the physical CPU has and gives up live migration. The x86-64-vN types give up flags to stay migratable.

The one question

Does this VM need to move between nodes, or does it need to squeeze the host CPU? Everything below is downstream of that. The short version of how I answer it:

Single node, or a VM already pinned to one node by PCI passthrough or hard affinity, gets host. Migration is already off the table, so I take the free flags. That holds for Linux; Windows is a different story, which is the whole reason this post exists.

A VM that needs cluster-wide live migration gets the lowest CPU generation common to every node, either as an x86-64-vN level or a named model of that generation.

A migration domain with mixed Intel and AMD forces the vendor-neutral x86-64-vN types. Named vendor models will not cross vendors, and Proxmox is explicit that live migration between Intel and AMD hosts has no guarantee of working at all.

The options

host

Exposes the exact flags of the physical CPU. Maximum feature exposure, best Linux performance for anything that uses modern instruction sets. The cost is that it breaks live migration to any node with a different CPU or microcode: if a required flag is missing on the target, QEMU aborts. I use it for single-node hosts, a genuinely homogeneous cluster (identical CPU and microcode on every node), or a VM that is already unmovable because of passthrough.

The x86-64-vN virtual types

Vendor-neutral, defined jointly by AMD, Intel, Red Hat, and SUSE in 2020, and they work on both Intel and AMD hosts. This is the migration-safe family.

Type	Compatible with (min CPU)	Flags added over the previous level
`kvm64` (x86-64-v1)	Intel Pentium 4+, AMD Phenom+	baseline (Pentium 4 level, poor perf)
`x86-64-v2`	Intel Nehalem+, AMD Opteron G3+	cx16, lahf-lm, popcnt, pni, sse4.1, sse4.2, ssse3
`x86-64-v2-AES`	Intel Westmere+, AMD Opteron G4+	aes
`x86-64-v3`	Intel Haswell+, AMD EPYC (Naples)+	avx, avx2, bmi1, bmi2, f16c, fma, movbe, xsave
`x86-64-v4`	Intel Skylake+, AMD EPYC Genoa (v4)+	avx512f, avx512bw, avx512cd, avx512dq, avx512vl

Two things about that table are worth holding onto. The backend and CLI default is kvm64, but the GUI default for a new VM is x86-64-v2-AES. That matters because a VM created from a script or the CLI can quietly land on kvm64 while one clicked together in the web UI gets v2-AES. And do not treat kvm64 as the safe default: some modern distros, CentOS and RHEL 9 for example, are built for x86-64-v2 as a minimum and will not boot on kvm64. The sane floor is v2-AES. For migration, pick the highest level your weakest node supports.

Named vendor models

Specific microarchitectures, more granular than the vN levels, and a named model may expose a flag a vN level does not. They are vendor-locked: an Intel model will not migrate to an AMD host, or the reverse. Models with an -IBRS or -IBPB suffix already carry the relevant Spectre v2 control flag. I reach for these on a same-vendor cluster where I want a specific generation’s flags and still want migration, choosing the lowest generation present in the cluster.

Custom models

You can define a reusable base plus flag toggles under Datacenter, Custom CPU Models (backed by /etc/pve/virtual-guest/cpu-models.conf), then reference it from a VM as custom-<name>:

cpu-model: avx
    flags +avx;+avx2
    phys-bits host
    hidden 0
    hv-vendor-id proxmox
    reported-model kvm64

reported-model controls what the guest thinks it is running on. phys-bits host matches the host’s address bits but breaks migration to hosts with a different value. Access is ACL-gated per model at /mapping/cpu/<name>: Mapping.Use is required to assign a model to a VM, and that check is enforced on create, update, and clone, so someone who can clone a VM that uses a custom model still needs Mapping.Use on it. These earn their place when you want one documented, cluster-wide profile reused across many VMs.

Here is the part that is easy to miss. The x86-64-vN virtual types do not enable the Spectre and Meltdown mitigation flags by default. host inherits whatever the physical CPU exposes, so the migration-safe path silently gives those up unless you add them back. Two things have to be true for any of these flags to help: the host CPU has to support and propagate the feature (current microcode), and the guest OS has to be patched to use it.

For Intel guests: pcid reduces the Meltdown and KPTI performance hit, it is cheap, so add it. spec-ctrl covers Spectre v1 and v2 where retpolines are not enough; it is included in -IBRS models and needs adding explicitly otherwise. ssbd is the Spectre v4 fix, never included by default, always explicit.

For AMD guests: ibpb covers Spectre v1 and v2, included in -IBPB models, add otherwise. amd-ssbd is the Spectre v4 fix with higher performance than virt-ssbd. Expose virt-ssbd as well, because some kernels only understand that one, and it has to be set explicitly even with host since it is a virtual flag that does not exist on physical AMD CPUs. amd-no-ssb tells newer silicon it is not vulnerable to v4, and it is mutually exclusive with the two ssbd flags.

To see what the host actually exposes:

for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "${f##*/} -" $(cat "$f"); done
grep ' pcid ' /proc/cpuinfo

A migration-safe Intel base with the mitigations added back looks like this:

cpu: x86-64-v3,flags=+pcid;+spec-ctrl;+ssbd

Why Windows is different

On Linux, host does what you expect: more flags, more performance, no penalty. On Windows it frequently makes things slower, and for a while that made no sense to me. Native has to beat emulated, right? Not here.

When the CPU type is host, QEMU passes the physical CPU’s security flags into the guest, including md_clear (the MDS mitigation) and flush_l1d (the L1TF mitigation). Windows sees those flags and switches on its own in-guest mitigations, the VERW and L1D flushes on transitions. The result is a large jump in memory read latency and, in bad cases, a guest that visibly stutters with the vCPUs pegged. The x86-64-vN types and most named models do not pass md_clear or flush_l1d, so Windows never turns those mitigations on and the penalty never appears. This is a community finding rather than official CPU-type documentation, but it is well corroborated on the forums and it matches what I have seen.

There is a second effect stacked on top. With host, Windows can decide it is running on real hardware and enable virtualization-based security, which pulls in nested virtualization inside the VM, which hurts again. msinfo32 will tell you whether Windows thinks it is virtualized and whether VBS is on.

Caution

On Windows guests, host is often slower than x86-64-v3, not faster, and it fails silently: no error, just high CPU and sluggish memory latency. Passing md_clear and flush_l1d makes Windows enable its own in-guest MDS and L1TF mitigations. The x86-64-vN types leave those flags off, so the penalty never triggers.

Net effect: on Windows, x86-64-v3 is frequently both faster and migratable than host. Older Windows Server barely touches the newer instruction extensions anyway, so the flags host adds rarely pay for the mitigation cost they trigger. That is why I default Windows guests to x86-64-v3, with x86-64-v2-AES as the conservative fallback for older or mixed-low clusters.

One caveat I want to be careful about, because it gets oversold:

Warning

“Switching off host loses no security, the mitigations still run at the hypervisor level” is only half true. Cross-VM and host-to-guest isolation are handled by the Proxmox kernel regardless of guest CPU type. What you actually give up is the guest’s own intra-VM MDS and L1TF protection: process-to-process and kernel-to-user side-channel hardening inside that Windows VM. Fine for a single-tenant VM running trusted code. Weigh it deliberately for a multi-user RDS host or anything running untrusted workloads.

It is also worth being honest that the vN types get their safety purely by not exposing the flags, so v3 is not inherently more secure than host with md_clear stripped. It does the same thing by omission.

Applying a CPU type change needs a full shutdown and start. A reboot from inside Windows is not enough to renegotiate the vCPU. I confirm the change with Get-SpeculationControlSettings: on host the mitigations report active, on v3 they report inactive because the flags are absent.

When host is genuinely required

Reach for host, or explicit flag exposure, when a feature demands it, not for raw speed:

Nested virtualization inside the guest (WSL2, Hyper-V, Docker Desktop, Android emulators, or Windows VBS and HVCI that you actually want on). GPU or PCI passthrough, and anti-cheat that inspects CPU identity. Software that needs an instruction set your vN floor does not carry.

In those cases the VM is usually pinned already, since passthrough kills migration, so host costs nothing extra on the portability axis. On Windows, accept that the mitigation penalty rides along; if VBS is the goal, that penalty is the feature. A couple of Windows-on-recent-Intel specifics live here: if Hyper-V or VBS hangs at boot under host or max, level=30 is the known workaround (x86_64 only, silently ignored elsewhere). And cet-ss and cet-ibt are disabled by default for Windows 11 machine types because they currently break boot for guests with VBS, so only re-enable them per VM if a workload needs them.

The supporting knobs

Sockets times cores is total vCPUs, and the split is mostly irrelevant for performance. Set sockets for software licensing if that matters, otherwise one socket, or match NUMA nodes. Overcommit is safe: total vCPUs across all VMs can exceed physical cores, and the host schedules them like any multithreaded load. Proxmox will not let a single VM exceed the physical core count.

On multi-socket hosts, enable NUMA so guest memory and vCPUs land local to a socket instead of spread across the memory bus. It is also required to hot-plug cores or RAM. When enabled, set the VM’s socket count to the number of host NUMA nodes. Check with numactl --hardware | grep available, where more than one node means the host is NUMA.

For resource control there are three knobs. cpulimit is a hard cap on host CPU time in whole-core units (1.0 is one core, 4.0 is four); set it equal to the total core count to guarantee a VM never exceeds its vCPUs, since peripheral and IO threads can otherwise push it slightly over. cpuunits is relative scheduler weight, default 100 (or 1024 on legacy cgroup v1); a VM at 200 gets twice the CPU bandwidth of one at 100 under contention, so it is priority, not a cap. affinity pins vCPUs to specific host cores in taskset list format, for example 0-1,8-11; it is useful for latency-sensitive or NUMA-pinned workloads, at the cost of maintenance and the risk of lopsided utilization, and it is explicitly not a security boundary.

vCPU hot-plug is newer and more fragile than the alternatives, so I prefer resource limits unless I truly need it. Max pluggable is always sockets times cores, and vcpus sets how many are plugged at start. It is Linux only, a kernel newer than 4.7 is recommended, and you need a udev rule to online new CPUs automatically.

A few Windows extras I keep in mind regardless of CPU type: install the VirtIO drivers from the virtio-win ISO at build time (and consider pinning a known-good virtio-win release rather than always taking the newest), leave the machine version pinned (it is automatic for Windows, because Windows reacts badly to virtual-hardware changes even across cold boots), and set balloon: 0 on anything critical, since the Windows balloon driver is not built in and can slow the guest.

Profiles I actually use

These assume the migratable profiles are ones I want to keep freely live-migratable across the cluster. If a given VM is pinned, I treat it as the specialized profile instead.

General Linux, portability first:

cpu: x86-64-v2-AES,flags=+pcid;+spec-ctrl;+ssbd
numa: 1

Raise the base to x86-64-v3 if every node is Haswell or newer, which picks up AVX2. The AMD variant is flags=+ibpb;+amd-ssbd;+virt-ssbd.

Specialized Linux, features first and pinned:

cpu: host
numa: 1
affinity: <cores for the target socket>

This is the local-AI and GPU-passthrough pattern. Passthrough already blocks migration, so host costs nothing. Pin affinity and memory to the socket that owns the GPU or NIC. On AMD with host, still add +virt-ssbd explicitly. One nuance: on some Intel server parts, heavy AVX-512 lowers all-core clocks, so more flags is not unconditionally faster for mixed workloads. Benchmark the real workload rather than assuming v4 or host wins.

General Windows, my default for almost every Windows VM:

cpu: x86-64-v3
numa: 1
balloon: 0

Do not add md_clear or flush_l1d; leaving them off is the whole point on Windows. Leave the machine version pinned. Applying the change needs a full shutdown and start, after which I confirm with Get-SpeculationControlSettings that the mitigations went inactive.

Specialized Windows, only when a feature forces host:

cpu: host,flags=+pcid;+spec-ctrl;+ssbd
numa: 1
affinity: <cores for the target socket>

Only when the feature list above applies. If you just want speed, x86-64-v3 is almost always faster on Windows. Add level=30 if Hyper-V or VBS hangs at boot on recent Intel, and re-enable cet-ss;cet-ibt per VM only if a VBS workload needs them. If performance is unacceptable and you do not need the guest’s own MDS and L1TF protection, a custom model can strip md_clear while keeping other host flags, but weigh that intra-guest trade first.

My cluster

A cluster that spans Dell generations mixes CPU capability levels. As a worked example from my setup: an R730xd (13th gen, Broadwell-era Xeon E5 v3 and v4) supports up to x86-64-v3, while an XC740xd (14th gen R740 base, Skylake-SP and Cascade Lake) additionally supports x86-64-v4 with AVX-512. The migration-safe ceiling for the whole cluster is therefore the lower of the two, x86-64-v3. Only VMs pinned to the Skylake-class node can safely use host or v4 and see AVX-512.

So the action is simple: run lscpu on every node, set the house default to the highest vN level the weakest node supports, and reserve host for pinned, passthrough, or single-node VMs.

Decision checklist

Windows guest? Default to x86-64-v3 (fallback x86-64-v2-AES), even on a single node, because host triggers the mitigation penalty. Only use host if a feature forces it.
Linux guest, pinned by passthrough or hard affinity, or on a single-node host? Use host. Linux has no mitigation penalty, so take the free flags.
Needs cluster-wide live migration? Mixed Intel and AMD goes to x86-64-vN at the lowest common level. Single vendor goes to x86-64-vN at the lowest common level, or a named model of the lowest generation for extra flags.
Linux only: add mitigation flags unless you used host and confirmed the host already exposes them. Intel +pcid;+spec-ctrl;+ssbd, AMD +ibpb;+amd-ssbd;+virt-ssbd.
Multi-socket host: set numa: 1, sockets equal to NUMA node count.
Windows extras: VirtIO ISO at build time, leave the machine version pinned, balloon: 0 if critical, level=30 if Hyper-V boot fails on recent Intel with host, BIOS power profile to max performance.
Noisy-neighbor risk: cpulimit for a hard cap and cpuunits for priority.
After any CPU type change: full shutdown and start, not a guest reboot.

Quick reference

# Set CPU type
qm set <vmid> --cpu host
qm set <vmid> --cpu x86-64-v3
qm set <vmid> --cpu x86-64-v3,flags=+pcid;+spec-ctrl;+ssbd
qm set <vmid> --cpu custom-<name>

# NUMA and affinity
qm set <vmid> --numa 1
qm set <vmid> --affinity 0-1,8-11

# Resource control
qm set <vmid> --cpulimit 4        # cap at 4 cores of host time
qm set <vmid> --cpuunits 200      # 2x scheduler weight vs default 100

# Host capability checks
lscpu
numactl --hardware | grep available
grep ' pcid ' /proc/cpuinfo
for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "${f##*/} -" $(cat "$f"); done

Inside a Windows guest, to compare the mitigation state before and after a change:

Install-Module -Name SpeculationControl -Force
Get-SpeculationControlSettings   # compare host vs x86-64-v3
msinfo32.exe                     # VBS state, and whether Windows sees it is a VM

VM config lives at /etc/pve/qemu-server/<vmid>.conf, and custom models at /etc/pve/virtual-guest/cpu-models.conf.

References and further reading

Proxmox VE admin guide, QEMU/KVM chapter (CPU type, flags, resource limits, NUMA): https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_cpu
Meltdown and Spectre CPU flags section of that chapter: https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_meltdown_spectre
List of AMD and Intel CPU types as defined in QEMU: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_qm_vcpu_list
Manual: cpu-models.conf, for custom CPU models: https://pve.proxmox.com/wiki/Manual:_cpu-models.conf
Proxmox forum thread identifying md_clear and flush_l1d as the Windows performance trigger: https://forum.proxmox.com/threads/help-about-cpu-type.132652/

Virtualization on NateBent.com

Proxmox Best Practices - Guest Storage

Why this post exists

Validated against

The short version

Cache: why none, and the one exception

Why none wins on ZFS

Why none wins on shared iSCSI

The one legitimate writeback case

aio: why io_uring, and when native or threads

The four-quadrant matrix

Real examples from the cluster

ZFS foundations

Current state

volblocksize alignment

Storage-level thin provisioning

TRIM

SLOG note

Guest-side checklists

Linux

Windows

Health and hygiene findings

What to re-verify when things change

Quick reference

References and further reading

Proxmox Best Practices - Guest CPU Types

Context

The one question

The options

host

The x86-64-vN virtual types

Named vendor models

Custom models

The security dimension nobody puts on the menu

Why Windows is different

When host is genuinely required

The supporting knobs

Profiles I actually use

My cluster

Decision checklist

Quick reference

References and further reading