• Target: four sites, two VCF instances, one fleet. Instance 1 covers Site A and Site B, Instance 2 covers Site C and Site D, and one VCF Operations plus one VCF Automation manage the whole fleet.
• Fleet level services (fleet lifecycle, software depot, license server) run only on the first instance. Every extra instance deploys just VCF Services Runtime, Salt master and SDDC lifecycle, and shares the rest.
• Decide which site becomes the first instance before you start. You cannot relocate an instance after it joins a VCF 9.1 fleet.
• Convert on the current versions: reuse vSphere 8 Update 3, NSX 4.2.x and Avi in place, then upgrade later with Lifecycle Manager.
• Order per site: converge the primary site of each instance, import the second site as a workload domain, integrate the second instance into the fleet, then upgrade.
• Prerequisites: vSphere 8 Update 3 at every site, VCF Installer for the target build, backups, and consistent DNS and NTP across sites.

A customer runs four sites on vSphere 8 with NSX 4.2.x and Avi load balancer. They want a single VCF 9.1 fleet, but not a single instance. Two sites, A and B, should sit in one instance, and the other two, C and D, in a second instance, with one fleet management layer over both. This part shows how to reach that layout with the convert first approach, so nothing is upgraded before it is under management.

You will converge each environment on its current versions, stand up the fleet on the first instance, join the second instance to the fleet, bring Avi under management, then upgrade every component to 9.1 through Lifecycle Manager. For the underlying mechanics of a single conversion, read Part 22, and for attaching an existing vCenter, read Part 21.

A VCF fleet is one or more VCF instances managed by a single VCF Operations and a single VCF Automation. Fleet level components, meaning fleet lifecycle, the software depot and the license server, run only on the first instance. Every additional instance deploys just VCF Services Runtime, a Salt master and SDDC lifecycle, and consumes the shared services from the first instance. In this scenario Instance 1 is the first instance, so it carries the fleet services, and Instance 2 is lighter and points back to Instance 1.

There is no supported way to relocate a VCF instance once it has joined a VCF 9.1 fleet. Choose which site is the first instance, and which sites belong to which instance, before you converge anything. Confirm that the two sites in each instance sit within the management latency VCF supports.

Fix the design before any conversion. Because an instance cannot move between fleets later, this decision is final in practice.

• Pick Site A as the first instance, so Instance 1 carries the shared fleet services.
• Assign Site B to Instance 1, and Sites C and D to Instance 2.
• Confirm the two sites in each instance meet VCF management latency limits.
• Reserve management IP ranges, FQDNs and a spare IP per vCenter for the later upgrades.

Run a dry validation at each site days ahead of its window.

Site A becomes Instance 1 and brings up the fleet management layer.

Site B joins Instance 1 as a workload domain, on its current version.

Site C becomes Instance 2. It does not repeat the fleet services, it shares them from Instance 1.

Each site keeps its Avi load balancing. You register the existing Avi with the fleet, and for small footprints VCF 9.1 can deploy a single node Avi cluster from VCF Operations. For a full walkthrough of Avi in VCF, see Part 12.

All four sites are now under one fleet, still on 8.x. You do not upgrade by hand. Lifecycle Manager, called LCM, runs each upgrade. For every component the job is the same: pick it, run a precheck, then start it. LCM enforces the order and blocks a failed precheck.

Run the same loop for each component, one instance at a time:

The order LCM follows is VCF Operations, then SDDC and Fleet, then NSX, then vCenter, then ESXi, then NSX Edge, and finally Avi. Because the sites start on NSX 4.2.x, LCM may move NSX to 9.1 in two hops, each its own window. Upgrade Instance 1 first, then Instance 2.

Convert all four sites before you start any upgrade. That way every site is under management and recoverable, and you can run the upgrade windows for the two instances on separate schedules.

• One fleet shows two instances in VCF Operations, and all four sites appear as managed domains.
• Fleet services run on Instance 1, and Instance 2 reports that it shares them.
• Certificate and password management has moved to VCF at every site.
• Avi reports healthy for each domain that uses it.
• The Software Depot is reachable and prechecks pass for the next component.
• After upgrade, NSX, vCenter, ESXi and Avi are on 9.1 and interoperability is green.

Why two instances instead of one
Two instances keep each pair of sites in its own management and lifecycle boundary while one fleet gives unified operations. It suits customers who want separation between site groups but a single pane for the whole estate.

Do both instances need their own VCF Operations
No. One VCF Operations and one VCF Automation manage the whole fleet. Only the first instance runs the fleet services, and the second instance shares them.

Can I convert all four sites at once
You can run the site conversions in parallel where staffing allows, since each converts on its own versions. Build Instance 1 first though, because it hosts the fleet services the second instance depends on.

What happens to Avi during the move
Avi is reused in place, registered with the fleet, and upgraded last through LCM. Small sites can use a single node Avi cluster deployed from VCF Operations.