TL;DR · Key Takeaways
- The cheapest hosts you will ever add are the ones you already own and are wasting.
- VCF Operations points at four kinds of waste: old snapshots, orphaned disks, dead VMs, and oversized VMs.
- Cleaning up snapshots, orphaned disks and dead VMs is mostly safe.
- Rightsizing holds the real savings and the real risk, so do not apply a recommendation without checking the workload first.
Walk any environment that has been running a few years and you will find the same clutter. VMs nobody remembered to delete. Disks left behind by a migration that half-finished. Snapshots taken for a patch in 2023 that are still growing. And a fleet of machines sized like the physical servers they replaced, because that felt safe at the time. Part 6 showed you this as reclaimable capacity on the capacity page. Part 8 showed you it as money on the cost report. This part is where you actually go and get it back.
Where the waste is
VCF Operations groups reclaimable resources into a few buckets, and they are not equally scary to clean up. Powered-off VMs, orphaned disks and stale snapshots are usually easy wins. Idle-but-running VMs need a quick word with whoever owns them. Oversized VMs need rightsizing, which is the most valuable category and the one you have to be careful with, because you are changing a machine that is live. I read the list as three tiers of risk, not one pile to blitz on a Friday afternoon.
| Category | What it is | Risk |
|---|---|---|
| Old snapshots | Snapshots kept long past their purpose | Low: consolidate |
| Orphaned disks | VMDKs no VM references | Low: verify, then remove |
| Powered-off VMs | Off for a long time, still on storage | Medium: confirm owner |
| Idle and oversized VMs | Running but barely used, or over-allocated | Higher: rightsize with care |
Start with old snapshots
If you only do one thing after reading this, go hunt down old snapshots. People treat a snapshot like a backup. It is not. It is a delta file that keeps growing, and the longer it lives the more storage it eats and the slower it makes the VM underneath it. I have seen a snapshot taken for a ten-minute patch grow bigger than the base disk over a year, quietly filling a datastore nobody was watching. VCF Operations lists them for you, and once you have checked that nobody is mid-change, they are almost always safe to consolidate. Best return for the least risk anywhere in the product.
Orphaned disks are the next easy one. These are VMDK files that no live VM points at any more, left behind when a deletion or a migration went sideways. They just sit on storage doing nothing. Confirm they are genuinely unreferenced, make sure one of them is not somebody quiet manual backup, and remove them. Between snapshots and orphaned disks, most sites claw back a good chunk of storage before they touch a single running machine.
Powered-off VMs are the third of the easy wins, with one wrinkle worth naming. A machine that has been off for ninety days is probably dead. Occasionally it is not: it is the seasonal box someone powers on once a year, or a licensing appliance, or a rollback target kept on purpose. This is exactly why the routine further down has a verify step. The platform can tell you a VM has been off for months; only the owner knows whether that was neglect or a plan. Reclaim a machine that was off deliberately and you make the whole team nervous about the next cleanup, and nervous teams stop cleaning up, which is how the clutter creeps back.
Rightsizing: cut CPU freely, memory with care
Rightsizing means matching a VM vCPU and memory to what it really uses, and VCF Operations works out the recommendation from demand history. Nearly all the savings are in cutting, because people size VMs the way they used to size physical boxes they could not easily change later, so they pad. Trimming vCPUs comes with a bonus you saw in Part 7: fewer vCPUs means less co-stop, so the VM often runs faster after you shrink it. That one is rare and satisfying, a change that saves money and speeds up the workload at the same time.
Memory deserves respect. A recommendation is only as good as the window behind it, so before you apply a memory cut, widen the history until it covers the workload real cycle, month-end, quarter-end, whatever peak it actually has, and leave room above the peak rather than the average. Apply it in a change window and watch ballooning and swap afterwards, the same contention signals from Part 7. Rightsizing is not a batch job you run once and forget. It is a recommendation you look at, agree with or overrule, apply, and then check.
There is an upsizing side people forget too. Now and then a VM is genuinely starved and the recommendation is to give it more. Those are easy to approve, nobody argues with making their app faster, but they matter for a subtler reason. If the tool only ever shrinks things, app owners learn to distrust it and pad every request to defend themselves, which recreates the oversizing you were trying to kill. Show that the system also asks for increases when the data backs it, and your downsizing recommendations start getting accepted, because the tool looks fair instead of like a budget axe.
Honestly, half of rightsizing is the conversation. The change itself is a couple of clicks. The hard part is talking to the owner who set their VM to 16 vCPUs because that felt safe. Bring the evidence, show the real demand over a full cycle, and frame a CPU cut as a speed-up where co-stop is in play, not as taking something away. Offer to revert if the numbers move, and mean it, because one forced downsizing that goes wrong poisons every recommendation after it. The teams that rightsize well made it a collaboration. The ones that pushed changes through spent the next month in the ticket queue.
A monthly routine that sticks
A one-off cleanup feels good and fixes nothing, because the waste grows straight back. What actually moves the number for good is a small loop you run every month: identify, verify, act, record. Identify from the reclaimable list. Verify with the owner or the evidence, because the platform can flag an idle VM but only a person knows it is the DR box that is meant to sit quiet. Act in the right change window. Record the saving against the specific things you removed, so the work is visible and the next month is trusted. Skip verify and you will eventually delete something that mattered. Skip record and nobody will believe the effort was worth it.
Stop making the mess
The best cleanup is the waste that never happens. Look at what you reclaim each month and it is usually the same three habits: snapshots with no expiry, VMs deployed from oversized templates, and machines powered off with no plan to delete them. Fix the source and the monthly pass shrinks on its own. Put a lifetime on snapshots so old ones get flagged automatically. Trim the templates people deploy from, because a template that ships with 8 vCPUs breeds a whole fleet of 8-vCPU VMs that never needed them. Give powered-off VMs an expiry date the day they are created. A team that only reclaims is bailing water. One that also fixes the templates and the policies is patching the hull.
It shows up in capacity and cost
All of this loops back to the last two parts. The capacity page from Part 6 is where reclaimed capacity turns into longer time remaining. The cost view from Part 8 is where it turns into a lower bill and a saving you can name. That is what makes reclamation the highest-value routine an ops team has: one monthly pass improves the capacity forecast and the cost report at once, using kit you already own, with no purchase order and no downtime for the safe categories. When leadership asks what your team did for the budget this quarter, a reclamation log with named resources and a moved capacity number is about the cleanest answer you can hand them.
A cluster is short on memory time remaining, and someone has already drafted a PO for two hosts. Before it goes out, you work the reclaimable list. Snapshots: 40 old ones across the cluster, consolidating them gives back 3 TB and clears two datastore alarms. Orphaned disks: another 1.2 TB. Powered-off VMs: 15 machines off for over 90 days, and the owners confirm 11 can go. Rightsizing: 30 oversized VMs, where trimming CPU alone frees scheduling headroom and careful memory cuts on the safe ones hand back a good slice of RAM. Add it up and memory time remaining goes from weeks back to months. The two-host purchase gets deferred a full quarter, and you report the saving tied to the exact snapshots, disks and VMs you retired, so next quarter is easy to justify.
Common questions
Can I just auto-apply the rightsizing recommendations?
Not blindly. They come from demand history, and history can miss a seasonal or spiky peak. Auto-apply is fine for CPU downsizing on workloads you understand well. For memory, review it and apply in a change window.
Why would removing vCPUs make a VM faster?
A multi-vCPU VM has to co-schedule all its vCPUs at once, so idle ones cause co-stop while the scheduler waits to line them up. Drop the count on an over-provisioned VM and that waiting drops with it. Cheaper and quicker in one move.
What is the single biggest quick win?
Old snapshots. They eat storage, grow without limit, and drag on the VM, and they are almost always safe to consolidate once you have checked nothing is mid-change. Go there first.
How do I prove the cleanup was worth it?
Report the saving against the exact snapshots, disks and VMs you removed, and show the time-remaining move on the clusters you touched. Named actions plus a number that moved is the proof that funds the next pass.
Where this leads
Reclamation is really just the discipline of not wasting what you already bought. Clear the safe three every month, cut CPU freely and memory carefully, and write down the saving so the habit compounds. If you take one thing from this part, make it the monthly loop with a verify step and a recorded number, because a cleanup done once is a story and a cleanup done every month is a capability. Next we swap efficiency for safety and look at configuration compliance and drift, keeping the fleet inside the lines it is supposed to stay in.
By the numbers: what one cleanup pass gave back
A single reclamation sweep across one cluster.
| Waste type | Found | Recoverable | Note |
|---|---|---|---|
| Old snapshots | 40 | 3 TB | clears two datastore alarms |
| Orphaned disks | several | 1.2 TB | verify no VM references first |
| Powered-off VMs | 15 (off over 90 days) | 11 removable | owners confirmed |
| Oversized VMs | varies | CPU and RAM back | rightsize with care |
« Previous: Part 8 | VCF 9 Operations Complete Guide | Next: Part 10 »
References
- Using Rightsize to Adjust Resource Allocation, VCF 9.0 (Broadcom TechDocs)
- Using the Capacity Page to Assess and Optimize Capacity, VCF 9.0 (Broadcom TechDocs)
- Rightsizing VMs with VMware Cloud Foundation (VCF Blog)
About The Author
DrJha