VMware updates their best practices guide with every vSphere release, but let’s be honest — most of it doesn’t change much. vSphere 9 is different. A few updates in here can actually influence how you design, run, and maintain your environment.
This isn’t just a feature list. These are the new or changed recommendations in vSphere 9 that matter, why they exist, and how you should approach them.
1. Advanced NVMe Memory Tiering — More Memory Without the DRAM Bill
Before vSphere 9, if you ran out of DRAM on a host, you either bought more DIMMs or lived with performance drops from swapping to slow storage. Neither was ideal — DIMMs are expensive and limited, and swap is painful.
Now, you can configure NVMe as a second tier of memory behind DRAM. NVMe isn’t as fast as DRAM, but it’s a huge jump from traditional swap space and gives you room to run bigger workloads or more VMs without an immediate hardware upgrade.
Best practice: Keep critical workloads in DRAM as much as possible. Use NVMe tiering for workloads that need the extra capacity but aren’t sensitive to a bit more latency. Watch hit/miss ratios to make sure tiering is actually helping.
2. New Snapshot Format — Less Pain During Backups and Maintenance
Snapshots have always had a cost. In older versions, long chains and consolidation could slow things down, sometimes enough to impact production workloads.
vSphere 9’s new snapshot format is faster to create and consolidate, with less I/O penalty — especially on vSAN and vVols. This makes snapshots less disruptive, but it’s not a free pass to keep them around forever.
Best practice: Keep snapshots short-lived. Even with the improvements, long chains still hurt. Use them for what they’re meant for — short rollback points — and consolidate quickly.
3. Lifecycle Manager Improvements — Faster Patching, Fewer Reboots
Image-based lifecycle management was a big step forward when it showed up, but it wasn’t perfect. Mixed hardware clusters and frequent reboots kept some shops from adopting it.
vSphere 9 fixes some of that. You can now manage multiple hardware profiles in the same cluster, remediate hosts in batches, and even apply some patches without a reboot. This means faster patch cycles and less downtime.
Best practice: If you’re still on baseline-based updates, start moving toward image-based lifecycle management. Take advantage of live patching where it works, but plan for reboots when kernel or hardware changes are involved.
4. GPU vMotion — Finally Fast Enough to Use
GPU vMotion has been around, but in earlier versions it was so slow it was easier to just schedule downtime. That’s not great when GPU workloads are growing — AI, ML, VDI — and you need flexibility.
In vSphere 9, GPU vMotion is up to six times faster. That makes it practical to migrate GPU-backed workloads during normal maintenance or for load balancing without taking them offline for hours.
Best practice: If you’re running NVIDIA vGPU or similar, start including GPU vMotion in your regular maintenance plans. Just make sure your network can handle the data movement without becoming the bottleneck.
5. Monster VM Limits — Bigger Isn’t Always Better
The old limits — 768 vCPUs and 12 TB of RAM — were fine for most workloads. But some HPC, AI training, and massive database deployments need more.
vSphere 9 raises the ceiling to 960 vCPUs and 16 TB of RAM per VM. That means you can consolidate certain massive workloads into a single VM instead of spreading them across multiple.
Best practice: Only go this big when the workload demands it. Larger VMs mean a bigger blast radius if something fails, and they put more pressure on backup and restore times. Make sure your DR plan can handle it before you deploy.
Final Thoughts
These updates in vSphere 9 aren’t just “nice to know” — they’re worth planning around. Whether it’s squeezing more out of your hardware, reducing downtime, or finally making GPU migrations practical, the real value is in deciding where these changes fit your environment.
📄 VMware vSphere 9.0 Performance Best Practices Guide
Take a hard look at these changes, figure out which ones solve real problems for you, and make them part of your standard operating playbook.