Using a 90-Day Planning Horizon Correctly in VCF Operations

Cosmin Trif — Tue, 25 Aug 2026 00:00:00 +0000

A 90-day capacity goal can describe three different things in VCF Operations: past demand used by the projection, future warning lead time, or the future period considered by VM rightsizing. They are controlled separately.

This article replaces the earlier 90-day capacity procedure, which incorrectly treated Time Remaining thresholds as a historical lookback setting.

The Three Meanings of 90 Days

Planning question	Relevant control	What it does not control
Should the forecast consider up to 90 days of past demand?	Historical Data window, if that value is available in the installed build	Alert severity or procurement lead time
Should an alert become critical when exhaustion is projected within 90 days?	Time Remaining criticality thresholds	Historical lookback
Should Recommended Size cover demand projected across a 90-day future horizon?	The applicable Time Remaining warning/green threshold plus the documented 30-day extension	Past-data retention

Changing one row does not configure the other two.

What the Capacity Engine Actually Does

VCF Operations forecasts demand rather than simply averaging a fixed block of historical utilization. Current Broadcom guidance describes these behaviors:

Recent samples receive more weight through exponential decay.
Conservative risk uses the upper bound of the projection range.
Aggressive risk uses the mean of the upper and lower projection bounds.
Peak-focused mode incorporates peaks detected in historical demand and can be combined with either risk posture.
Business Hours limits the demand samples used for projection to the configured hours; it does not merely give those hours extra weight.
Capacity Remaining is based on a short forward projection, while Time Remaining estimates when demand will intersect usable capacity.
vSphere HA admission-control reservations reduce usable cluster capacity and can therefore change the result even when current utilization appears low.

These settings change the model’s behavior. None of them, by itself, means “use exactly 90 days of history.”

Before Changing a Policy

Identify the active policy on the exact cluster, VM group, or object you are evaluating.
Record the existing Capacity settings and take screenshots for the change record.
Confirm whether the object is using the Demand model, the optional Allocation model, or both. Do not add arbitrary allocation ratios to hide a Demand-based alert.
Check vSphere HA admission control before interpreting usable capacity as missing physical capacity.
Decide which 90-day outcome you actually need: historical evidence, alert lead time, VM sizing horizon, or a documented combination.

Clone an inherited policy when you need a separate production, non-production, cluster, or VM posture. Broadcom recommends separate VM policies when rightsizing settings should differ from higher-level capacity policies.

Goal 1: Use a 90-Day Future Alert Lead Time

If procurement must begin when capacity is projected to run out within a quarter, configure Time Remaining severity thresholds for that operational lead time.

For example, an organization might choose warning at 120 days and critical at 90 days so the earlier warning leaves a 30-day intake buffer. Those numbers are governance choices, not Broadcom defaults. Keep the thresholds in a logical order, document who owns each severity, and verify how the installed version labels warning, immediate, and critical.

This configuration means “alert us based on a future exhaustion date.” It does not mean the forecast reads only the last 90 days.

Goal 2: Use a 90-Day VM Recommended Size Horizon

Broadcom’s current rightsizing explanation states that Recommended Size considers the peak projected demand from now through 30 days beyond the Time Remaining threshold used by the policy. Its example uses a 30-day warning threshold and therefore produces a 60-day sizing horizon.

Under that documented rule, a 90-day Recommended Size horizon corresponds to a 60-day applicable threshold plus the 30-day extension:

60-day policy threshold + 30-day extension = 90-day sizing horizon

Do not set the threshold to 90 days and call the sizing horizon 90 days; that would extend the evaluated period to 120 days under the same rule. Because UI wording can differ by release, verify the resulting projection on a VM’s Capacity tab before applying the policy broadly.

Use a VM-specific policy if clusters need different Time Remaining severities. Select Conservative, Aggressive, and Peak Focused according to workload risk and peak behavior, not merely to force a preferred recommendation.

Goal 3: Consider 90 Days of Historical Demand

The Historical Data setting is the control associated with the model’s past-data window. Broadcom KB 437777 explicitly treats it separately from Time Remaining risk and gives an example of temporarily reducing a 30-day window to one day when an obsolete spike is distorting a forecast.

To request a 90-day historical window:

Go to Infrastructure Operations > Configurations > Policy Definition.
Edit or clone the policy that is active on the intended objects.
Open Capacity and unlock the inherited Historical Data setting if necessary.
Select 90 days only if the installed VCF Operations build exposes 90 days as a supported value.
Save the policy, confirm its object assignment and precedence, and record the effective value.

If the installed build does not offer a 90-day value, do not substitute a 90-day Time Remaining threshold and describe it as a lookback. Use 90-day historical charts or reports as supporting evidence, and confirm the supported forecasting-window choices for that release with Broadcom Support.

Historical-data retention is also separate. Retaining a metric for reporting does not guarantee that every retained sample is used by the current projection.

Correcting Anomalous History

Use the Capacity view’s Reset control when a known change or anomaly makes the current projection unrepresentative. Broadcom documents two relevant behaviors:

Selecting a new projection start date causes forecasting to use data from that point forward.
Selecting a start and end time for exclusion omits that interval from capacity planning and forecasting.

A reset does not delete the underlying historical metric data. Charts, reports, and retained time-series data remain available.

Do not assume an object maintenance schedule is a substitute for this exclusion workflow. Maintenance behavior is designed around monitoring and alert handling; use the capacity engine’s own reset or exclusion controls when the goal is to change forecasting input.

Recalculate and Validate

Capacity forecasting runs periodically, so a policy change may not appear after one five-minute collection cycle. Broadcom KB 437777 describes two supported validation paths:

For a global recalculation, go to Administration > Control Panel > Dynamic Thresholds and start recalculation during an approved window.
For a specific cluster, open its Capacity tab and use Reset only when changing the projection baseline is intended.

Then validate all of the following:

The expected policy is active on the target object.
The effective Historical Data value matches the approved setting.
Time Remaining severity changes at the intended future thresholds.
The Capacity chart shows the expected projection start point and any excluded interval.
VM Recommended Size uses the intended future horizon.
HA reservation and capacity buffers match the actual resilience design.
Demand and Allocation models are interpreted separately, with the more constrained model understood.

Test on a small object group before broad assignment. Keep the before-and-after values with the change record so a surprising forecast can be traced to a specific policy decision.

Rightsizing on Cosmin.us