Memory Tiering and VM Memory Reservation: What You Actually Need to Know

If you’ve been working with VMware vSphere in a memory-tiered environment, you’ve probably run into two concepts that sound similar but behave very differently in practice, VM Memory Reservation and Memory Tier-Disabled VMs. What each one means, how they interact, and why the combination matters for your infrastructure planning are exactly what we’re going to cover here.

Memory Reservation and Where Memory Actually Comes From

Let’s start with a simple question: when your VM says it needs 32 GB of memory, does it actually get 32 GB? Not necessarily, unless you’ve set a reservation.

VM Memory Reservation is the amount of memory that is guaranteed to a VM. Think of it as a promise from the host: “No matter what else is running, I will always have this much memory set aside for you.” Without a reservation, a VM’s memory can be reclaimed by the host under memory pressure.

In vSphere, there are two ways to set a memory reservation, and keeping them straight matters in a Memory Tiering environment.

The reservation number field lets you set a guaranteed amount, up to the full size of the VM. Set it to 64 GB for a 64 GB VM and the scheduler guarantees that memory is always available. But those reserved pages can still be satisfied from either DRAM or Non-Volatile Memory Express (NVMe). Memory Tiering is still in play. This is a software-level guarantee enforced by the vSphere memory scheduler. Actual pages aren’t necessarily allocated until the guest OS and applications access them.

The “Reserve all guest memory (All locked)” checkbox is a convenience mechanism, not a fundamentally different setting. It simply reserves all of the VM’s memory for you automatically, so you don’t have to type the full amount into the reservation number field. Like any full reservation, it prevents the host from reclaiming that memory through swapping, ballooning, or compression under memory pressure. It does not pin memory to DRAM. Memory Tiering is still in play, and reserved pages can still be satisfied from either DRAM or NVMe.

It’s also worth knowing why this checkbox exists in the first place. The “Reserve all guest memory (All locked)” option was added to handle memory hot-add cleanly. When this box is checked and memory is hot-added to the VM, the reservation increases in the same hot-add operation. Without it, a customer would have to first issue an API call to hot-add the memory and then a separate API call to increase the reservation. This VMODL checkbox solves the hot-add to a fully reserved VM more elegantly by handling both in a single step.

Feature	“All Locked” Checkbox	Manual Reservation Number
Coverage	Always 100% of configured RAM	Can be anywhere from 1% to 100%
When upgrading VM RAM	Automatically scales to the new size	Stays at the exact number you typed
Datastore Swap File Size	0 MB (Takes up no disk space)	Equal to Configured RAM minus Reserved RAM
Primary Use Case	Hardware passthrough (vGPU) and strict isolation	Guaranteeing baseline performance during host contention

Pinned memory is a separate concept entirely, and it is not something you set with a checkbox. Pinned memory happens automatically when a VM uses a hardware passthrough device, such as a GPU or NIC configured with DirectPath I/O, FT VMs, latency sensitive, UPT, SEV, or even via other vmx parameters such as sched.mem.prealloc.pinnedMainMem or sched.mem.prealloc.guestMem. In those cases, the pages are locked in place by the IOMMU at the hardware level. Those pages cannot be moved, reclaimed, swapped, migrated, or tiered by any component of the system. The hardware enforces this, not the scheduler. Pinned memory must reside in DRAM and is removed from Memory Tiering entirely. This is fundamentally different from a memory reservation, which is a scheduler-level guarantee that can still be satisfied from either DRAM or NVMe.

Here’s the clearest way to think about it: the reservation number is a promise to the scheduler, “All locked” is simply a convenient way to set that promise to the full VM size, and pinned memory is a contract with the hardware that happens automatically with passthrough devices.

	VM Memory Reservation	Pinned Memory (HW Mapping)
What it guarantees	Capacity is held by the scheduler	Physical pages are locked in place
Who enforces it	vSphere memory scheduler	Hardware (IOMMU / page tables)
Can pages move?	Potentially (balloon, swap) unless “All locked” is checked	No, that’s the whole point
When pages are mapped	Lazily (on access) for reservation number; upfront at power-on for “All locked”	Immediately, at the time of pinning
Typical use cases	Production VMs, latency-sensitive VMs	Passthrough devices, RDMA, VMs with DirectPath I/O
Interaction with tiering	Reserved memory can still be on NVMe tier	Pinned memory must be in DRAM (not pageable)

Recap

• Reservation number = guaranteed capacity, still capable of using Memory Tiering.
• “All locked” checkbox = full reservation (convenience), still capable of using Memory Tiering.
• Pinned memory = hardware-locked pages (from passthrough), DRAM only, removed from tiering.

These are three distinct concepts, and understanding the difference matters a lot when planning a Memory Tiered environment.

Memory Tiering Is the Right Choice for Most Workloads

Before we get into when you might need to disable tiering, it’s worth underscoring just how broadly applicable Memory Tiering is. In our estimation, most customer workloads are highly suitable for Memory Tiering without any modification. General virtualization, VDI deployments, dev/test environments, web and application servers, and databases with moderate memory activity all have natural hot/cold memory patterns that make them ideal candidates. This is a high-value feature, not a niche optimization.

The numbers back that up. Memory Tiering delivers up to 40% lower TCO, 2x better VM consolidation, and up to 4x more available memory per host. It works transparently with no application or guest OS changes, and the default 1:1 DRAM:NVMe ratio is suitable for a wide variety of workloads and customer environments. For most of your VMs, tier-enabled should be the default, not the exception.

What Is a Memory Tier-Disabled VM?

A tier-disabled VM is a VM that has been pulled out of the tiering model entirely. When Memory Tiering is disabled for a VM, all its memory, whether reserved or not, must come exclusively from DRAM and is susceptible to swapping, ballooning, or compression. No NVMe. DRAM only.

This matters because DRAM is a scarce resource in a memory-tiered host. That’s the reason you deployed tiering in the first place, to extend beyond the limits of DRAM. When a VM opts out, it places a harder constraint on the host’s most limited pool.

How Does a VM End Up Tier-Disabled?

There are two paths to this.

1. Implicitly (vSphere does it automatically)

vSphere will automatically disable Memory Tiering for a VM when:

• The VM uses a passthrough device (like a Graphics Processing Unit (GPU) or Network Interface Card (NIC) configured with DirectPath I/O)
• The VM is configured as Latency Sensitivity = High
• The VM is a Fault Tolerant (FT) VM

These scenarios have characteristics, direct hardware access, extreme latency requirements, or memory mirroring that make Memory Tiering incompatible or unsafe. This isn’t a bug; it’s the right behavior. But it does mean these VMs are effectively claiming DRAM-only resources without you necessarily doing anything.

2. Explicitly (You Decide)

Customers can also disable Memory Tiering for a specific VM using an advanced VM configuration property. This gives you fine-grained control when a workload shouldn’t be touching the NVMe tier. Keep in mind that without a full reservation, ballooning, compression, and swapping can occur. More on how to mitigate that below.

The Critical Recommendation: Tier-Disabled VMs Should Always Be Fully Reserved

If you have a tier-disabled VM, you should strongly consider setting “Reserve all guest memory (All locked)” or reserving the full memory amount for that VM.

Here’s why: In a memory-tiered cluster, DRAM is intentionally kept scarce. When a tier-disabled VM says “I only want DRAM,” it’s already putting pressure on that resource. Now imagine it doesn’t have a full reservation. vSphere sees unreserved memory pages and, under host memory pressure, may start swapping those pages out to a swap file on storage. That will result in a significant performance decrease, and it’s entirely avoidable.

By checking “Reserve all guest memory,” you’re reserving all of the VM’s memory so the host can’t reclaim it through swapping, ballooning, or compression. Since this VM is tier-disabled, that memory comes from DRAM. Yes, it consumes your DRAM budget, but it protects the VM from swapping and keeps performance predictable. If this VM is important enough to be tier-disabled, it’s important enough to be fully reserved.

It’s also worth understanding why customers typically disable Memory Tiering on specific VMs in the first place. In most cases, the intent is to run a focused test, a controlled way to check how a particular workload performs with dedicated DRAM before making broader architectural decisions. That’s a completely valid approach.

What you do want to keep in mind is what happens to your overall tiering ratios as you start disabling and reserving VMs. The default Memory Tiering ratio is 1:1, meaning equal amounts of DRAM and NVMe available to the tiered pool. When you pull VMs out of that pool by disabling tiering, their memory must come from DRAM, drawing down the DRAM side without touching the NVMe side. The ratio shifts, and the remaining tiered VMs have less DRAM to work with.

Let’s make that concrete. Say you have a host with 512 GB DRAM and 512 GB NVMe, running four VMs at 256 GB each. That’s a balanced 1:1 ratio. Now you disable and fully reserve one of those VMs. That VM claims 256 GB of DRAM exclusively, leaving only 256 GB of DRAM for the remaining three VMs with Memory Tiering enabled against the full 512 GB of NVMe. Your effective ratio shifts from 1:1 to 1:2. Depending on the memory activity of those tiered VMs, that skew can create real pressure. Go in with eyes open about the downstream effect on your DRAM budget and keep active memory under 50% of total physical memory as a best practice.

Putting It All Together

The following scenarios help make this concrete.

Scenario A: Tier-Enabled VM with Full Reservation (reservation number set to max)

All 32 GB are reserved via the reservation number field. vSphere guarantees all memory is available. It can still come from DRAM or NVMe, and Memory Tiering is still in play.

Scenario B: Tier-Enabled VM with “Reserve all guest memory (All locked)” checked

Checking “All locked” simply reserves all of the VM’s memory, protecting it from swapping, ballooning, and compression. Memory Tiering is still in play, and those reserved pages can still be satisfied from either DRAM or NVMe. This is the right choice when you want a full reservation without typing the number manually.

Scenario C: Tier-Disabled VM with No Reservation

This is the risky one. All memory must come from DRAM, but nothing is guaranteed. Under host memory pressure, vSphere may swap this VM’s pages to disk. Avoid this configuration.

Scenario D: Tier-Disabled VM with Full Reservation (Recommended)

All memory must come from DRAM, and all memory is guaranteed. This is the safe, recommended configuration for any VM that has had tiering disabled, whether implicitly or explicitly. You’re consuming DRAM budget, but your VM is protected.

Scenario E: VM with Passthrough Device (Implicit Tier Disable + Pinning)

vSphere disables tiering automatically. The pages used by the passthrough device get pinned by the IOMMU at the hardware level. Setting “All locked” is strongly recommended to reserve the non-pinned portion of the VM’s memory footprint as well, protecting it from swapping, ballooning, and compression.

Final Thoughts

Memory reservation, Memory Tiering, and pinned memory are three separate but deeply connected concepts. The reservation (whether set by number or by “All locked”) tells vSphere how much to guarantee; tier status tells vSphere where that memory can come from; and pinned memory, which happens automatically with hardware passthrough, directly maps VM memory to physical DRAM and removes it from tiering entirely. Getting these three controls right is what separates a well-tuned Memory Tiered environment from one that creates unexpected pressure or performance surprises.

For most workloads, the default (tier-enabled with appropriate reservations) is exactly right. For VMs that need tiering disabled, pair that decision with a full memory reservation. It’s an easy setting to overlook and an expensive one to ignore when your host is under pressure.