TL;DR · Key Takeaways
- In VCF 9 the installer deploys VCF Operations for you, so the real work is connecting data sources correctly.
- Data sources connect as integrations, also called management packs, each backed by an adapter and an account.
- Some integrations are on by default and cannot be disabled. The compliance packs are off until you enable them.
- Collection runs through the appliance or through cloud proxies. A single proxy is a single point of collection failure, so pair them.
- Confirm every object from the Part 2 inventory shows up before you trust a single dashboard.
Three weeks after a clean VCF 9 build, someone asks why the PCI compliance report is empty. Nothing is broken. The PCI pack was never on. On a fresh deployment several integrations start activated and a handful, including every compliance benchmark and the ping check, start off. Assume they are all running and you will trust a dashboard that is quietly blind.
Deployment in VCF 9 is not the hard part anymore. The installer handles the appliances. The work that decides whether VCF Operations is useful is connection: which data sources you attach, how you collect from them, and which defaults you accept without reading.
What actually gets deployed
VCF Operations is not a single box. A deployment is made up of the VCF Operations Manager appliance, a Fleet Management appliance and a collector. Because it is mandatory in VCF 9, the VCF Installer builds it as part of the fleet, and after the installer finishes you log in to VCF Operations to begin. That is the whole deployment story for most fleets, which is a real change from the days of hand-deploying an analytics cluster. The flip side is that the installer making it easy can lull you into skipping the verification that used to be forced on you by a manual build. The appliances being present is not the same as the platform being connected, sized and protected. Treat the post-install login as the start of the real work, not the finish line.
Remember the constraint from Part 1: one VCF Operations instance per fleet. That single instance is why sizing and availability matter, and it is why the collection design below is not optional polish. If the one instance and its collection path are fragile, the whole fleet goes dark at once.
Connecting data sources
Connections are called integrations, and VCF Operations also refers to them as management packs. You manage them from the left menu under Administration then Integrations. An integration can be a connection to a data source plus prebuilt dashboards, alerts and views. Underneath, an account holds the adapter, and the adapter is what actually talks to the product or API. So the chain reads: integration contains an account, the account holds an adapter, the adapter collects. The vCenter account, for example, connects VCF Operations to your vCenter instances, collects their metrics, and can run actions against them.
Defaults that surprise people
On a fresh deployment, core platform integrations are activated automatically and some cannot be deactivated at all: vCenter, vSAN, NSX, vSphere Supervisor, Service Discovery and OS and Application Monitoring are on and stay on. The VMware Cloud Foundation and vSphere Replication integrations are on but can be turned off. The ones that catch people are off by default: the VCF for Networks integration, the Ping check, both VCF Automation organization packs, and every compliance benchmark (CIS, DISA, FISMA, HIPAA, ISO, PCI). If your security team expects continuous compliance, someone has to enable those packs. They do not turn themselves on.
| Integration | On by default? | Can deactivate? |
|---|---|---|
| vCenter | Yes | No |
| vSAN | Yes | No |
| NSX | Yes | No |
| vSphere Supervisor | Yes | No |
| VMware Cloud Foundation | Yes | Yes |
| VCF for Networks | No | Yes |
| Ping | No | Yes |
| Compliance packs (CIS, DISA, FISMA, HIPAA, ISO, PCI) | No | Yes |
Cloud proxies and collector groups
A cloud proxy collects data from an endpoint environment and uploads it to VCF Operations. One proxy can serve multiple vCenter accounts, which is convenient and also a trap, because that one proxy becomes the single throat through which a whole set of sources breathes. You can deploy classic or unified cloud proxies depending on need. The part to internalize: for high availability or load balancing you deploy two or more cloud proxies in a collector group. A lone proxy is a single point of collection failure, and when it reboots for patching your data has a hole in it exactly when you might be changing something risky.
Your connection account is a security choice
The vCenter account does two jobs: it collects, and it can run actions against vCenter. Those are different trust levels. If all you want is monitoring, the service account needs read-level collection rights. The moment you intend to run actions from VCF Operations, power operations, snapshot cleanup, vMotion, that same account needs the rights to do them. People often grant broad rights up front because it is easier, then forget that the monitoring system can now change production. Decide deliberately, and scope the account to what you actually let Operations do.
Scaling collection across sites
Because there is one VCF Operations instance for the whole fleet, the proxies are how you reach everything that instance has to watch, including sites and network segments the appliance cannot touch directly. A single proxy can serve several vCenter accounts, so the temptation is to point everything at one and move on. That works until scale or distance gets in the way: a remote site behind a slower link, a security zone the central appliance cannot reach, or simply more sources than one proxy should carry. The fix is the same building block in both cases, a collector group, used either for availability at one location or to place collection near a group of sources. Plan proxy placement the way you plan any collection topology: close enough to the sources to be reliable, grouped enough to survive a reboot, and sized so no single proxy is carrying the whole fleet on its own. Getting this wrong does not show up on install day. It shows up the first time a link wobbles or a proxy falls behind, and suddenly part of your fleet is missing from a console you thought was complete.
Picture a fleet with three vCenters behind a single cloud proxy. Day to day it works. Then patch night arrives and the proxy reboots. For the minutes it is down, all three vCenters stop reporting, so your dashboards show a gap and any threshold that needed continuous data goes quiet, right when you are touching the environment. Now add a second proxy and put both in a collector group. Collection rides through the reboot because the group keeps serving. The cost is one more small appliance. The return is that your single VCF Operations instance never goes blind during routine maintenance. For any fleet where collection during change windows matters, and that is most of them, two proxies in a group is the baseline, not a luxury.
Questions from the field
Do I install VCF Operations myself in VCF 9?
For a standard VCF 9 build, no. It is a mandatory component and the VCF Installer deploys the appliances as part of the fleet. Your work begins after the installer completes, when you log in and start connecting data sources.
What is a cloud proxy and do I need one?
A cloud proxy collects from an endpoint environment and uploads to VCF Operations, and it can serve multiple vCenter accounts. You need proxies when collection should happen close to the source or across a boundary, and you should run two or more in a collector group whenever collection continuity matters.
Which integrations are off by default?
The compliance benchmarks (CIS, DISA, FISMA, HIPAA, ISO, PCI), the Ping check, the VCF for Networks integration, and both VCF Automation organization packs start off. Core platform integrations such as vCenter, vSAN, NSX and Supervisor start on, and several of those cannot be deactivated.
Should I configure the Operations for Networks adapter manually?
No. Fleet Management creates and manages that adapter instance during deployment and upgrade. Enable the integration through the supported path and let the system own the adapter to avoid duplicates.
What rights does the vCenter account need?
Read-level rights are enough for monitoring. If you plan to run actions from VCF Operations, the account needs the privileges for those specific actions. Grant only what the role requires.
When an object is missing: a quick triage
The most common day-one and day-two question is some version of why do I not see this host, cluster or VM in VCF Operations. Almost always the answer is one of four things, and checking them in order saves you from random clicking. Work the chain from the outside in: is the integration even on, is the account connected and authenticated, is the collector or proxy healthy, and finally has discovery actually run.
Walk the chain in order
First, the integration. If the source type is off, as the compliance packs and VCF for Networks are by default, nothing downstream can collect, so confirm activation before anything else. Second, the account. An account with bad or expired credentials, or one pointed at the wrong endpoint, will sit in a failed state and collect nothing; the Integrations page shows you that status directly. Third, the collector path. If the cloud proxy serving that account is down or aged, collection stops for every source behind it, which is exactly why the collector-group point from earlier matters. Only after those three is it worth asking whether discovery has run, because discovery populates objects once the adapter instance is healthy. Following this order turns a vague missing object into a specific, fixable cause in a couple of minutes.
The reason this triage belongs in a deployment part and not a troubleshooting part is that the same chain is your install verification. If you can walk integration, account, collector, discovery and get a clean answer at each step for every source, your connection work is genuinely done. If you cannot, you have found the gap before it becomes a 2 a.m. surprise.
Where this leads
Deployment is solved by the installer; connection is where you earn the value. My verdict: walk the Integrations page like a checklist, build a real collector group, and scope the account on purpose. Do that and the objects from Part 2 populate cleanly, which is the precondition for everything that follows.
With data flowing, the next part turns to what you do with it first: dashboards that actually get used, instead of the wall of default panels nobody opens twice.
Collector design at a glance
Where collection runs, and what happens when a piece of it fails.
| Collection path | Runs where | Redundancy | Use when |
|---|---|---|---|
| Analytics node | On the VCF Operations appliance | Part of node HA | Objects reachable from the appliance network |
| Cloud proxy | A separate collector near the data | One proxy is a single point of collection failure | Remote sites or segmented networks |
| Collector group | Two or more proxies grouped | Survives loss of one proxy | Any site you cannot afford to stop collecting |
« Previous: Part 2 | VCF 9 Operations Complete Guide | Next: Part 4 »
References
- Integrating Data Sources with VCF Operations, VCF 9.0 (Broadcom TechDocs)
- vCenter Account in VCF Operations, VCF 9.0 (Broadcom TechDocs)
- Configuring Cloud Proxies in VCF Operations, VCF 9.0 (Broadcom TechDocs)
About The Author
DrJha