Sizing tool

Ops & Logs Planning Sizer

A planning companion to Broadcom's VCF Operations Sizing Estimator. It covers what the estimator leaves out: what Log Management and Real-Time Metrics add to the VCF services runtime (worker nodes, IPs for the runtime block, ingestion VIPs), the Log Management host and VIP limits, and Cloud Proxies per location. It also gives a quick VCF Operations estimate that matches the estimator (compared 2026-10-14); use the estimator itself for the final node size. Rules, sources and where they disagree are in the companion guide. Take the sizes into the Management Domain sizer to check they fit your cluster. Everything runs in your browser; nothing is sent anywhere.

1. What you will monitor

ESX hosts vCenter instances Virtual machines Datastores

Other monitored objects

Everything else VCF Operations collects: NSX, vSAN, management packs, Kubernetes. An object is anything with its own properties and metrics, so each VM, host and datastore is one.

Known object count optional

If you already run VCF Operations (or Aria Operations), its real object count beats the estimate above. 0 uses the estimate.

Collected metrics optional

From an existing install: the sum of the adapter instances' metrics on Cluster Management. 0 estimates them at the official estimator's rates: 262 per VM, 292 per host, 230 per vCenter, 93 per datastore (other objects at the VM rate). Metrics often set the size before objects do.

Estimator buffer % Growth allowance %

The official estimator always adds 20% to objects and metrics, before growth. Growth also applies to log volume. VCF Operations and Log Management can't be scaled back down once scaled up, so size for where you'll be, not where you are.

2. VCF Operations Deployment model

Simple: one node, or a multi-node cluster without HA when one node isn't enough. High Availability: every object is kept on two nodes, so it holds half as many objects as the same nodes without HA. Continuous Availability: node pairs across two fault domains plus a witness, also half the objects.

Locations that need their own Cloud Proxy

Sites or network zones whose vCenters and endpoints are collected locally.

3. Log Management

Size

Events/sec per ESX host Extra events/sec

The official estimator uses 200 per host; the Log Management Detailed Design says hosts × 250. Add extra for heavy senders, such as firewall-rule logging.

Known events/sec optional

From a current log platform. 0 uses the estimate.

Syslog (TCP) senders HTTP / API senders

Sets how many ingestion VIPs you need. Syslog 0 means one per ESX host.

Retention (days) Spare replicas

Storage assumptions

Bytes per event Stored GB per ingested GB

The official estimator's defaults: 400 bytes per event, and 1.25 GB stored per GB ingested, counted in binary GB (GiB). Configuration Maximums implies about 350 bytes (600 GB/day per Small replica at 20,000 events/sec). Change both if you have measured values.

4. Real-Time Metrics

Sized on the ESX host and vCenter counts from step 1.

Services runtime footprint

Log Management

Size	Replicas	Disk / replica	VIPs	IPs	Workers	Note

Workers are VCF services runtime worker nodes: 12 vCPU / 24 GB each for Small, 24 vCPU / 48 GB for Medium, and two of those per Large replica. The runtime adds them itself. IPs: 6 to start, plus 1 per Small or Medium replica (2 per Large), plus 1 for each extra VIP.

Real-Time Metrics

Cloud Proxies

VCF Operations quick estimate

Matches the official estimator for the counts entered here. For the final node size, and for management packs, an audit-file import or data-disk sizing, use the VCF Operations Sizing Estimator.

Size	Nodes	vCPU	RAM GB	Note

VCF Operations estimate matched to Broadcom's VCF Operations Sizing Estimator (build 2026-10-05, compared 2026-10-14); limits from Configuration Maximums (VCF Operations 9.1.0), KB 397782 and the VCF 9.1 Log Management Detailed Design. This is a planning aid, not a lab measurement. For an existing install, enter its real object and metric counts, or run them through the estimator itself.