In the first part of the VCF 9.0 upgrade series, I walked through the process of upgrading the VCF Management Components — beginning with the Fleet Management Appliance and continuing through Aria Operations, Automation, Logs, and Network.
In this second part, we’ll shift focus to the core components of VMware Cloud Foundation, which form the backbone of every workload domain: vCenter Server, ESX hosts, NSX Managers, and Edge Clusters.
Since the core components have not yet been upgraded, the versions of the vCenter Server, NSX, and ESX hosts remain at 9.0.0, as shown in the screenshot below.
The next step is to download the required bundles, so navigate to Fleet Management → Lifecycle → VCF instance → Binary Management → Upgrade Binaries.
After verifying the component versions and downloading the required upgrade bundles, the first step in upgrading the core components is to upgrade the SDDC Manager. I began this process by running a precheck to ensure that all prerequisites were met before proceeding with the upgrade.
After the precheck completed successfully, I initiated the SDDC Manager upgrade by selecting “Update Now.”
After reviewing the message indicating that I would be temporarily disconnected from the SDDC Manager UI during the process, I proceeded to start the upgrade.
After approximately 20 minutes, the SDDC manager upgrade was completed successfully.
Next, I proceeded to upgrade the remaining core components. As always, I began by running a precheck to validate all prerequisites and ensure the environment was ready for a smooth upgrade process.
I then selected the target version and chose all the core components that I wanted to include in the precheck process.
After ensuring that I have no errors or prominent warnings, I will proceed with the upgrade.
By selecting ‘Configure Update‘, the NSX upgrade precheck will begin.
The process begins with the NSX Precheck, which provides an overview of the NSX upgrade workflow and validates that all required conditions are met before proceeding.
In my management domain, there are no Edge Clusters to upgrade, so I proceeded directly to the next step and started the precheck.
On the review page, an information banner appears, indicating that during the precheck phase, the NSX Upgrade Coordinator will be temporarily upgraded to perform a detailed validation. Once the precheck is completed, the Upgrade Coordinator will be automatically rolled back to its original state.
You can also review the upgrade sequence to see the detailed steps and order in which the NSX upgrade is being executed.
After the NSX precheck was completed, I proceeded by selecting “Schedule Update” to define when the NSX upgrade should begin.
At this stage, a review summary is displayed, showing details of the cluster configuration and whether host cluster sequential upgrade is enabled or disabled.
I selected “Update Now” and checked the box confirming that I had reviewed the precheck report and verified that the update was safe to apply.
When the upgrade begins, you can check the upgrade status by selecting ‘View Status’.
You can check the status of the upgrade by selecting View Status.
After the NSX upgrade is completed, I proceed to update the remaining core components.
In the upgrade Sequence, the next core component is the vCenter server.
After I initiated the vCenter Server upgrade, I received a message about the vCenter with Reduced Downtime Update, which helps reduce downtime for vCenter, but I needed to meet additional requirements.
It’s highly recommended to take a backup from the vCenter server before starting the upgrade to ensure a rollback is easy in case any problems occur.
For those who have upgraded vCenter before, you’re already familiar with the requirement to provide a temporary static IP address used during the upgrade process. This IP is assigned to a temporary virtual machine that vCenter uses to clone and migrate its configuration.
In VCF 9.0, this process has been simplified — the system now automatically assigns a temporary IP address during the upgrade. It uses a link-local network (169.254.0.0/16), configured directly between the source and target vCenter VMs, which removes the need to manually provide a static IP or rely on DHCP for temporary connectivity.
You can also choose between two preparation options:
- Immediate – the preparation phase starts right after the configuration is completed.
- Scheduled – allows you to specify an exact date and time for when the preparation phase should begin.
This flexibility enables easier alignment of upgrade preparation with maintenance windows and change management policies.
Additionally, you can choose whether the switch-over should occur automatically or be scheduled for a specific time.
In my case, I selected ‘Immediate’ for the Prepare Update phase and ‘Automatic’ for the Switchover phase, allowing the process to continue seamlessly once the preparation was complete.
You will then receive a summary of the option you have chosen for the upgrade, and you can proceed with initiating the upgrade.
After you start the upgrade, you can check the status of the activities.
After successfully upgrading vCenter as the final stage, I need to upgrade the ESX hosts.
To proceed with the ESX host upgrade, the first step is to create an upgrade image. For this purpose, I downloaded the required ESX installation bundle from the Broadcom Support Portal.
Then from the vCenter server → Lifecycle manager → Actions → Import Updates
Then, from Image Library → Create Image, I specified an Image Name, selected the desired ESX version, and optionally, I could add a Vendor Add-on or Firmware and Driver Add-on. Once the selections were made, I saved the configuration to create the upgrade image.
As the next step, I navigated to Fleet Management → Lifecycle → VCF Instance → Image Management → Import Image to upload the newly created ESX image into the environment.
I selected “Import from vCenter” as the source option and proceeded to import the ESX image into the environment.
After the image was successfully imported, I returned to my Management Domain to proceed with the ESX host upgrade.
At this stage, the Cluster Precheck process begins. It validates the selected clusters and assigned images to identify any potential compatibility issues before the upgrade continues.
In this step, the cluster to be upgraded is selected.
In this step, assign the previously created and imported image to the selected cluster.
After selecting the Image, select Assign Image and continue.
In this step, the Upgrade Options are configured to optimize the upgrade process. You can enable Quick Boot to reduce host reboot time and choose to migrate powered-off or suspended VMs automatically if a host enters maintenance mode. By default, clusters are upgraded in parallel to minimize overall upgrade duration.
Finally, a review summary is displayed, showing all the configurations and selections made. After reviewing the details, I selected “Run Precheck” to validate the configuration before starting the upgrade.
After the precheck completed successfully, I proceeded to schedule the upgrade to begin the ESX host update process.
I chose the “Update Now” option and confirmed that I had reviewed the hardware compatibility and compliance check results, verifying that the cluster image was safe to apply.
You can check the status of the upgrade.
After the ESX host upgrade completed, all hosts were successfully updated to version 9.0.1, and the cluster status showed as healthy and compliant.
The final step in the upgrade process—if your environment uses vSAN, is to upgrade the vSAN disk format version. To do this, navigate to:
vCenter Server → Cluster → Configure → vSAN → Disk Management.
Start by running the precheck Upgrade to validate the health and compatibility of all disk groups.
Once the precheck completes successfully, proceed with the Upgrade Disk Format task to bring all vSAN disk groups to the latest version, ensuring full compatibility with your upgraded VCF environment.
Before confirming the vSAN on-disk format upgrade, vCenter displays a warning that no data will be moved during the process. However, once the disk format is upgraded, you cannot roll back the software version or add older hosts to the cluster and I proceed with the upgrade.
After just couple of minutes the disk format successfully upgraded to version 22.0.
In the following article, I will cover how to upgrade vSphere Supervisor.