Introduction

VM rightsizing is not just a “nice to have” — it is essential for maximizing infrastructure efficiency. Oversized VMs waste resources and cause CPU and memory contention across your cluster, while undersized VMs struggle inside the guest OS and bottleneck applications.

VMware Cloud Foundation addresses these challenges by providing AI-driven insights and automation to help you size VMs perfectly and keep your infrastructure optimized and workloads running smoothly.

Rightsizing vs. Reclamation — What is the Difference?

First, let us clear up a common confusion about the two as, sometimes, they are often used interchangeably since they both relate to capacity management.

• Rightsizing adjusts a VM’s allocated CPU or memory to match actual needs — scaling up if under-provisioned and scaling down if over-provisioned.
• Reclamation frees unused physical capacity by deleting idle VMs, clearing old snapshots, or removing orphaned disks.

Rightsizing focuses on performance; reclamation focuses on capacity.

This blog covers rightsizing — fine-tuning VMs for peak performance.

Getting Started: The Rightsizing Page

Navigate to the Capacity dropdown in VMware Cloud Foundation and select Optimize, then open the Rightsize page.

Figure – Access rightsizing recommendations from the Optimize dropdown.

This is your mission control for rightsizing where you can:

• Resize oversized and undersized VMs instantly (with hot-add enabled, no reboot needed)
• Schedule resizing for later.
• Exclude VMs from future scans.

This centralized interface lets you act quickly without switching tools.

Understanding Oversized and Undersized VMs

On the Rightsizing page, you can quickly see a table of oversized and undersized VMs by clicking on the appropriate tab.

You can:

• Select one or more oversized or undersized VMs and resize them directly in VMware Cloud Foundation.
• Schedule for resizing off-hours.
• Exclude VMs from notifications (individually or in bulk using filters)

Figure – Select Oversized or Undersized VMs to take action.

When you select an oversized or undersized VM, VMware Cloud Foundation will also provide rationale to support its rightsizing recommendation.

Figure – Get rightsizing rationale for each recommendation.

Capacity Projections for VMs

The capacity engine built into VMware Cloud Foundation leverages AI/ML technologies to create forward-looking projections of the future utilization of VMs. The projections are updated every collection cycle, which is every 5 minutes, by default.

Those projections are used to determine the Recommended Size of VMs. The recommendations are not simply based on the historical utilization of the VM. Details on how recommended size is projected, and the configuration settings are covered later in this blog.

When reviewing capacity projections for VMs, you should look at 6 months (or more) of historical data, as there could be some historical demand or usable capacity changes that impact the projections.

For VMs, there are three different projections generated. They are Time Remaining, Capacity Remaining, and Recommended Size. You can view these projections on the capacity tab of any virtual machine object. The capacity projections for VMs are based on demand, which is what usage would have been if there was no contention.

Specifically, the metrics that represent demand are:

• CPU|Demand (MHz): This represents what CPU usage would have been if there was no contention like ready, co-stop, or hyper-threading.
• Memory|Utilization (KB): Memory usage as seen from inside the guest OS, which also accounts for guest memory swapping/paging.

Time Remaining is the projected number of days until the VM will run out of capacity. Time Remaining is an important concept for rightsizing because you do not want to get to a situation where you have 0 days of capacity remaining.

Figure – See how much time is remaining and be proactive before capacity runs out.

Capacity Remaining is the minimum capacity left projected three days in the future. It is important to understand that Capacity Remaining is not just free resources, it is based on a projection 3 days in the future.

Figure – Recommended VM size is based on forward-looking projections.

Recommended Size is the recommendation size from the capacity projections. This is the value that is converted vCPUs and GB of memory to change on the VM that is shown on the Rightsizing page mentioned in the previous section.

What sets the rightsizing recommendations from VMware Cloud Foundation apart from other solutions is that it is based on forward-looking projections. This means it accounts for projected growth, unlike other solutions that only look at historical usage. The methods used to project the recommended size for VMs will be covered later in this blog post.

What is important to understand with rightsizing recommendations is how it relates to the capacity projections and that you can view those capacity projections on the capacity tab of the VM. If you are looking for evidence to justify rightsizing recommendations, the capacity tab of the VM is a great place to start.

One Dashboard for All the Evidence You Need

While the Rightsizing page is a great place to view oversized and undersized VMs and the capacity tab to see capacity projections, there are additional questions related to rightsizing that need to be answered.

The VM Rightsizing Details dashboard is designed to answer the big questions:

• How much capacity will we free up?
• What’s the potential cost savings?

It is a great out-of-the-box tool to leverage in a conversation with the owner of a VM to justify their approval to rightsize a VM.

Figure – The VM Rightsizing Details dashboard provides an overview of the rightsizing recommendations for Undersized VMs and Oversized VMs.

There is a lot of information on the VM Rightsizing Details dashboard, but the most notable are the reclaimable capacity and potential cost impact due to rightsizing. There are nuances to reclaimable capacity, due to rightsizing, which can be counterintuitive because it is the amount of physical resources freed due to rightsizing, not the change in resources allocated to the VM.

Reclaimable capacity is what drives the potential cost impact of rightsizing. Check out the Reclaimable Capacity and Potential Cost Impact sections below to learn more about how they are determined.

Rightsizing Reports

If you prefer reports, there are two out of the box reports called Optimization Report – Oversized Virtual Machines and Optimization Report – Undersized Virtual Machines related to rightsizing. These reports can generate CSV or PDF, and reports can be run on demand or scheduled for delivery as an email. There is also the option to create custom reports if you are looking for other information not included in the out-of-the-box reports.

Figure – Generate rightsizing reports that can be shared with your extended team.

Acting on Rightsizing Recommendations

Now that we know which VMs need to be rightsized, you can correct in the way that best fits your processes:

1. Manual: Select and resize VMs directly on the Rightsizing page.
2. Scheduled: Plan resizing jobs for off-hours with job naming and timing options. Jobs appear in Automation Central alongside other automated tasks.
3. Custom Actions: Use alerts and webhooks or integrate with VMware Aria Automation Orchestrator for automated workflows triggered by oversize/undersize alerts.

Let us look at each one in more detail.

The Manual Approach

On the rightsizing page, you can manually initiate the process. All you need to do is select one or more VMs and click Resize VM(s). Once a VM is selected, you have a chance to accept the recommendations or modify them as you see fit. The Rightsize VM(s) action performed from the Rightsizing page is performed directly in vCenter.

Figure – Manually rightsize VMs directly within VMware Cloud Foundation.

Figure – Make adjustments to rightsizing recommendations befrore committing.

The Scheduled Approach

The other option on the Rightsizing page is to select Schedule Action, which as the name suggests, allows you to schedule rightsizing to occur at a future time.

Figure – Automate rightsizing using the Schedule Action button.

Once the VMs have been selected with this option, simply give the action a Job Name and define the date and time that you would like the rightsizing to occur.

Figure – Define when automatic rightszing will occur.

Once the job has been created, it will appear in Automation Central, along with any other jobs that you have automated, such as Bill Generation.

Figure – Use Automation Central to see all of your scheduled jobs, including rightsizing.

The Custom Approach

Another option is to create an alert notification that calls a webhook. Webhooks are a generic way to call various first and third-party systems. Once you have a system that can receive the webhook, you can run any action that the receiving system is capable to do.

Here is an example of a customer alert based on Summary|Is Oversized ==1 or Summary|Is Undersized ==1. Now that you have an alert, you have to decide what you want to call when a VM is identified as oversized or undersized.

Figure – Create custom rightsizing alerts based on your needs.

Finetuning Rightsizing Recommendations

How Projections are Made

Now that we have seen how rightsizing works in the UI and how you can act on the rightsizing recommendations, let us look at how VMware Cloud Foundation projects the recommended size for VMs and see which settings can be finetuned.

The capacity engine built into VMware Cloud Foundation leverages AI/ML technologies to create forward-looking projections of the future utilization of VMs. It is those projections that are used to determine the Recommended Size of VMs. The recommendations are not simply based on the historical utilization of the VM.

The settings that control rightsizing are available in policies.

Some of the policy settings affect all object types, so if you want different settings for VMs than other objects, like clusters, the best practice is to make a separate policy for your VMs.

Key Policy Settings

• Time Remaining Criticality Threshold: Controls warning levels for Time Remaining (default: 30 days warning, 10 days critical). Also influences how far into the future Recommended Size is projected (default 60 days). Set this based on your rightsizing frequency.
• Risk Level Configurations: Choose between Conservative (default, for production), Aggressive (for non-critical workloads), and Peak Focused modes.
  • Conservative: Uses upper bound of projection range for sizing.
  • Aggressive: Uses mean of upper and lower bounds.
  • Peak Focused: Accounts for sporadic peaks in workload demand.
• Business Hours: Define hours (e.g., 8 AM–5 PM Mon-Fri) to focus capacity management only during business times, ignoring after-hours activities like backups or scans. Multiple policies allow different business hours per VM group.
• Recommended Size Limits: Caps prevent drastic changes—oversized VMs capped at 50% reduction, undersized capped at 100% increase—to encourage gradual adjustment.
• Historical Data & Exponential Decay: Recent data points weighted higher to adapt quickly to changes.
• Peaks: Projections consider momentary, sustained, and periodic peaks differently to reflect realistic workload patterns.

Let us take a look at each one in more detail.

Time Remaining Criticality Threshold

Time Remaining is when the VMs demand is projected to exceed the total capacity of the VM in days. Time Remaining Criticality Threshold controls when the system will flag Time Remaining as being in warning, immediate, or critical to give you a proactive warning before the VM runs out of capacity. The default is 30 days for yellow (warning) and 10 days for red (critical).

Time Remaining Criticality Threshold is also used to control how much of the projected demand to consider when projecting the Recommended Size. Recommended Size is determined by considering the peak projected demand between now and 30 days beyond the Time Remaining Criticality Threshold. Since the default warning threshold is 30 days, that means Recommended Size also defaults to 60 days in the future (30 days from Time Remaining Criticality Threshold + 30 days).

To determine the appropriate values for Time Remaining Criticality Threshold, consider how often you plan to rightsize your VMs and set it to a value that gives you enough lead time to rightsize the VMs.

Figure – Define how many days you have until the utilization projection crosses the usable capacity threshold.

Risk Level Configurations

You can set the risk level for the time that is remaining when the forecasted total need of a metric reaches usable capacity. Click the lock icon to override the settings and change the thresholds for your policy.

Once unlocked, you can select how Aggressive or Conservative the projections will be, as well as factor in Peaks, by selecting the radio buttons on the scale.

Let us take a look at Conservative, Aggressive, and Peaks in more detail.

Conservative Setting

Use this option for production and mission-critical workloads.

Figure – Risk Levels can be defined on an Agressive to Conservative scale.

By selecting a more Conservative Risk Level, Time Remaining will be determined by looking at the intersection of the upper bound of the projection range and the Usable Capacity of the VM.

To project the Recommended Size with the Conservative setting, the upper bound of the projection range is used in conjunction with the Time Remaining Criticality Threshold + 30 days (as mentioned in the previous section). The peak of the projection within that time range becomes the Recommended Size for the VM.

Figure – Conservative is recommended for critical environments such as production or business-critical applications.

Aggressive

By selecting a more Aggressive Risk Level configuration, Time Remaining will be determined by looking at the intersection of the mean of the upper and lower bound of the projection range and the Usable Capacity of the VM.

To project the Recommended Size with the Aggressive setting, the mean of the upper and lower bounds of the projection range is used in conjunction with the Time Remaining Criticality Threshold + 30 days (as mentioned in the previous section). The peak of the projection within that time range becomes the Recommended Size for the VM.

Figure – Aggressive is ideal for for less critical environments such as development, UAT, or test.

Peak focused

Enabling peak focused mode causes the capacity engine to create projections using the peaks that have been identified in the historical demand. Peak focused mode is supported with both Conservative and Aggressive risk levels.

Figure – Peak focused mode works best for workloads that have sporadic peaks.

Business Hours

Some customers prefer to do capacity management for some workloads based on a portion of the day and to effectively ignore the rest of the day. An example of this would be to concentrate on the hours of the day the business is open and ignore after-hours when backups, patching or AV scans typically run. In VMware Cloud Foundation, this is called business hours. You can configure it to be 8 AM – 5 PM, Monday through Friday, which will only use demand during those business hours to create the projections.

If you need different business hours for different VMs, you can create multiple policies with different business hours per policy. You have the option to use policies to apply different business hours to VMs for rightsizing versus clusters for capacity management. Changes to business hours will cause the projection, including rightsizing recommendations, to be updated to reflect the newly configured business hours.

Figure – Define Business Hour to get more accurate rightsizing recommendatios.

Recommended Size Limits

Customers are often reluctant to make substantial changes to VMs and are looking for a more conservative approach. Recommended Size has been designed to be conservative in its recommendations as well.

Recommended Size for oversized VMs is capped at 50% of the current configuration while Recommended Size for undersized VMs is capped at 100% of the current configuration. This helps to gradually guide VMs to the Recommended Size without recommending substantial changes like 32 vCPUs down to 1 vCPU.

Recommended Size Metrics

There are eight key metrics related to rightsizing VMs to be aware of. You can use these metrics to create custom dashboards, views, and reports.

• Capacity Analytics Generated|CPU|Recommended Size (MHz): The recommended amount of CPU Usable Capacity in MHz needed to maintain a green state for the entire time between now and the Green Time Remaining Score Threshold set in the policy + 30 Days.
• Capacity Analytics Generated|Memory|Recommended Size (KB): The recommended amount of Memory Usable Capacity in KB needed to maintain a green state for the entire time between now and the Green Time Remaining Score Threshold set in the policy + 30 Days.
• Summary|Is Oversized: If a VM is detected to be oversized for at least one resource type (CPU or Memory), the value will be set to 1. Otherwise, the value will be 0.
• Summary|Is Undersized: If a VM is detected to be undersized for at least one resource type (CPU or Memory), the value will be set to 1. Otherwise, the value will be 0.
• Summary|Oversized|Virtual CPUs: The recommended number of vCPUs to remove from an oversized VM.
• Summary|Oversized|Memory (KB): The recommended amount of memory in KB to remove from an oversized VM.
• Summary|Undersized|Virtual CPUs: The recommended number of vCPUs to add to an undersized VM.
• Summary|Undersized|Memory (KB): The recommended amount of memory in KB to add to an undersized VM.

Historical Data

The capacity projection start date is determined by the data collection frequency and the projection window. The capacity engine projects capacity based on historical data, typically consuming data points every 5 minutes. The projection window extends one year into the future. The start date for the projection is essentially the point from which the capacity engine begins analyzing historical data to forecast future capacity needs.

It is possible to reset the projection calculation starting point. Please see the Reset Capacity Projections section below for more details.

Figure – The capacity projection start date is determined by the data collection frequency and the projection window.

Exponential Decay

Exponential Decay gives higher weight to recent data points to allow the projection to react more quickly to recent changes in utilization.

Peaks

As you know, most workloads do not follow a straight line for utilization. There can be various peaks in utilization over time that need to be accounted for in the projections. The impact of a peak on the projection is relative to the peaks’ duration, height, and frequency. Remember this is a projection created by the AI/ML powered capacity engine, so there is not a specific formula that can doublecheck the math.

If you are taking historical utilization into consideration, ask yourself if the peak looks significant enough to affect capacity planning and are there enough peaks that appear to follow a periodic pattern(s). If so, you should see the impact of those peaks on the projections. In general, the more important the peak(s) look, the more impact the peak(s) has on the projection.

• Momentary peaks that are short-lived and might be one-offs. These are the peaks that you would dismiss for capacity planning purposes because they do not appear important. In general, small and short-lived peaks should have minimal impact on capacity planning and therefore have minimal impact on the projection.
  
• Sustained peaks last for a longer time and do impact projections. If the peak is not periodic, the impact on the projection lessens over time due to exponential decay.
  
• Periodic peaks exhibit cyclical patterns or waves. For example, hourly, daily, weekly, monthly, and last day of the month. There can be multiple overlapping cyclical patterns, which will also be detected.
  

Reset Capacity Projections

Significant changes in demand or capacity may skew projections temporarily. You can reset projections from any date and exclude anomalous time ranges to recalibrate forecasts immediately by clicking the Reset Button.

Figure – Use the Reset Button to adjust Start Date.

Once you reset capacity calculations, you will notice that the Projection Calculation Start point on the capacity charts will reflect the date that you selected. Capacity projections will start from that day forward.

The screenshot below shows the impact of restarting capacity calculations from August 6th, 2025, because there was a notable change in demand on August 5th, 2025.

Figure – When a start and end time is chosen for exclusion, the selected time interval will not be considered for capacity planning and forecasting.

Capacity Models for Clusters

So far, everything we have looked at applies to the VM level. The remaining topics bring that viewpoint up to the cluster level and higher. When managing capacity at a cluster level, there are two different capacity models that can be used, called demand model and allocation model. The reason the capacity model for a cluster is important for rightsizing is that quantification of reclaimable capacity and potential cost impact are both dependent on the capacity model used for the parent cluster, not the VM.

Demand Model for Clusters (Default)

Demand model looks at what usage would have been if there was no contention. For CPU demand, examples of contention are ready, co-stop, hyperthreading, and frequency scaling. For memory demand, example of contention is paging or swapping, but more specifically swap/page in. Demand model for a cluster is always active and looks at the aggregate demand of all VMs in the cluster to determine the cluster’s capacity.

Reclaimable Capacity for Demand Model

If you are ever asked to quantify the overall impact on capacity if all VMs are rightsized when using the demand model, be sure to leverage the VM Rightsizing Details dashboard mentioned above.

The key part to understanding reclaimable capacity, when the parent cluster is using demand model, is that the change to cluster capacity does not always correlate with the change in configured resources for the VM.

These reclaimable capacity metrics apply to VMs running in clusters running with demand model only.

• Summary|Oversized|Potential Memory (GB): An oversized VM can have reclaimable memory only if consumed memory is greater than the new recommended size of the VM. The reclaimable memory capacity is the difference between consumed memory and recommended size.
• Summary|Undersized|Potential CPU Usage (GHz): CPU Usage of a VM of an undersized VM is expected to be the current CPU Demand. The difference between CPU Demand and CPU Usage is the expected increase in capacity utilized after rightsizing.
• Summary|Undersized|Potential Memory (GB): It can be expected for consumed memory to increase by the same amount of memory recommended to add to an undersized VM.

You may have noticed that CPU for oversized VMs has not been mentioned so far. If an oversized VM’s CPU usage is 100MHz before rightsizing, removing vCPUs will not change its CPU usage so the VM should have usage of 100MHz after rightsizing. This means there is no reclaimable capacity associated with the overallocation of vCPUs. Reclaimable CPU Usage for oversized VMs will always be 0 MHz regardless of how many vCPUs are recommended to remove.

Allocation Model for Clusters (Optional)

Unlike demand model, allocation model is optional. Enabling allocation model involves defining overcommit ratios such as 8:1 vCPU:Core. With allocation model, the utilization or demand of the workloads is not considered. It looks at the aggregate of resources provisioned or configured to VMs compared to the overcommit ratios defined.

Potential Cost Impact on the Demand and Allocation Model

Calculating the potential cost can be utilization or allocation based, depending on whether allocation model is enabled for capacity.

If you are ever asked to quantify the potential cost impact of rightsizing, you can leverage the VM Rightsizing Details dashboard mentioned above.

Demand Model

Demand model can cause some confusion when looking at cost impact because demand model is looking at the physical resources used by the VM, not the resources configured on the VM. What is important to understand is that the cost impact is determined using the reclaimable capacity mentioned in the previous section and the CPU and memory base rates for the parent cluster or host.

Allocation Model

The Allocation Model is what most customers tend to think of when looking at the cost impact of rightsizing. Since the Allocation Model is based on the resources configured on a VM rather than the physical resources used by a VM, the cost impact is determined using the recommended CPU and memory changes and the allocation model CPU and memory base rates for the parent cluster or host.

Cost Impact Metrics

Cost|Potential Savings: This metric contains all the potential savings opportunities for the VM. This can be from being oversized or reclaimable from being powered off, idle, or having old snapshots. If allocation model is enabled, potential savings will be based on allocation model. Otherwise, it will be based on demand model.

Cost|Potential Cost Increase: This metric shows the potential cost increase from rightsizing the VM if it is undersized. If allocation model is enabled, potential cost increase will be based on allocation model. Otherwise, it will be based on demand model.

Final Thoughts

Rightsizing with VMware Cloud Foundation is about more than saving capacity — it is about:

• Improving application performance
• Avoiding costly resource contention
• Freeing up budget for innovation instead of over-provisioning

With AI-driven insights, multiple actionable paths, and clear cost impact reporting, you can rightsize with confidence — and keep your infrastructure running like a well-tuned engine.