VCF Operations rightsizing: oversized VMs, reclaim and what to check before you resize

How VCF Operations rightsizing works

VCF Operations rightsizing compares each VM’s projected demand with what it has allocated and lists the VMs that are oversized or undersized for CPU or memory, with a suggested vCPU and memory size for each. A second view, Reclaim, lists capacity you can take back without resizing anything: idle VMs, powered-off VMs, snapshots and orphaned disks. In VCF Operations 9.1 you open both from Manage in the top bar, then Capacity and Optimize in the left pane; click a data centre and choose the Rightsize or Reclaim tab.

VCF Operations is the 9.x name of the product known before as Aria Operations and vRealize Operations (vROps). This guide follows the 9.1 TechDocs pages, updated between 21 September and 15 October 2026. Broadcom’s feature comparison for VCF and VVF 9.1.1, dated 14 October 2026, marks cost management with reclamation for vSphere Foundation, VCF Edge and VCF. Its row for predictive capacity management, including rightsizing, carries two marks, as does the row for lifecycle management, which the table says VVF customers handle with vLCM. On vSphere Foundation, have the entitlement confirmed in writing.

Which VMs waste capacity, and why snapshots come first, is in our guide to where the waste is in a vSphere estate.

How the capacity engine calculates a recommendation

Broadcom’s page on calculating and forecasting capacity, updated 15 October 2026, says the engine “collects data points every five minutes and processes them once in 24 hours to calculate output metrics.” By default it works on the demand model; the allocation model, with its overcommit ratios, applies only when you turn it on in the policy. The projection is a range that, in Broadcom’s words, “covers 90% of the future data points”.

The engine treats peaks in three ways. A momentary peak is a one-time event and does not change the projection. A sustained peak changes it, and its weight fades over time unless it recurs. A periodic peak, such as a daily backup or a month-end run, does not decay and weighs most. You can move the start of the history or exclude up to six time periods, such as a migration that distorted the data.

The recommended size is “The maximum projected utilization for the period from now to 30 days beyond the time remaining warning threshold.” With the default warning threshold of 120 days, that is the highest projected utilisation over the next 150 days. The policy’s risk level decides which edge of the range counts. Conservative uses the upper bound, and the policy page recommends it “for production and mission-critical workloads” and “for VMs with utilization spikes”. Aggressive uses the mean of the upper and lower bounds and is meant for non-critical workloads. It is a slider on the policy’s Capacity card, under Operate, Administration, Configurations and the Policy Definition tile.

Two caps limit each recommendation. “VCF Operations caps an oversized recommended size at 50% of the currently allocated resources”, so a reduction takes away at most half, and it caps an undersized one at 100%, so an increase adds at most the current allocation. A VM with 16 vCPU that peaks at three therefore gets a recommendation of no fewer than 8 vCPU, and it reaches its right size over several rounds. VMware’s VCF blog advised on 12 August 2025 to review “6 months (or more) of historical data” before relying on the projections.

What the Rightsize and Reclaim tabs show

The Rightsize tab has two lists, Oversized VMs and Undersized VMs, grouped by cluster, with the suggested change in vCPU and GB of memory. Expanding a VM shows its utilisation history over one to 12 months, the projection and the recommendation. Both lists include idle VMs and VMs with snapshots, so a VM can appear in Rightsize and in Reclaim at once. The Reclaim tab sorts its candidates into four categories.

Broadcom TechDocs, VCF Operations 9.1: Calculating and Forecasting Capacity (15 October 2026), Using Rightsize to Adjust Resource Allocation and Using Reclaim to Free Up Resources (15 October 2026); Broadcom KB 438023 and KB 445643.

Broadcom’s KB 445643, written for Aria Operations, defines an idle VM as one whose “CPU consumption is less than 100 MHz for 100% of the time during each 24-hour period”, and says of the vCLS VMs that DRS and HA need, “Do not reclaim or delete these VMs”. In 9.1, Reclamation Settings open from the gear icon next to the page heading and apply to all data centres; age-based exclusions are under Operate, Administration, Global Settings.

The panes Total Reclaimable Capacity and How much you can potentially save convert the lists into capacity and cost. The cost comes from the cost drivers, whose reference costs Broadcom says “might not be accurate” until you enter your own; how to set them is in our guide to VMware cost per VM and showback.

What to check before you apply a recommendation

These checks catch cases where a correct demand projection still gives a wrong size.

Broadcom KB 438023 (ESXi 8.0 rightsizing guidance) and KB 321931 (vNUMA and vCPU hotplug, ESXi 7.x and 8.x); other rows are our checklist.

For memory, KB 438023 compares active and consumed memory with the allocation: “A consistently low active-to-allocated ratio suggests oversizing.” Non-zero ballooning means the host has reclaimed memory from the guest, and “Active in-guest paging suggests the VM itself is undersized for its workload.” A memory cut on a host that already balloons or swaps makes the pressure worse, as our guide to vSphere memory overcommit, ballooning and swapping explains.

On the CPU side, KB 438023 calls co-stop below about 3% per vCPU normal and reads sustained higher values as more vCPUs than the VM can use. It also warns that “Sustained high ready time generally signals CPU contention at the host level rather than undersizing of the individual VM.” For an undersized VM with high ready time, read ready and co-stop per vCPU as our CPU ready guide describes.

KB 321931 says CPU Hot Add disables vNUMA on virtual hardware version 19 or earlier and advises disabling it in production VM templates “unless online resource resizing is a strictly validated operational requirement”; KB 438023 adds that from hardware version 20 on ESXi 8.0, vNUMA is preserved with CPU Hot Add enabled. VMware’s VCF blog of 12 August 2025 describes resizing “with hot-add enabled, no reboot needed”, but hot add only increases a VM, and KB 438023 states that “Changes to vCPU count, memory size, or CPU topology require the VM to be powered down.” Plan every resize for a maintenance window.

Under VMware optimisation, our engineering partner Vixen.UNO audits the estate’s actual resource usage and makes changes in agreed maintenance windows with a rollback plan. Send us the Rightsize export for one cluster and the business peaks it may not show.

Applying rightsizing in maintenance windows

Resizing from VCF Operations needs one setting in advance: “Operational Actions must be activated in the vCenter cloud adapter instance.” The Resize VM(s) workspace proposes the vCPU and memory change for each selected VM, and you can edit each value before you run it. Broadcom has you tick a box confirming that “because workloads must restart to accommodate resizing, some work may be interrupted.” Schedule Action runs the same change later, as a job managed in Automation Central.

1. Export the lists with Export All and record each VM’s current vCPU and memory; these values are your rollback.
2. Send each owner the history and recommendation for their VMs, and exclude the VMs they reject, with tags where a whole application is affected.
3. Group the approved changes by maintenance window and change one dimension per VM per window, CPU or memory, so a complaint points to one change.
4. Run the resize from the Resize VM(s) workspace or schedule it with Schedule Action for the window.
5. After the restart, check the application, then ready and co-stop per vCPU and in-guest paging over the next business peak.
6. If the application degrades, restore the recorded values in an agreed window and exclude the VM until the owner has reviewed it.
7. Let VCF Operations collect a full business cycle before the next round, since one recommendation removes at most half of the allocation.

For orphaned disks, Broadcom’s 9.1 page says “You cannot reclaim orphaned disks from the UI”: export the list, check each reported VMDK and remove the confirmed ones manually. Idle and powered-off VMs go to their owners first; idle VMs are then powered off, and both are kept for a retention period before deletion.

Worked example: a 30-host cluster with 1,200 VMs

The figures are an illustration, not a client case. One cluster of 30 hosts, each with two 32-core CPUs and 1,024 GB of memory, gives 1,920 cores and 30,720 GB. It runs 1,200 VMs that allocate 6,000 vCPU and 26,400 GB, about 3.1 vCPU per core. The policy uses the Conservative risk level and six months of history.

Example values; caps and risk level as in Broadcom’s VCF Operations 9.1 page Calculating and Forecasting Capacity (15 October 2026).

The suggested changes stay within both caps. After one round, the cluster allocates 4,930 vCPU, about 2.6 per core, and 22,940 GB. Broadcom notes that the recommended size “does not include the capacity that vSphere HA reserves for failover”. Whether the cluster now needs fewer hosts depends on measured demand with one host down, HA admission control and, with vSAN, the host minimum of the storage policy, so the allocation figures are an input to host consolidation under per-core licensing rather than its result.

Reporting rightsized and reclaimed capacity

A report owners and finance accept shows each cluster before and after: allocated vCPU and GB, VMs changed, VMs excluded with the reason, and storage returned from snapshots, orphaned disks and retired VMs. Report allocation and measured demand side by side, because the host count follows demand.

Allocation-based showback rates per vCPU and per GB put the cost of an oversized VM on its owner, which gives owners a reason to accept the recommendation.

Rightsizing results feed the paid technical assessment of our VMware optimisation service, which delivers a report, a TCO and ROI model and an action plan ahead of renewal. Describe your clusters, VM count and renewal date in the form below.

What we do

Our VMware optimisation service starts with an estate and licence audit: versions, subscriptions, actual resource usage, risk profile and TCO, with options for action. Licence and cost optimisation matches editions and subscriptions to your actual workloads and covers host and cluster consolidation where the rightsized estate allows it. Engineering is delivered by our engineering partner Vixen.UNO, which makes all changes in agreed maintenance windows with a rollback plan at every stage and provides support under an agreed SLA. If there is nothing to optimise, we say so. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ