VCF Operations & Log Management Sizing

Interactive tool: Ops & Logs Planning Sizer applies the rules on this page to your numbers. It’s a companion to Broadcom’s VCF Operations Sizing Estimator, not a replacement: use the estimator for the final VCF Operations node size.

What the planning sizer adds

The official estimator sizes VCF Operations well, and better than this tool: it works per management pack, imports an existing install’s object counts and sizes the data disk. What it doesn’t give you, checked against its 2026-10-05 build:

• The services runtime footprint. Log Management runs on VCF services runtime worker nodes. The tool shows how many workers (and their vCPU / GB), how many IPs to reserve in the services-runtime block of your network plan, and how many ingestion VIPs. The estimator gives vCPU / RAM per replica only.
• Real-Time Metrics, which the estimator doesn’t size at all.
• Log Management limits the estimator leaves out: hosts per size and the per-VIP limits.
• Cloud Proxies per location. The estimator sizes collectors by load only.
• Where the sources disagree (estimator vs TechDocs), dated, so you can explain a different answer.

The VCF Operations section is kept as a quick estimate: it gives the same answer as the estimator for the counts it asks for.

The Management Domain sizer starts from a size you have already chosen and adds up its footprint. This page covers the step before that: which size, and how many nodes or replicas, for the environment you will monitor. Take the result back into the Management Domain sizer to check that it fits your cluster.

The rules follow Broadcom’s official VCF Operations Sizing Estimator (build 2026-10-05), which the tool was matched against on 2026-10-14: 75 reference scenarios give the same result (see How this compares with the official estimator). The limits are Broadcom’s published figures from the sources in Sources, read the same day. None of it is lab-measured. For an existing VCF Operations or Aria Operations install, your real object and metric counts beat any estimate.

VCF Operations

Node sizes

From Configuration Maximums (VCF Operations 9.1.0). The figures are identical to KB 397782 (9.0), which also carries the scaling rules below.

How the size is picked

1. Count objects. An object is anything VCF Operations collects properties and metrics for: every VM, host, datastore and vCenter, plus NSX, vSAN and management-pack objects. If you already run VCF Operations, use its real count instead.
2. Count metrics. Use the real count if you have one. Otherwise estimate it at the official estimator’s per-kind rates: 262 per VM, 292 per host, 230 per vCenter, 93 per datastore (227 per cluster, 165 per datacenter, not asked for here). Objects with no rate are counted at the VM rate. Metrics usually set the size from about 15,000 VMs.
3. Add the 20% buffer, then growth. The estimator always adds 20% to objects and metrics, and applies growth on top (growth 10% gives ×1.32). Neither VCF Operations nor Log Management can be scaled back down, so size for where you’ll be, not where you are.
4. Apply the model.
   • Simple is one node, held to the single node limits. When no single node is big enough, the estimator offers a multi-node cluster without HA on the per-node cluster limits, and so does the tool.
   • High Availability replicates every object to a second node, so KB 397782 says the limit is “two times less compared to a non HA configuration”. Nodes needed = ⌈2 × objects ÷ objects per node in a cluster⌉, at least 2. The estimator does not double metrics: nodes for metrics = ⌈metrics ÷ metrics per node⌉.
   • Continuous Availability replicates to a node pair across two fault domains, so capacity is also halved. The node count must be even, each fault domain is capped by the last column above, and a witness node (2 vCPU / 8 GB) is added in a third site.
5. Pick the size. The estimator picks the smallest size whose single-node limits hold all objects and metrics, in every model. The exception is Small in HA and CA, which counts at half its limits (5,000 objects / 800,000 metrics). Only when no size qualifies does it take the fewest nodes, which is KB 397782’s rule: “Use the configuration which has the least number of nodes, but is able to accommodate the number of objects to be monitored.” Its example: 352,000 objects (no HA) is 4 × Extra Large rather than 10 × Large. The two rules differ in HA: at 19,000 objects and 4.9M metrics the estimator picks Medium × 3 over Large × 2. All nodes in a cluster must be the same size.

The estimator also sizes each node’s data disk from metric retention and rollup. The tool doesn’t.

Raising node memory to its maximum (Extra Small 16, Small 32, Medium 64, Large 96, Extra Large 256 GB) raises the limits by about 20% for a single node and 10% for a cluster. The tool doesn’t count on that, so treat it as headroom.

Cloud Proxies

Unified Cloud Proxy limits, from KB 397782 and the 9.1 Add a Cloud Proxy page:

Plan at least one proxy per location (site or network zone) that is collected locally. Add more when objects or vCenters go over one proxy’s limit. Use Small while the per-location count already covers the load, otherwise Standard. A node’s own collector handles only 5 / 25 / 50 / 100 / 120 vCenter adapters (Extra Small to Extra Large), which is another reason to collect through proxies.

Log Management

Per-replica limits

From the VCF 9.1 Log Management Detailed Design (Last Updated 2026-10-12). Log Management runs as replicas on the VCF services runtime. Capacity scales with the number of replicas and with their size.

The GB/day column is from Configuration Maximums. Which connection figure applies to which protocol is disputed; see Where the sources disagree. The events-per-second figure is for a “typical load profile”: a lighter profile (fewer queries, smaller messages) can reach the hard cap, but don’t plan on it.

How the size is picked

1. Estimate events per second. The official estimator uses 200 per ESX host. The design page says more: “The number of EPS can be approximated by the number of ESX hosts in the fleet multiplied by 250.” The tool defaults to 200; set 250 for the published figure. Add your heavy senders on top. The page names firewall-rule logging as one that “can generate a significant volume of EPS”.
2. Replicas for load = the larger of ⌈EPS ÷ events per replica⌉ and ⌈GB per day ÷ GB/day per replica⌉. The estimator uses both limits.
3. Replicas for retention. Each replica’s disk ranges from 500 GB to 9 TB, so the retained data needs at least ⌈retained GB ÷ 9,000⌉ replicas. The estimator caps a replica at 9,000 GB.
4. Spares are optional. The design page advises “plan for an extra replica or two (N+1 or N+2)”. The estimator adds none, so the tool defaults to none and lets you choose N+1 or N+2. Then apply the size’s minimum (3 for Medium and Large).
5. Choose the size. The estimator uses Small while it needs at most 5 replicas, Medium up to 12, otherwise Large. The design page puts it more loosely: “scaling up the size to medium once you exceed 5-6 small replicas, or large once you get to 6-8 medium replicas”. Many small replicas make a later size change a big jump, because it applies to every replica (12 Small become 12 Medium).
6. Size the VIPs. Each VIP has its own load balancer with the per-VIP limits above. Add VIPs, and point senders at different FQDNs, when events or connections go over one VIP. Broadcom recommends against putting an external load balancer in front.

Storage: the assumptions

The TechDocs pages say only that “Storage capacity is a factor of the retention period and the number of log messages received”. The tool uses the official estimator’s defaults, which you can change:

• Bytes per event: 400. Configuration Maximums implies about 350: 600 GB/day per Small replica ÷ 20,000 events/sec.
• Stored GB per ingested GB: 1.25. Retained = GB per day × retention days × 1.25.
• Binary units. The estimator counts a “GB” per day as 1024³ bytes, and so does the tool.

If you can measure both on a current log platform, use your own numbers.

Footprint on the VCF services runtime

Log Management deploys no appliances of its own. The services runtime adds worker nodes for it (design page):

Allow 6 IPs for the initial installation plus the per-replica IPs, plus one for each VIP you add. The design page, verbatim: “Allow for 6 IPs for an initial log management installation plus 1 IP for every small or medium replica and 2 IPs for every large replica.” (Until #401 the network plan said “+2 per additional replica”; it now follows this page.) All replicas run on the same cluster and datastore as the services runtime, so that datastore has to hold every replica’s disk.

Where the sources disagree

The sources disagree in two places. All three TechDocs pages involved show Last Updated 12 Oct 2026:

• Medium is 24 vCPU / 48 GB on the Deploy Log Management page, but 16 / 32 on the design page and in Configuration Maximums. The design page explains the gap: 24 / 48 is the size of the services-runtime worker node that a Medium replica runs on, and 16 / 32 is the replica. Both are correct; they measure different things.
• Connections per VIP are printed in opposite orders. The design page heads the column “Connection Limit (http / tcp [syslog])” and gives Small 20k / 50k, which reads as HTTP 20k and syslog 50k. Configuration Maximums labels the same pair “Syslog Connections (Active TCP Connections) / Http Connections”, which reads as syslog 20k and HTTP 50k. Large is 30k / 50k in both. Until one is corrected, the tool takes the lower figure (20k, or 30k for Large) for both protocols. That may ask for one VIP more than you need, but never one less.
• The Large minimum is 3 replicas on the design and deploy pages. The P&P workbook (and so the Management Domain sizer) uses a minimum of 6. This page and its tool follow TechDocs.

How this compares with the official estimator

The VCF Operations Sizing Estimator (build 2026-10-05) sizes VCF Operations and Log Management through a public API (/api/recommend, /api/logs/recommend). This tool was compared with it on 2026-10-14 and changed to match (#400). Where the estimator and the published pages disagree, the tool follows the estimator, because that’s what you’ll be compared against:

The 75 reference results (39 VCF Operations, 36 Log Management, across sizes and models) are stored in web/scripts/ops-logs-estimator-fixtures.json, and the site build re-checks the tool against them, so a change that drifts from the estimator fails the build. If Broadcom changes the estimator, re-capture those results.

Two things the tool keeps that the estimator doesn’t: the host limit per Log Management size (Small 1,500, Medium 3,000, Large 4,560, from the design page), and the per-VIP limits that set the number of ingestion VIPs.

Real-Time Metrics

From Configuration Maximums (VCF Operations 9.1.0). Pick the smallest size that covers both your ESX host count and your vCenter count:

The host limit counts all connected vCenters together. Real-Time Metrics also runs on the services runtime, with no appliances of its own. The deploy wizard has been seen to show 32 vCPU / 43 GB for a Medium instance: that’s the services-runtime scale-up for it, which is not the same quantity as the table (see 04-sizing.md, #200).

What this does not model

• VCF Operations for Networks, Telegraf agents, Service Discovery and VDI (Horizon) objects have their own limits in KB 397782. They’re not covered here.
• Multi-instance Log Management. If no single instance fits (more than 19 Large replicas or 4,560 hosts), split the logs across instances. See Broadcom’s Multi-instance Log Management Model.
• Other load factors. The design page lists factors that lower processing capacity: complex or numerous filtering rules, many queries (from automation or several admins), and hosts without hardware-accelerated FIPS ciphers. Turning off event clustering raises it. Leave headroom if your environment has the first three.
• Peak vs average. Broadcom notes you can provision for peak load, or for average load and accept that some logs may be lost at peak. The tool sizes for the events-per-second figure you give it.

Sources

• Configuration Maximums, configmax.broadcom.com, product VCF Operations, release 9.1.0: VCF Operations node and Cloud Proxy sizes, Log Management and Real-Time Metrics categories.
• VCF Operations 9.0 Sizing Guidelines (KB 397782): HA / CA halving, CA fault-domain limits and witness, the fewest-nodes tip, collectors.
• Log Management Detailed Design (VCF 9.1): per-replica and per-VIP limits, EPS estimate, spares, scale-up advice, disk range, worker nodes and IPs.
• Deploy Log Management (VCF 9.1): wizard sizes and replica ranges.
• VCF Operations Models (VCF 9.1): Simple, High Availability and Continuous Availability.
• VCF Operations Sizing Estimator (build 2026-10-05, compared 2026-10-14): the rules the tool follows where the published pages differ.
• For scaling an existing VCF Operations cluster up or out, see the upgrade guide’s VCF Operations sizing and scaling.