Aria Operations → VCF Operations: in-place upgrade vs. fresh install

A companion to the Overview, expanding on Phase 1 – VCF Operations upgrade and the standalone VVF manual upgrade path. Applies whenever there is an existing Aria Operations instance to carry forward into VCF 9 – decide this before committing to a phase count, since it changes whether a re-IP procedure, a content migration, or neither is on the critical path.

The two paths

In-place upgrade (Aria Operations 8.18.x → VCF Operations 9.1.x directly) keeps everything – configuration and historical metrics/trend data – but carries forward any accumulated cluster cruft (orphaned adapters, stale content) and, if a network change is needed during the upgrade, requires a manual node-by-node re-IP procedure (below) on top of the upgrade itself.

Fresh install (deploy a new VCF Operations 9.1.x cluster and migrate content across) gives a clean start and sidesteps re-IP entirely, but does not carry historical metrics/trend data across – only configuration content transfers. Confirmed working in practice: dashboards exported from an 8.18.x cluster via Content Management import cleanly into a fresh 9.1.x cluster. Content Management export/import is confirmed to cover dashboards, dashboard sharing, custom groups, and super metrics; coverage of views/reports/alert-symptom-recommendation definitions and policies is likely but not independently confirmed – verify per object type before relying on it for anything not explicitly listed here.

	In-place upgrade	Fresh install + content import
Historical metrics/trend data	Preserved	Lost – stays on the old cluster
Configuration (dashboards, groups, super metrics, …)	Preserved automatically	Migrated selectively via Content Management export/import
Legacy cluster cruft	Carried forward	Left behind
Re-IP, if the network changes	Required as a separate manual procedure	Not needed – deploy directly at the target address
Topology	Must convert on the existing nodes	Can build the target topology (HA, node count) directly
Network subnet compliance (see below)	Inherited as-is – an already-non-compliant layout stays non-compliant	Built compliant from the start, on a single subnet
Effort	Lower – one cluster, one upgrade	Higher – two clusters running in parallel during cutover, every adapter/integration re-registered

Check the cluster’s size either way. Whether the existing nodes (or the fresh cluster you are about to build) are big enough for the object and metric counts on 9.1, and how to scale up or out later, is in VCF Operations sizing and scaling.

Decide primarily on whether historical metric/trend data needs to survive the upgrade. If yes, in-place is close to mandatory. If a clean start is acceptable, fresh install removes the re-IP problem and lets the target topology be built directly instead of converted into.

Check the existing cluster’s network topology before deciding

Analytics cluster nodes are only supported on a single Layer 2 network and IP subnet. Per Broadcom TechDocs’ VMware Aria Operations Cluster Node Networking Requirements: “Place analytics cluster nodes on same Layer 2 network and IP subnet. A stretched Layer 2 or routed Layer 3 network is not supported.” Also: “Packet Round Trip Time between the analytics cluster nodes must be 5 ms or lower” and “Network bandwidth between the analytics cluster nodes must be one gbps or higher.” There’s no separate VCF 9-branded copy of this specific page – VCF Operations is Aria Operations rebranded at the code level, and this is one of the places Broadcom’s VCF 9 docs still point back at the source product’s own docs tree rather than forking a copy. The 9.0-specific VCF Operations 9.0 Sizing Guidelines (already in this doc’s Sources) corroborates the latency figure directly – ”< 5 ms” general node-to-node latency – and adds a separate ”< 10 ms, with possible occasional peaks up to 15 ms” figure for datastore latency, plus a per-cluster-size bandwidth table (15 Mbps Small up to 200 Mbps Extra Large) rather than a single flat floor. Either way, this applies to VCF Operations same as it did to Aria Operations – it isn’t an 8.18-specific limit that goes away at 9.x.

If the existing cluster is already out of compliance with this – nodes spread across different subnets, routed rather than switched between them, or otherwise not meeting the latency/bandwidth figures above – that’s a strong signal toward fresh install rather than in-place: an in-place upgrade carries the existing topology forward as-is, so an already unsupported network layout stays unsupported (and a likely source of cluster instability) straight through the upgrade. Fresh install sidesteps this the same way it sidesteps re-IP – the new cluster’s nodes are placed correctly from the start, on a single compliant subnet, rather than inheriting whatever the old cluster’s network layout happened to be. Check this before the historical-data-retention question above settles the decision on its own – a cluster that needs fixing structurally may still need to go fresh even if retaining trend data would otherwise argue for in-place.

Walkthrough A: in-place upgrade

Applies to Aria Operations 8.14+ (covers the 8.18.x line) going to VCF Operations 9.1.x.

1. Pre-upgrade

Confirm the source build is on a supported direct-upgrade path to the target 9.1.x build (check the current VCF/vSphere Interoperability Matrix – some 8.18.x point releases skip straight to 9.1.1, others must land on an intermediate 8.18.x patch first).
Optionally run the Pre-Upgrade Readiness Assessment Tool (APUAT) – see below for the full procedure.
Take an offline VM-level snapshot of every cluster node (Primary, Replica, Data, Cloud Proxies) – deselect “Snapshot the virtual machine’s memory”.

Pre-Upgrade Readiness Assessment Tool (APUAT)

Uploaded and installed the same way as any other PAK, against the normal, online cluster. Nothing about this step needs the cluster taken offline or brought online first, same as the real upgrade PAK below.

Run it with the cluster online, not offline. Field-verified: running APUAT against an offline cluster produced an empty Removed/Disconnected Metrics tab in the report – no impacted content was listed, which reads as a false “nothing affected” result rather than an error. Re-running the same PAK against the online cluster correctly populated the tab with the actual metric impacts. See also the field notes entry.

Download the source-version-matched Assessment Tool PAK from the Broadcom Support Portal – search “APUAT” or “VMware Aria Operations - Upgrade Assessment Tool”. It’s versioned to the build you’re upgrading from, not the target.
Admin UI → Software Update → Install a Software Update, browse to the PAK, check “Install the PAK file even if it is already installed”, leave “Reset Default Content” unchecked, UPLOAD (several minutes), accept the EULA, NEXT, then INSTALL.
The tool runs a one-time scan and self-deletes when finished – it doesn’t alter anything in the system, so re-running it is harmless.
Retrieve the report: Support → Support Bundles, locate the most-recently-created bundle, download the ZIP, extract it, and open the HTML file inside.
Check two tabs before deciding whether to proceed: System Validation Checks (whether the system is upgrade-eligible at all – failures here are blocking) and Removed/Disconnected Metrics (dashboards, reports, management packs, alerts, and heat maps that reference metrics being deprecated in the target version, each with a link to a suggested replacement metric).

2. Apply the upgrade

Admin UI → Software Update → Install a Software Update, upload the target-version Upgrade PAK.
If prompted, select “Install the PAK file even if it is already installed”; only select “Reset Default Content” if factory-shipped alerts/dashboards should be overwritten back to stock.
Monitor progress. The Admin UI restarts and the cluster automatically transitions Offline → Online during the update – this is expected, not a failure. Do not manually bring the cluster online first – install the PAK against the running cluster and let the update drive the Offline → Online transition itself. (The separate manual take-offline / bring-online sequence below applies only to the re-IP sub-procedure, not to applying the PAK.)
Confirm cluster health and that metrics are still flowing post-upgrade before moving on to the next fleet component.

3. Deploy and register License Server, if not already present

License Server is a required component for VCF 9.x licensing regardless of path or Tier, and typically doesn’t exist yet on an 8.18.x-only source – see step 4 (“Deploy License Server”) under Walkthrough B for the deployment and connected/disconnected registration steps, identical regardless of which walkthrough got VCF Operations to 9.1.x.

4. Re-IP, only if the network is changing as part of the same window

Manual and offline, run after the version upgrade completes:

Update DNS for the node(s) to the new IP before starting – forward and reverse resolution is mandatory for every node in the cluster.
Take the cluster offline (Admin UI → Cluster Status → Take Offline; wait for it to report Offline).
Update the network config on the VM itself (vSphere → Configure → vApp Options → IP / subnet / gateway / DNS).
Stop the CASA service (service vmware-casa stop), edit the node’s config files (casa.db.script, roleState.properties, persistence.properties) to replace the old IP with the new one, restart CASA, then run the vcopsConfigureRoles.py script to reconcile the cluster’s internal role/topology config.
Process nodes in strict order – Primary → Primary Replica (if present) → Data nodes – completing all sub-steps on one node before starting the next.
Bring the cluster back online.

Walkthrough B: fresh install

Not bound to VCF Management Services. Deploying VCF Operations does not require also deploying VCF Management Services – manual OVA deployment of VCF Operations, standalone, without Management Services, is explicitly supported for VVF 9.0/9.1 (“operating a standalone VVF infrastructure without deploying VCF Management Services”). This is the same standalone model the manual upgrade path already documents – it applies equally to a fresh VCF Operations deployment, not just an in-place one.

VCF Installer’s automated flow is a separate, narrower route, and not generally the one this walkthrough follows – see when it applies below. It can select HA mode for VCF Operations at initial deployment, but only inside its fully automated bring-up flow, which assumes standardized infrastructure (vDS, etc.) and does not support manual customization of networking, cluster settings, or storage during that process.

1. Deploy the Primary node

In the vSphere Client, right-click the target inventory object → Deploy OVF Template → point it at the VCF Operations install OVA.
Step through the wizard: node name (no underscores or other nonstandard characters; must be unique per node in a multi-node cluster), compute/storage placement, network mapping.
Power on the VM, then browse to its FQDN or IP to reach the initial setup wizard:
- Enter the Node Name and Node Address; set Current Cluster Role to Primary/new-cluster.
- Set the admin password (minimum 15 characters, one uppercase, one lowercase, one digit, one special character).
- Accept the default self-signed certificate, or load a custom one by browsing to the certificate file.
- Leave the shared/virtual IP field blank unless a load-balanced VIP is being used for the cluster.
Finish the wizard and confirm the single-node cluster comes Online.

2. Add a Data node, then activate HA against it

HA is not a separate “deploy a Replica node” step – you deploy a Data node first, then promote it to Replica through the admin interface:

Deploy a second appliance from the same OVA, with a static IP, following the same OVF wizard as step 1.
On the Primary node’s admin interface (https://<primary-fqdn-or-ip>/admin), click Add new Nodes: enter the new node’s name and IP address, set Current Cluster Role to Data, and supply the Primary’s admin password.
Once the Data node has joined, click Activate under the High Availability section.
Select that Data node to serve as the Replica for the Primary, and confirm.
The cluster restarts to apply HA – wait for it to report Online again before doing anything else; this can take several minutes.

3. Add further Data node(s) for capacity, if the target topology needs more than Primary + Replica

Repeat the “Add new Nodes” step above with Current Cluster Role set to Data, one node at a time, letting each join fully complete before starting the next.

4. Deploy License Server

License Server is a required component for VCF 9.x licensing regardless of path or Tier – see Full VCF upgrade sequence: Prerequisites – Licensing.

In VCF Operations: Manage → Licensing → Licenses & Registration → Manage → License Servers → Add License Server, and copy the time-bound registration code it generates.
Download the License Server OVA from the Broadcom Support Portal.
Deploy it via Deploy OVF Template against the target cluster/host.
In the vApp properties step, set the appliance hostname and paste the registration key into the Unique Registration Key field – copy/paste only, to avoid case-sensitivity or auto-capitalization errors.
Power on and wait 5-10 minutes for the registration heartbeat to sync; confirm the appliance shows up under the License Servers list in VCF Operations.

Registering VCF Operations + License Server with the VCF Business Services console (“licensing happy”) is a separate step from deploying the appliance itself, and is required regardless of Tier. Pick a mode based on whether the environment has outbound internet access:

Connected mode (has internet access – recommended, simpler ongoing upkeep):

In VCF Operations: License Management → Registration → in the connected-mode pane, click Start Registration. The VCF Business Services console opens in a new tab.
Log in to the console with Broadcom Support Portal credentials.
Select the Site ID to register this instance under, click Next.
Enter a unique display name for the VCF Operations instance, Save and Next.
Select licenses to add, Save and Next.
Review the summary, click Generate Activation Code, copy it, Finish.
Back in VCF Operations: License Management → Registration → connected-mode pane → Enter Activation Code, paste it, Activate.
Update licenses at least once every 6 months going forward – usage reporting is automated in this mode.

Disconnected mode (no internet access – manual file exchange, a heavier but firewall-friendly path):

In VCF Operations: Manage → Licensing → Licenses & Registration → Continue on the Register & License pane.
On Select Connection Mode, choose Disconnected, Continue.
In the Download Registration File card, click Download and save the file.
From a computer with internet access, log in to the VCF Business Services console with Broadcom credentials, select the Site ID.
Licensing → VCF Operations Registrations → New Registration, import the registration file just downloaded.
Enter a unique name for the VCF Operations instance, Save.
Download the verification file from the console, import it back into VCF Operations, then download the confirmation file it produces and upload that back to the console – a two-way file exchange, not a single upload.
In the Add Licenses section, start the workflow for the relevant license server, download the license file from the console, and import it into VCF Operations.
Repeat the file exchange (report usage, pull an updated license file) at least once every 6 months (180 days) – there is no automatic heartbeat in this mode, it’s a recurring manual task.

Confirm which mode fits the target environment’s firewall policy before committing – switching from disconnected to connected mode later is possible but is its own documented procedure, not a toggle.

Switching an already-registered instance from connected to disconnected is the easy direction – no re-registration, the existing registration in the VCF Business Services console stays in place:

In VCF Operations: Manage → Licensing → Licenses & Registration.
On the Registration and License Server Status card, click Manage Registration Details.
On the Registration Details tab, next to Reporting Mode, click Switch to Disconnected, then confirm Switch to Disconnected in the dialog.

The switch itself is trivial; the ongoing cost is that usage reporting stops being automatic. From then on, the manual usage-file / license-file exchange (disconnected step 9 above) is due at least every 180 days. Broadcom is explicit about missing it: licenses are treated as expired, hosts are disconnected from vCenter, and no workload operations can be started. Put a recurring reminder well inside that window before switching. Going back to connected later is the separate reverse procedure (see Sources); if the instance has been disconnected for more than 180 days, that switch can fail and needs a new activation code (KB 428209).

Isolated vCenter with no path to a shared VCF Operations/License Server

A vCenter that’s genuinely air-gapped from every VCF Operations instance in the fleet can’t fall back to a standalone license key. Per Broadcom KB 404155, “vCenter 9.0 no longer functions as a standalone licensing authority. Entitlements must be validated via VCF Operations.” Without a reachable VCF Operations to validate against, the symptom is unambiguous: the Version 9.x Licenses section shows “No licenses found,” there’s no field to manually input a license key at all, and the vCenter sits stuck in Evaluation mode indefinitely, even post-upgrade. There is no lighter fallback – 9.x retired manual 25-character key entry entirely, and there’s no way to entitle a vCenter without a VCF Operations instance somewhere it can reach.

The fix is not “put this vCenter in disconnected mode against the fleet’s existing VCF Operations” – per the same KB, “centralized license management across disconnected sites is not supported; each environment requires its own management instance.” Each genuinely isolated network segment needs its own VCF Operations appliance – and its own License Server, deployed the same way as the connected/ disconnected steps above. VCF Operations orchestrates registration, but per Broadcom’s own License Server Overview, it cannot hold or serve licenses by itself: “You must add at least one license server to each VCF Operations instance that you use for license management,” with no exception carved out for a single-vCenter or standalone scenario:

Deploy a VCF Operations appliance inside the isolated network – OVA from the Broadcom Support Portal, same as any other VCF Operations deployment (see Walkthrough B above).
Integrate it with the local, isolated vCenter instance.
Deploy a License Server appliance inside the same isolated network and register it to this local VCF Operations instance – same OVA/registration-code procedure as step 4 above, just against the local instance instead of a shared one.
Generate a registration request from the local VCF Operations UI.
From a separate machine that does have internet access, upload the request to the VCF Business Services Console to obtain a license entitlement file – the same disconnected-mode file-exchange pattern as above, just carried across the air gap by hand rather than network connectivity.
Import the entitlement file back into the isolated VCF Operations instance.
Add the licenses to the local License Server, then assign them to the vCenter and ESX hosts from VCF Operations’ licensing interface.

This does not mean standing up a new fleet. A “fleet” specifically means SDDC Manager / Fleet Management orchestrating a VCF instance – nothing above touches either. This VCF Operations appliance can stay a bare, unattached instance whose only job is entitling this one vCenter, the same documented pattern already used in Walkthrough B: “Building VCF Operations standalone first and attaching SDDC Manager once the fleet exists is a normal, documented pattern, not a workaround.” An upgrade project touching multiple isolated network segments still needs to budget for one VCF Operations appliance per segment – but each one is just that: a standalone appliance, not a fleet.

5. Migrate content from the old cluster

On the old cluster:

Administration → Content Management → Export, select Dashboards (and other content types as needed) – exclude out-of-the-box content unless it was customized.
Export Configuration and Content as separate exports.
Download the generated ZIP(s) from the Export tab.

On the new cluster:

Administration → Control Panel → Content Management → Import, browse to the exported ZIP, choose the desired conflict-resolution behavior, and import.
Import the Configuration export before the Content export – user and role information needs to exist first.
Confirm dashboards render fully (not stuck on the “still configuring” wrench icon) – that icon usually means an underlying View, Super Metric, or Custom Group referenced by the dashboard wasn’t included in the export and needs rebuilding manually.

6. Register data sources

Register each vCenter as a data source – see Registering vCenter as a data source below. This is independent of, and not a prerequisite for, attaching to the fleet.

7. Attach to the fleet, once it exists

From VCF 9, one VCF Operations deployment manages one-or-more VCF instances/fleets – you register an existing VCF instance into VCF Operations (Administration → Integrations → Add → VMware Cloud Foundation, pointing at SDDC Manager’s FQDN), not the reverse. Building VCF Operations standalone first and attaching SDDC Manager once the fleet exists is a normal, documented pattern, not a workaround.

Constraint: once a VCF 9.1 instance is part of a fleet, there is currently no supported way to relocate it to a different fleet / VCF Operations pairing afterward. Doesn’t block building standalone ahead of time, but means the eventual fleet-to-Operations pairing should be planned to be correct the first time.

When VCF Installer is the better fit instead

VCF Installer’s automated bring-up is worth using directly, instead of this manual walkthrough, when its prerequisites are already met:

Greenfield (new fleet/instance) – VCF Installer deploys a brand-new vCenter itself; no existing/upgraded vCenter is required.
Converging an existing vCenter – the vCenter must already meet a version bar before VCF Installer’s converge workflow will run against it. Full version-bar table, prerequisites, and the NSX auto-selection back-in-time trap this path shares with Import: Converge and Import: bringing existing infrastructure under VCF.

If neither applies yet (no NSX, vCenter not at a qualifying build) but a VCF Operations cluster is wanted ahead of the fleet build, Walkthrough B above is the route.

Registering vCenter as a data source (separate from the fleet attach)

Don’t conflate this with attaching SDDC Manager (above) – a fresh VCF Operations cluster needs each vCenter registered individually as a data source before it collects anything from them, regardless of whether/when that cluster is later attached to a fleet.

Prerequisites:

A cloud proxy already deployed and network-reachable to the vCenter instance.
vCenter credentials with at least Read access at datacenter/vCenter level, plus “Performance > Modify intervals” permission for guest metrics. That is monitoring only. For VCF Operations to also license the vCenter – which on 9.1 is the only licensing path – the account needs Global.Licenses, Certificate Management → Create/Delete (below Admins priv), and membership of the LicenseService.Administrators SSO group, followed by Activate Management on the integration. Without them the vCenter collects fine but never appears under License Management → vCenter Systems (field-verified). Full role, account and troubleshooting detail, including the log lines that tell the causes apart: VCF Operations in VVF/Standalone – Post-Deployment Configuration (VCF9-DeploymentPlanning).
vCenter 9.x behind an outbound proxy: the License Server must bypass it, or license assignment fails with “The license server SSL certificates are not trusted by the vCenter instance” – see vCenter proxy configuration.
That message is a catch-all. VCF Operations pushes the License Server’s certificate into vCenter’s trusted roots with the vCenter account (trusted_root_chains.create, KB 443480), then vCenter talks to the License Server itself. Missing certificate privileges, the proxy, or a push that simply didn’t land all produce the same message. If both privileges and proxy are ruled out, adding the License Server’s certificate to vCenter’s trusted roots by hand is a field-reported workaround – the flow, KB 424533’s checklist and the steps: License Server certificate trust (VCF9-DeploymentPlanning).
Log management appliance deployed, if log collection from this vCenter is wanted.

Procedure (Operate → Administration → Integrations → Accounts tab → Add → vCenter):

Enter a display name/description (include the IP for easy identification as a convention).
Enter the vCenter FQDN, not IP – “vCenter instances configured using IP address are not included in VCF accounts. If you want the vCenter instance to be part of the VCF account, enter the FQDN.”
Select or create the associated Physical Data Center.
Add credentials, and optionally separate Action Credentials for running actions.
Select the Cloud Proxy/Group that will manage this account.
Toggle Activate for Operational Actions / Log Collection / Network and Flow as needed; expand Advanced Settings for collector, discovery, and event-change options.
Click Validate Connection, review the presented certificate against the vCenter’s actual certificate, and accept.
After the account is added, open its context menu and click Start Collecting.

Collection then proceeds on a standard 5-minute cycle; initial collection for a large environment can take more than one cycle to fully populate.

For a fleet with multiple vCenters (the common case for a convergence engagement with several existing vCenter instances), each one is registered as its own account through this same flow – there is no bulk-register step.

Where the stored credentials live. There’s no menu entry for them: they sit behind a Credentials button on Administration → Integrations. You can only view a credential you own (field-observed on 9.x).

Do this as the local admin account. A credential created under a personal or AD account is owned by that account, and nobody else can view it. When that person leaves, or the account is disabled, the credential is stuck with them. Registering integrations as admin keeps every credential in one place the team can always reach.

Continuous Availability vs. plain HA – don’t conflate them

Both are opt-in, advanced-architecture configurations in VCF 9 Operations, not defaults – Broadcom files both under “Manual Deployment and Configuration of Components for Advanced Architectures.” They solve different problems and have different minimum topologies:

HA (Replica node) – single-site failover pair: Primary + Replica (+ Data node(s) for capacity). Protects against loss of one node.
Continuous Availability (CA) – multi-fault-domain resilience: needs three separate fault domains (Primary fault domain with ≥1 Primary + ≥1 Data node, a mirrored Replica fault domain, and a Witness fault domain), each fault domain able to be a different workload domain, availability zone, or region. Adds FD-to-FD latency requirements (~≤10ms) and witness-node sizing that HA alone does not need.

A 3-node cluster spread across 3 sites over L3 looks like the textbook minimum CA topology, but confirm CA is actually configured (not just a node/site count that happens to resemble it) before designing an upgrade or downscale procedure around CA-specific assumptions – node/site count alone is not proof of CA.

Removing a node – data loss

Verbatim from Broadcom’s documentation:

“When you remove a node, you lose data that the node had collected unless you are running in high availability (HA) mode. HA protects against the removal or loss of one node.”

Without HA, removing a Data node loses whatever metrics/objects it held – there is no documented rebalance/redistribution alternative. Practical notes for a non-HA removal:

Cluster must be in a clean Online/Offline state – never mid expand/shrink; contact support instead of forcing it if it’s in a failed state.
Take a snapshot/backup first.
Removal itself, for a Data or Remote Collector node, is one call: curl -ik -u 'admin:password' -X DELETE https://<primary_node_IP>/casa/deployment/slice/<node_to_remove_IP>
Re-check sizing on the surviving node(s) against the full object/metric count before committing – a downscale concentrates the same workload onto fewer nodes.