TL;DR · Key Takeaways
- VCF Operations is the mandatory day-2 console in VCF 9. The standalone metrics, logs and network products are no longer separate installs.
- Same analytics engine you knew as vRealize Operations, then Aria Operations, now renamed and given a wider job.
- One instance per fleet, not one per site, so plan sizing and consolidation before you deploy.
- It now owns licensing, SSO and identity, certificates and lifecycle. One license file pools CPU cores and vSAN TiB across the fleet.
- Treat it as tier-0. On day one, reconcile the inventory count, confirm the license pool sits under entitlement, and triage Diagnostic Findings.
This first part is orientation. What VCF Operations actually is in VCF 9, what changed from the Aria Operations you already know, and why the rename matters more than a rename usually does. Get the mental model right here and the next seventeen parts, the data model, dashboards, alerts, capacity, cost, all sit on solid ground.
It used to be called Aria Operations
The lineage is short, and worth saying out loud because the name has changed three times. This is vRealize Operations, which became VMware Aria Operations in the 2023 to 2024 rebrand, and is now VMware Cloud Foundation Operations, or VCF Operations for short. Same analytics engine underneath. The objects, metrics and properties you learned still apply. Dynamic thresholds, symptoms, alert definitions, super metrics, custom groups, all still there and all covered later in this series.
So your muscle memory mostly carries over. What did not stay the same is the scope. In VCF 9 this stopped being a monitoring appliance sitting beside the platform and became the control point for day-2. It absorbed products that used to stand on their own, and it picked up jobs, licensing, identity, lifecycle, that used to live in SDDC Manager. That is the part that changes your planning, not the logo.
It is mandatory now
In older releases you could run VCF and never deploy Operations. Plenty of shops did, and bolted monitoring on later or never. That option is gone. In VCF 9 it is a required component. If it is not there, the installer deploys it; if you are upgrading from a release without it, you install it as part of the upgrade. Which means it is on the critical path, so you design, size and protect it like one.
One instance per fleet
Fleet is a new VCF 9 word. It means everything in the deployment: VCF Operations, VCF Automation, your vCenters, NSX managers, clusters and workload domains. Here is the rule that catches people out: there is exactly one instance of VCF Operations and one of VCF Automation per fleet. You can run several VCF instances, but Operations is the single pane across them. If you came from one Operations cluster per site, plan the consolidation up front, because the single-instance model drives your sizing and your availability design.
Licensing lives here now
This is the quiet headline. VCF Operations is now the license manager for the whole stack. The old way was a long 25-character hex key pasted onto each component. The new way is a single license file per instance, pooling entitlement across the fleet for both CPU cores and vSAN capacity in TiB. Advanced services like Private AI Foundation with NVIDIA and extra vSAN TiB are tracked in the same file. On top of licensing it also took on single sign-on and identity, unified certificate management with automatic renewal, password rotation tracking, and lifecycle management of upgrades, all from one UI.
Put that together and VCF Operations is not just where you watch graphs. It is where licensing, identity, certificates and upgrades live. If this appliance is unhealthy you have lost far more than dashboards, which is why I keep saying tier-0.
One console instead of four
The consolidation is the daily-life change. Logs are built in now, with event filtering, trend views and a Log Assist workflow that bundles logs for root-cause work and support cases, so you stop pivoting to a separate Log Insight appliance. Network operations is built in too, with health monitoring, traffic analysis and automatic discovery of business applications, the job that used to belong to Operations for Networks. A Diagnostic Findings page correlates issues across the infrastructure by matching known signatures, and VCF Health rolls up vCenter connectivity, services and vSAN health. The Management Pack Builder ships natively so you can model third-party kit, and Supervisor and vSphere Kubernetes Service clusters are monitored out of the box.
| Pre-VCF 9 product | What you used it for | Where it lives in VCF 9 |
|---|---|---|
| vRealize / Aria Operations | Metrics, dashboards, capacity, alerts | VCF Operations core |
| Operations for Logs (Log Insight) | Log search, RCA | Integrated logs and Log Assist |
| Operations for Networks (Network Insight) | Flow analysis, network mapping | Network operations |
| SDDC Manager licensing and lifecycle | Per-component keys, upgrades | Fleet management (license manager, LCM) |
One opinion, said plainly: I would drop the standalone Log Insight and Network Insight habits the day you move to VCF 9. The integrated experience is where the correlation lives now, where a metric spike, a log line and a flow can sit on one screen. Keeping the old appliances alive just to save a query is how you end up with two sources of truth and an argument at 2 a.m. about which one is right.
Your first week with VCF Operations
If you inherit a VCF 9 fleet and someone hands you Operations, do not open the dashboard catalog first. The dashboards are downstream of two things that decide whether you can trust any of it: complete collection, and a clean licensing and identity baseline. Get those right in week one and the rest of the series pays off. Skip them and you spend month two chasing alerts that fire because an adapter quietly stopped collecting.
Confirm collection before you trust a single graph
The first real signal is a count, not a metric. Compare the inventory Operations reports against what you know is out there: every vCenter, every cluster, every host, every datastore. A vCenter that got added to the fleet but was never connected as a collection source is invisible, and invisible things do not page you when they break. This is the most common silent failure on a fresh deployment. The platform looks healthy precisely because the unhealthy thing is not being watched. Walk the inventory, reconcile the numbers, and only then believe the green.
Read the Diagnostic Findings page early
Operations scans the environment against known signatures and lists matches on a Diagnostic Findings page. On a freshly upgraded fleet this page is gold, because it catches config problems that predate you: a host in a non-compliant mode, a certificate near expiry, a vSAN setting that drifted. It is the closest thing to a second pair of eyes that already knows the common failure patterns. Clear it before you start tuning alerts, otherwise you cannot tell an inherited problem from a new one.
My day-one checklist for an inherited fleet is four lines: inventory count matches reality; license pool sits under entitlement for both cores and vSAN TiB; SSO sources are the ones you expect; Diagnostic Findings is read and triaged. None of that is a dashboard. All of it is the ground the dashboards stand on.
Worked example: what one license file actually covers
Take a modest fleet: 3 clusters, 8 hosts each, so 24 hosts. Each host has two 32-core CPUs, which is 64 cores a host, so 24 times 64 is 1,536 cores of compute entitlement. Say vSAN presents 220 TiB of licensed capacity across the clusters. In VCF 9 that is one license file: roughly 1,536 cores and 220 TiB pooled in a single place, not 24 hex keys you reconcile by hand. The check that matters on day one is simple: consumed cores and consumed TiB both sit under entitlement, fleet-wide. Add a ninth host to a cluster and that is another 64 cores drawn from the same pool. You see it as one number, and you catch the overcommit before procurement does.
The reason this belongs in an operations series and not a procurement memo: when the pool is tight, capacity decisions and licensing decisions become the same decision. Reclaiming an idle cluster is not only freeing CPU and memory, it is freeing licensed cores. Later parts on capacity and reclamation lean on exactly that link.
Questions I actually get
Is VCF Operations the same thing as vRealize Operations?
Effectively yes, with a bigger job. Same analytics product, renamed from vRealize Operations to Aria Operations and now to VCF Operations. The data model and most workflows carry over. What is new in VCF 9 is the wider scope: licensing, identity, lifecycle, and the absorbed logs and network tooling.
Can I skip deploying it in VCF 9?
No. It is a required component. A fresh build installs it, and an upgrade from a release without it installs it during the upgrade. Plan its capacity and availability the way you would for vCenter.
Can I run more than one instance per fleet?
No. One VCF Operations and one VCF Automation per fleet, spanning your VCF instances. Multiple sites means you design the single instance reach and its availability on purpose, not an instance per site.
Does it replace Log Insight and Network Insight?
For day-2 inside VCF 9, the integrated logs and network operations are where the work happens, with Log Assist for bundling and RCA. The standalone products still exist in the wider portfolio, but my advice is to move into the integrated experience rather than run two sources of truth.
Where to start
Hold on to one sentence before you go further: in VCF 9, VCF Operations is the day-2 control point, it is mandatory, there is one per fleet, and it holds your licenses and identity. Everything else in this series is built on that. My take: stop thinking of it as monitoring you can add later, and start running it as the most important management appliance in the fleet after vCenter.
Next we go under the hood: the data model of objects, metrics, properties and relationships, which is the language every dashboard and alert in VCF Operations is written in.
By the numbers: one license file for the whole fleet
A modest fleet, and the single pool VCF Operations now tracks for it.
| Item | Value |
|---|---|
| Clusters | 3 |
| Hosts per cluster | 8 |
| Hosts, fleet total | 24 |
| CPU cores per host | 64 (two 32-core CPUs) |
| Licensed CPU cores, pooled | 1,536 |
| vSAN licensed capacity, pooled | 220 TiB |
| License files to manage | 1 (was 24 keys) |
References
- VCF Operations Overview, VCF 9.0 (Broadcom TechDocs)
- Operations in VMware Cloud Foundation 9.0 (VCF Blog)
- VCF Operations Sizing Guidelines (Broadcom Knowledge)
About The Author
DrJha