Day-2 / Day-N Fleet Deployments

Not every fleet component has to go in at bring-up. In VCF 9 the management domain comes up first, and a set of fleet components can be deployed later as Day-2 (Day-N) operations, driven by VCF Operations fleet lifecycle. VCF Automation in particular is commonly skipped at bring-up and deployed Day-N.

This page captures the planning decisions for those Day-2 deployments so the networking, DNS, and IP prep is ready before the deployment runs — the same “lock it first” idea as the Step 1 network plan. It maps to the workbook’s Deploy Fleet Management Day-N sheet.

Scope. This page is the fleet-management components (VCF Automation, Log Management, Operations for Networks). The other kind of Day-N expansion — adding workload domains and clusters after bring-up, and stretching them — is covered in 06-deployment-plan.md (E9). Those SDDC Manager API specs (network pool, workload domain, cluster, vSAN stretch) can optionally be built, validated, and submitted with VCFJsonSpecCreators.

The fleet you pick here sets your shutdown order. Every optional component on this page — VCF Automation, Operations for Networks, Cloud Proxy, License Server — is a numbered step in the documented shutdown and startup sequence. See 13-shutdown-startup.md; components you never deploy simply drop out of it.

Placeholders below use Rainpole-style values (sfo.example.io, 10.11.x.x). Replace consistently. This is a planning checklist, not a step-by-step deployment guide — follow the Broadcom deployment guidance for the actual procedure.

A. Decision gate — what goes in Day-2 vs. at bring-up?

Size the footprint of whatever you choose here on the sizing tool (04-sizing.md) — the Day-2 components are the same optional components the sizer models.

B. The deployable set

Each of these can be added Day-N from the Deploy Fleet Management Day-N sheet. Capture an FQDN + reserved IP for every appliance (nodes listed), plus the network placement from section C.

B.1 — VCF Operations load balancer is external, never served by VCF

This trips people up, so plan it up front. The VCF Operations analytics cluster (Primary / Replica / Data) is reached two ways, and only one of them involves a load balancer:

• No load balancer (default). There is no built-in floating or cluster IP for VCF Operations — you reach the cluster directly on the node FQDNs. Nothing extra to provision. Most deployments use this.
• Load-balancer VIP (optional). If you want a real load balancer in front of the analytics nodes, VCF does not deploy or manage one for VCF Operations — you must bring your own external load balancer (e.g. F5, or a standalone Avi/NSX ALB instance you run yourself). The load balancer is never served from VCF; VCF only records the VIP it points at. Per Broadcom TechDocs both the HA and Continuous Availability models “support an optional external load balancer.”

When you do use an external LB, plan for:

• an extra IP + FQDN for the VIP (on top of the per-node FQDNs/IPs), and
• certificate SAN coverage — every cluster node FQDN and the load-balancer FQDN must be in the certificate’s Subject Alternative Names.

Where the setting lives: the Deploy Management Domain and Deploy Fleet Management Day-N sheets carry an optional “Load Balancer FQDN” (+ IP) for VCF Operations — leaving it empty means no LB (node FQDNs only); filling it is the switch that says an external LB fronts the cluster. Decide it before you request certificates (the SAN list depends on it).

Don’t confuse this with Log Management. The Log Management cluster has an integrated load balancer (its VIP is handled internally) — that one is not external. Nor is it the platform’s own Avi/NSX ALB, which VCF can deploy and lifecycle-manage for tenant / workload load balancing — that is a different service from the LB that fronts VCF Operations itself.

B.0 — Real-Time Metrics is a maintenance-window change, not an add-on

Field-observed 2026-07-22. Everything else in the table above deploys alongside the fleet. Real-Time Metrics (RTM) does not — it lands as extra worker capacity inside the VCF services runtime (VCFMS), the same runtime hosting fleet lifecycle, the Identity Broker and Log Management. That runtime was sized at bring-up for the components that existed then, so adding RTM makes it grow its node group, and the Add Real-Time Metrics wizard blocks INSTALL behind an acknowledgement:

To deploy the real-time metrics component you must first scale up VCF services runtime in the following VCF Instances: … Scale-up affects all of the VCF management services components for those VCF Instances and the operation must be performed during a maintenance window.

☐ I am aware of possible service disruption and want to continue with deployment

Plan it as a change window against the whole management-services runtime, not as an optional extra someone ticks on a Tuesday afternoon.

The size wording misleads. The wizard’s Review Resource Requirements dialog shows a Real-time metrics size — Medium on a Medium instance, needing 32 vCPU / 43 GB / 15 GB / 6 IP addresses. That is the size RTM will be deployed at, derived from the instance size. It is not a statement that the runtime already has room; a Medium instance sets RTM’s shape, it does not pre-provision capacity for it.

Before you start:

• 6 free IPs in the services-runtime block — this is why that block is recommended at /27 rather than /28 (see 01-network-dns-plan.md)
• The management cluster can absorb the extra vCPU / RAM, since the scale-up places new workers
• A maintenance window, agreed with whoever depends on fleet management

Also note the wizard’s own header: RTM “will be installed on all eligible VCF Instances. If any instance is added or imported after service installation, you need to manually install it there by repeating these steps.” So it is not self-propagating — a later instance needs its own pass, with its own window.

After deployment: it collects nothing until you enable it in a policy. This is the step that gets forgotten once the change window closes. Field-observed 2026-07-22.

• Where: Configurations → Policy Definition → select a policy (e.g. Base Settings → Default Policy) → the Real time metrics card → EDIT POLICY.
• Which objects — only two. The Select Object Type dropdown offers Host System (category ESX Top) and vCenter, both grouped under vCenter. No VMs, no datastores, no clusters — worth stating because secondary summaries of the 9.1 release notes claim real-time covers “VMs, hosts and datastores”, which is not what the policy editor exposes.
• It is off by default. ESX Top shows Deactivated (Inherited). A fleet can finish the deployment — scale-up, maintenance window and all — and still collect nothing, because no policy activates it.
• Scope it with groups. The policy’s Groups and Objects section is the per-object mechanism: put the hosts that need real-time granularity into a custom group and assign a policy with ESX Top activated, leaving everything else on the default. That avoids turning 2-second collection on fleet-wide.
• Granularity is set in the same policy — TechDocs: “You can configure the granularity of real-time metrics, which defaults to 20 seconds, to as low as 2 seconds for ESX metrics via policy-based configuration.”

None of this is in TechDocs. Deploy Real-Time Metrics covers version support (core components must be 9.1 or later), System Managed Credential for shared NSX, and port 443 connectivity to ESX hosts — but says nothing about a runtime scale-up, resource requirements, IP counts, maintenance windows or disruption. The warning exists only in the product.

B.2 — VCF Operations for Networks: IP-only, and a one-shot password

Field-observed 2026-07-22, and consistent with TechDocs Deploy VCF Operations for Networks.

There are no FQDN fields. The Add VCF Operations for Networks wizard runs Add Options → Parameters → Summary, and the Parameters page asks only for a Password, the Platform Node IP address (“Enter the static IPv4 address for the platform node”), the Collector Node IP address, and an optional Dual Stack toggle that “turns on IPv4 and IPv6 networking for the VCF Operations for networks nodes”. DNS, FQDN and hostname are not mentioned anywhere on that TechDocs page — matching intake E14, which already records these two as needing IPs only.

So DNS records are not required to deploy and nothing in the wizard consumes them. Create A + PTR for both nodes anyway — you will need them later.

The FQDN becomes mandatory at certificate replacement. Field-verified 2026-07-22. Ops for Networks does participate in fleet certificate management (its Generate CSR dialog runs with Common Name: OPS_NETWORKS-PLATFORM…), and in that dialog DNS/FQDN SAN is a required field — “Enter FQDN separated by a comma”. So a site that reads “IP-only” and skips DNS hits a hard stop at the certificate pass, which is a far worse moment to discover it than during Step 1 planning. The dialog also warns: “For multi-node/clustered deployment, FQDNs and IPs of all nodes must be provided” — so a Large (3-node) platform needs every node’s FQDN and IP, not just the two you deployed with.

Beyond the certificate requirement, the records earn their keep for runbooks and bookmarks that survive an IP change, firewall / proxy rules expressed by name, sensible identification in logs and support bundles, and consistency with every other appliance in the Step 1 plan. One limit worth stating plainly: an A record does not make the appliance use that name for anything — it is for you, and for the certificate.

The generated password is shown once and cannot be recovered. The Parameters page says “Save password to secure place. You won’t be able to see it again after the deployment”, and TechDocs adds that it “is used for the console-user, support, and admin@local accounts” — one secret, three accounts. COPY TO CLIPBOARD and RE-GENERATE are the only affordances on that screen. Put it in the credential store before you click Finish: this sits on the VCF Management side, where there is no reveal API to fall back on (see section F).

If Activate Network & Flow Collection is greyed out, restart your browser before anything else. Field-observed 2026-07-22. After a successful deploy, Network Operations → Network & Flow can still show the checkbox disabled with “VCF Operations for networks Appliance is required.” — a stale client-side capability flag, not a missing appliance. A browser restart enabled it immediately, with no fleet-side action. The message invites exactly the wrong conclusion (that the deployment failed) and the obvious “fix” is a second appliance you then have to clean up. Order of checks: confirm the appliance is listed under Build → Lifecycle → VCF Management → Components (the deployment task may sit under SDDC lifecycle, not Fleet lifecycle — see section D); then restart the browser / re-login; only then is there a real problem to investigate.

B.3 — Deployed outside VCF fleet management (Avi, License Hub)

Everything in section B comes from the Deploy Fleet Management Day-N sheet. These two do not — and that is exactly why they get forgotten. Both are Day-N appliance sets, both are substantial, and neither appears anywhere in the fleet Day-N tooling. Detail lives in prerequisites.md; this is the Day-N planner’s summary.

Three things that bite Day-N planners specifically:

• Avi controller sets are scoped to the NSX instance, not the workload domain. The wizard says so itself: “This Avi Load Balancer will automatically be deployed and linked to other workload domains sharing the same NSX manager…”. Count sets per NSX instance (04-sizing.md), not per WLD.
• License Hub needs an NSX DFW exclusion, not a firewall rule — a policy carve-out owned by the vDefend DFW owner, not the perimeter firewall team. See 07-firewall-ports.md §E.
• Licensing is a six-step chain, and deploying the hub is only step 2. Deploy → register → load the licence file → onboard each endpoint → assign → switch the endpoint to On-prem License Hub. Stop early and you have a healthy, fully-deployed, unlicensed fleet. Give the whole chain one owner. If the site already runs Avi on an older version, entitlement migration is a pre-upgrade gate with a hard 90-day clock (intake E16a).

C. Network placement — the options

This is the decision behind the “VCF Automation on a VPC network” question. The Day-N sheet offers four placements and a VPC is not one of them — but that is a limitation of the sheet and the wizard, not of the platform, so the table below carries five: the sheet’s four, plus the NSX VPC subnet (field-verified, API-only — see the subsection after the table).

The first four line up with the Broadcom design library’s four fleet-level components network models (Fleet-Level Components Networking Detailed Design) and the custom-networking deployment guidance:

The Installer exposes this same choice at bring-up. Plan → Network Options → Customize → Management Components Custom Networking defers VCF Operations + VCF Automation (plus their cloud proxy and license server); after bring-up you run the wizard’s third deployment path — Deploy deferred components — to place them on the vDS / NSX segment you prepared. The SDDC Manager API / VCF Operations methods below achieve the same for Day-N.

The sheet and the wizard offer no NSX VPC option — but the platform does support it, via the API (below). The design library adds a fifth, DR-oriented model — Dedicated VLAN + NSX Stretched Overlay Segment — which stretches the overlay via NSX Federation with a Global Manager (primary/secondary) so VCF Operations keeps its IP on region failover (no DNS repoint); see the design library’s stretched NSX overlay segment model.

The point of the non-shared options is to separate user-facing networks from management networks for regulatory / security requirements.

At Day-N, every non-shared placement is API-only. Field-verified 2026-07-21: the Day-N Add VCF Automation wizard (Fleet LCM, via VCF Operations) has no network picker at all — it asks only for the services runtime nodes CIDR and the FQDNs, and always uses the management network. So Dedicated Management Network, NSX Overlay Segment, NSX VLAN Segment and NSX VPC alike have to be deployed through the Fleet LCM API once the fleet is up. Section D has the procedure; it applies to all four, not just the VPC.

The exception is the deferred-components path. The VCF Installer’s third deployment path — Deploy deferred components, unlocked by the Management Components Custom Networking toggle at bring-up (see the callout above) — does place VCF Operations + VCF Automation onto a prepared vDS / NSX segment from a UI. That is a different wizard at a different point in the lifecycle. If you know the placement up front, that route avoids the API entirely; decide it before bring-up rather than after.

NSX VPC — one of the non-management placements

The first four placements in the table are what the Day-N sheet and the deployment wizard offer. They are not the limit of what the platform supports: VCF Automation can be placed on an NSX VPC subnet — the fifth row — and Broadcom’s own design library builds patterns on exactly that.

A VPC is not a special case mechanically — per the callout above, all the non-shared placements go through the same Fleet LCM API at Day-N. What makes the VPC worth its own section is that it is the one placement the sheet does not list at all, so there is nowhere else to record the decision.

From VCF Automation instance types — deployment:

“To provide an additional layer of network isolation, this deployment pattern also uses a second VPC for the VCF Automation instances.” “The DMZ VPC accommodates external facing services (like load balancers) and serves as a security barrier between the Internet and the internal application network.” “The Transit Gateway routes traffic between the two VPCs and to the upstream network, enabling safe channels of communication.” “Provider Admin can apply east/west firewall on the Mgmt App VPC to protect access to VCF Automation appliances.”

So the shape is a DMZ VPC for external-facing services, a Mgmt App VPC for the VCF Automation appliances, and a Transit Gateway routing between them and upstream — with east/west firewalling available on the app VPC. Broadcom names this Deployment Pattern 3: External-Facing Deployment of VCF Automation, and documents its own trade-offs and a gateway-architecture note worth carrying into the decision:

Benefits (per the design library): one set of VCF Automation appliances is easier to manage and update (lower operational overhead); isolating external-facing services from core management and workloads limits lateral movement; the DMZ-plus-load-balancer micro-segmentation exposes the service without weakening protection; traffic distributes across multiple appliance instances for scale and availability.

Drawbacks (per the design library): needs robust security already in place — firewalls, WAF, API security; a load-balancer misconfiguration can cause downtime or abnormal routing; the added network complexity (routing, firewall rules, per-tenant subnet allocation) needs careful planning.

CTGW or DTGW — both are supported. The design library’s own diagram for this pattern shows the Centralized Transit Gateway (CTGW) architecture, but the page states plainly that the Distributed Transit Gateway (DTGW) architecture is equally supported. So this pattern doesn’t force a connectivity model — the CTGW/DTGW choice you already made for the domain (01-network-dns-plan.md §B) carries through unchanged.

How you actually deploy it: through the Fleet LCM API, exactly like the other non-management placements — the VPC subnet is referenced by its networkMoId like any portgroup. See Deploying VCF Automation to a non-management network — API only in section D for the full procedure.

Field-verified 2026-07-21. VCF Automation deployed onto an NSX VPC subnet via the Fleet LCM API: validation passed, the node VMs landed on the VPC portgroup, the cluster came up and the Provider Management UI serves at /provider. Budget generous time — the platform returns 404, then 500, before it finally answers, and that progression is normal rather than a fault.

Choosing between them. If a VPC is not a requirement, one of the four sheet placements is the lower-friction path — they are wizard-driven, and the workbook has fields for them. Reach for a VPC when you need its isolation or the DMZ/Transit Gateway pattern above, and accept the API-only deployment route that comes with it.

Common prerequisites (all placements): the initial VCF fleet / instance deployment is complete; component binaries downloaded to VCF Installer; load balancer deployed if used; every appliance FQDN resolves to a unique IP (dual-stack: both A and AAAA). The NSX Overlay path additionally needs the Edge cluster, Tier-0 (BGP), Tier-1, and overlay segment above; the Dedicated path needs the dedicated port group + VLAN created first.

For any non-shared placement, the sheet splits the network into localRegion (the VLAN side — Ops collectors / Cloud Proxy) and xRegion (Ops + Automation), and asks for:

The cluster CIDR is the VCF Automation services-runtime internal node network — pick one of the sheet’s reserved ranges (198.18.0.0/15 default) and keep it distinct from every routed subnet in the Step 1 plan.

Two different CIDRs — don’t confuse them (#190). VCF Automation has both, and only one of them appears in the Add VCF Automation wizard:

	What	Where you set it
Nodes CIDR (routable)	A dedicated block on the VM Management subnet for the Automation nodes — the wizard’s VCF services runtime nodes CIDR field. Both Automation FQDNs resolve outside it	Add VCF Automation wizard
Internal cluster CIDR	198.18.0.0/15 (or 240.0.0.0/15 / 250.0.0.0/15) — platform-internal, never routed	API / JSON spec only — internalClusterCidrIpv4 via the fleet lifecycle API. Not exposed in the wizard

The wizard showing no internal-CIDR field is expected — it defaults. Override it only when 198.18.0.0/15 clashes with something you actually route, and then you must do it through the API.

D. VCF Automation — deployment method

The Day-N sheet’s method dropdown (“Select Option”) offers three choices; capture which one, as they ask for different inputs:

Both deploy paths need: VCF Automation FQDN, VCF services-runtime FQDN, node prefix, the node IP pool, and the admin password. Decide the method and the network placement (section C) together.

Size is the deployment model — they are not separate choices. TechDocs VCF Automation Models: the Simple model is “Single node. Applies to small appliance size” and High Availability is “Three node cluster. Applies to medium or large node sizes”. A small deployment “can be scaled out to the high availability model by resizing the node to Medium or Large, which automatically scales the deployment out to 3 nodes.”

Size	Nodes	Model
small	1	Simple
medium	3	High Availability
large	3	High Availability

This is why the Fleet LCM payload carries only "size" and has no HA flag — there is nothing else for it to key off. Capture the size; the model and node count follow from it. Note this also means you cannot have a large single node, nor a small HA cluster.

That services-runtime FQDN is Automation’s own — a second one. TechDocs’ FQDN/IP list carries “VCF services runtime — 1 FQDN” twice: once under VCF Automation (this one — intake E10, on a discrete IP outside the Automation /29 node range) and once under VCF Management Services (the fleet runtime created at bring-up — intake E14). The workbook repeats the same field label the same way. Plan and create both A + PTR records; using the bring-up fleet FQDN here is a common and confusing failure.

Both Automation FQDNs must resolve outside the CIDR you provide. The Add VCF Automation → Parameters step states it inline: “VCF Automation FQDN and VCF services runtime FQDN must resolve to IP addresses that fall outside of the provided CIDR.” Field-confirmed that the VCF services runtime nodes CIDR field takes a routable /29 from the VM Management subnet — so that /29 covers the nodes only (IP-only, no DNS records) and the two FQDNs each need their own discrete VM Mgmt IP on top of it. Budget /29 + 2, and see 01-network-dns-plan.md.

Deploying VCF Automation to a non-management network — API only

The Fleet LCM UI can only place VCF Automation on the management network. It also only accepts a CIDR for the node addresses, so the smallest legal input is a /29 — 8 addresses for a component that needs 5. Placing VCFA on anything else (a VLAN portgroup, an NSX overlay segment, an NSX VPC subnet) is API-only, and the API additionally accepts an explicit list of 5 IPs.

Credit. The API approach, endpoints and payload shape below are William Lam’s, from VCF 9.1 — Deploying VCF Automation (VCFA) to non-Management Network and his fleet_lcm_deploy_vcf_automation_to_different_network.ps1.

What failure looks like if you try it through the UI. The bootstrap aborts at pre-validation:

A pre-validation prevented the bootstrap: VCF services runtime FQDN is not on
the management network.
A pre-validation prevented the bootstrap: Not all addresses from the VCF
Management Services IPv4 pool are part of the management network range, which
is from <first> to <last>.
Failed to bootstrap VCF services runtime of type 'CONSUMPTION'.

Read that carefully: it is not saying your placement is unsupported. It is saying the fleet is validating against the management range — because the deployment network was never declared, and the fields that declare it do not exist in the UI. CONSUMPTION is the Automation runtime (as opposed to the management-services one).

Step 0 — the target network must already exist

Create the NSX VPC subnet or overlay segment first, and let it realise. The API takes a reference to an existing network (networkMoId) — it does not create one. Nothing downstream works until the network exists and vCenter can see it:

1. Create the network in NSX — an NSX VPC (its default subnets are created for you) or an overlay segment on a transport zone the management cluster is attached to. Note its gateway address and prefix while you are there; you need it verbatim later.
2. Confirm it reached vCenter. NSX pushes segments to vCenter as distributed portgroups, and there is a short lag. Until it appears in vCenter → Networking, it has no MoRef and cannot be referenced.
3. Check reachability from the target network back to SDDC Manager, vCenter and VCF Operations. Pre-validation does not test this, so a one-way route or a missing firewall rule surfaces late, mid-deployment.
4. Create the DNS records — A + PTR for both Automation FQDNs, resolving onto this network and outside the 5-address pool. Pre-validation does resolve them, so they must exist before you start.

Step 1 — get the networkMoId

A PowerCLI one-liner is enough:

Get-VDPortgroup -Name "vm-default-<hash>" |
    Select-Object Name, @{N='MoRef'; E={$_.ExtensionData.MoRef.Value}}

Get-VirtualPortGroup -Name "<name>" works too. The value looks like dvportgroup-58 — that string is what goes into networkMoId.

Without PowerCLI, select the portgroup in the vSphere Client and read the MoRef out of the browser address bar (.../dvPortgroup/dvportgroup-58/summary).

NSX VPC default subnets are named vm-default-<hash> and pod-default-<hash>. The vm-default one is the VM-facing subnet — that is the one to target. They appear as ordinary DISTRIBUTED_PORTGROUP entries alongside your VLAN portgroups.

Step 2 — the fields that declare the network

In vspClusterSpec:

The APIs involved — note the two different hosts:

Authentication happens on the VCF management-services runtime; everything else on the fleet lifecycle appliance. Swapping the two is the most likely first-run failure.

The token account is admin@vsp.local — the local admin of the VCF services runtime (VSP = VCF Services Platform, the name that also shows up in the “Bootstrap VCF Services Platform” task). It is not vSphere SSO and not the VCF Operations login, and it has no reveal API — it comes from the bring-up record or gets rotated.

Watch the right task list. An API-initiated deployment appears under SDDC lifecycle, not Fleet lifecycle where the UI-driven tasks show up: Build → Tasks → VCF Instances → <instance>, as “Creating VSP Cluster … in domain <domain>” / “Bootstrap VCF Services Platform”. Looking in the Fleet lifecycle list makes a perfectly healthy deployment look like it never started.

Two prerequisites that fail before networking is even reached:

• Depot. The Fleet Depot Service must have synced the VCFA binaries including the VCD Migration Engine component, or the deployment fails on missing binaries whatever the network looks like.
• New deployments only. Upgrades of an existing Aria Automation 8.x or VCF Automation 9.0.x/9.1.x reuse the network VCFA is already on — this path does not move an existing deployment.

The script

You do not have to hand-craft the payload — William Lam publishes a script that does validate-then-deploy, with a $ValidateOnly switch that defaults to $true.

Not our script. fleet_lcm_deploy_vcf_automation_to_different_network.ps1 is © 2022 William Lam, redistributed unmodified under the BSD 2-Clause Licence (full text). The mirrored copy adds only a provenance header carrying the copyright notice, the upstream URL and the SHA-256 of the pristine file, so it can be verified against the original. Everything else in this table of scripts is ours; this one is not — please credit William, not this project.

Run it with $ValidateOnly = $true first, and set $OutputJsonPayload = $true to inspect the payload before anything is sent — note that the printed payload contains the passwords in cleartext.

Single-quote the password — a $ in it will be silently eaten. Field-verified 2026-07-22 (#195). The script assigns the password in a double-quoted PowerShell string, and PowerShell interpolates $… inside double quotes. A password of VMware1!$ecret is sent as VMware1! — the $ecret expands to an undefined variable and disappears. There is no error and no warning, and the deployment succeeds: you get a healthy appliance built around a password nobody knows. Use 'single quotes' (literal in PowerShell), and confirm the literal value in the $OutputJsonPayload output before you deploy.

It does not present as a password problem — it presents as a broken appliance. The Provider UI (admin@vsp.local) rejects the login, SSH as vmware-system-user fails as well (a different credential — both are set from the same provisioning value, so they break together), changing the password from VCF Operations fails with “could not get a token”, and a power-cycle changes nothing. Two independent auth surfaces failing at once reads as a bootstrap fault, not a typo.

First diagnostic, 30 seconds: try the password truncated at the first $. If that logs you in, this is the bug — stop, and do not start a single-user-mode password reset. See If you are already locked out below.

If you are already locked out. Recovery is two-part, and doing only the obvious half leaves the appliance in a different broken state:

1. Console / GRUB root reset — KB 325916. At the Photon boot screen press e, append init=/bin/bash to the line beginning linux:, F10, then mount -o rw,remount / and passwd. Check lockout too — your own retries may have locked the account: faillock --user <user> and /usr/sbin/faillock --user <user> --reset (8.18.x+), or pam_tally2 on ≤ 8.16.x. Exit with reboot -f. Snapshot first.
2. Realign the Kubernetes secret — KB 419010. Resetting vmware-system-user with passwd misaligns the stored secret, and Fleet Management then shows the password Disconnected. Regenerate the hash (vmsp passwd --password-stdin, base64) and kubectl patch the vcf-mgmt-…-ssh-password-secret in namespace vmsp-platform, then wait up to 60 minutes before retrying password updates. That KB is scoped to 9.0.x — on 9.1 confirm the naming with kubectl get secrets -n vmsp-platform | grep ssh before patching anything.

Password shows Disconnected in VCF Operations → Fleet Management → Passwords is also a useful diagnostic on its own — it is visible in the UI with no SSH, and it distinguishes a misaligned secret from a wrong password.

If recovery is not viable — remove and reinstall

When the admin@vsp.local credential cannot be recovered, the alternative is removing VCF Automation cleanly and deploying it fresh. That procedure — the cleanup_component.py sequence, the VCFMS_USERNAME/VCFMS_PASSWORD credential to use, and the vsp-component/vsp-cluster delete order — is general-purpose (not specific to this non-management-network deployment path), so it now lives in its own doc: 16-remove-components.md.

Verification status (2026-07-21). Confirmed on a real deployment through three stages: the validation task returned SUCCEEDED, the deployment task was accepted and progressed, and the bootstrap VM appeared in vCenter attached to the target VPC portgroup — which is the stage that actually proves the placement was honoured rather than merely accepted.

Completed 2026-07-22 (#192). The deployment finished, the instance registered itself in VCF Operations → Components on its own (no manual sync or re-register — it simply lagged, so do not go chasing it), and login succeeded. The apparent lockout in between was not a deployment fault: it was the $-interpolation trap above (#195).

VCF Automation tenant billing — the Bills page needs a Cost currency set

A tenant organization’s Administer → Bills page in VCF Automation throws [<uuid>] Internal Server Error until VCF Operations’ cost currency is configured — and that setting is not the same as any “global currency” set elsewhere. [field-verified 2026-08-31]

VCFA’s Bills view is a front end onto VCF Operations cost/chargeback data. With no currency set, the cost engine produces nothing, no bill is ever generated, and VCFA returns a 500 rather than an empty state. Manage → Cost → Overview in VCF Operations shows the same cause plainly: “We couldn’t find any currency configured.”

Set it, then let it populate:

1. VCF Operations → Operate → Administration → Global Settings → Cost/Price → Currency → SET CURRENCY (e.g. EUR). The default is empty.
2. Cost Calculation on that same page is a daily scheduled job (default 21:00) — there is no manual “recalculate” in the UI. Wait for the next run after setting the currency (or have it restarted on the appliance).
3. Confirm a pricing card / chargeback policy is assigned to the org — Manage → Cost → Chargeback → Organizations. A Total Ongoing Price of - there means none is assigned.
4. Generate the first bill: Manage → Cost → Bills → GENERATE BILL.
5. Re-open the tenant’s Administer → Bills page.

If it still errors once cost has calculated and a bill exists, check that VCF Operations is registered — an unregistered / evaluation Operations shows a banner, and cost features can be gated behind entitlement.

E. DNS / IP checklist (additive to Step 1)

On top of 01-network-dns-plan.md, for every Day-2 appliance you deploy:

• Forward (A) + reverse (PTR) DNS for each node / VIP FQDN
• Reserved IP outside any DHCP scope
• If NSX Overlay: Edge cluster + centralized transit gateway + Tier-1 (Active/Standby) and the segment exist
• VCF services-runtime cluster CIDR does not overlap any Step 1 subnet
• Passwords captured with the other fleet credentials (intake section F)
• The synthetic check prerequisites (DNS/NTP/reachability) are in place

If Avi or License Hub is in scope (B.3) — neither is covered by the fleet Day-N workflows above:

• Avi cluster FQDN resolves before the deploy — the VIP is not a wizard input, so an absent A record has nowhere to be fixed later
• A separate Cluster Name decided, distinct from that FQDN
• The Avi bundle has synced to the depot (09-binary-depot.md)
• License Hub pool ranges settled first, then A + PTR for the 1st and 2nd service-pool addresses (instance + messaging FQDNs)
• Both License Hub pools are contiguous, unbroken blocks in one subnet
• The SSP Installer’s two files (~9.5 GB) are downloaded — they do not come through the depot
• vCenter root CA certificate to hand for the SSP Installer connection, and an admin credential + certificate per endpoint for onboarding
• The NSX DFW exclusion for the License Hub VMs is raised with the vDefend policy owner
• Certificates and passphrases captured: the Avi Passphrase is restore-critical (lost = no controller restore)

If VCF Automation is going on a non-management network (section D):

• Both Automation FQDNs have A + PTR before you start — the pre-validation resolves them
• Both resolve onto the target network, outside the 5-address pool
• The VPC subnet / overlay segment exists in NSX and is visible in vCenter — it has no MoRef until it has realised there
• networkMoId captured for that network (Get-VDPortgroup)
• gatewayCidrIpv4 is the gateway address with prefix
• The admin@vsp.local password is to hand (no reveal API)
• Fleet Depot Service has synced VCFA binaries incl. VCD Migration Engine
• Return path from the target network to SDDC Manager / vCenter / VCF Operations is open — pre-validation does not check it

F. Ownership matrix

G. Helper scripts

Once the fleet is up, SDDC Manager is the system of record for the accounts it provisions and rotates across each workload domain. When you need a managed component’s current password — to log into an ESXi host directly, to hand an auditor the service-account inventory, or to confirm a rotation actually took — read it back from the API rather than hunting through the interface. Download the script and run it (Windows PowerShell 5.1 or PowerShell 7; it prompts for whatever you don’t pass):

.\Get-VCFCredentials.ps1 -SDDCManager sddc01.sfo.example.io -ResourceType ESXI -SkipCertificateValidation

The VCF Management side is different — those passwords cannot be read. The management-plane accounts (VCF Operations, Automation, VCF services runtime) are handled by VCF Operations’ Password Management, which rotates and tracks expiry but has no reveal function — there is no API that returns those plaintext passwords. If you need one of those secrets, rotate it to a known value; you cannot retrieve the existing one.

The same script can still inventory those accounts (component, username, account type, expiry — no secrets) with -VCFOps, taking a -Credential just like the SDDC Manager mode. It reads them from an internal, unsupported VCF Operations API (/suite-api/internal/passwordmanagement) that Broadcom may change between builds.

Sign-off

Once A–G are filled and signed, feed the results back into the single-AZ planning docs and the workbook:

• Day-2 FQDNs + IPs → the DNS section of 01-network-dns-plan.md
• Non-shared placement network → the VLAN/subnet table in 01-network-dns-plan.md
• Decisions + method → intake A17 / E15 / B21 in 02-intake.md
• All values → the Deploy Fleet Management Day-N sheet (see workbook-cell-mapping.md)