VCP-VCF study materials
VCP-VCF study resources

Upgrade Path from 4.5.x to 5.0 with a Mixed Workload Domain

VCP-VCF · Put your knowledge to work in context.

All case studies

Upgrade Path from 4.5.x to 5.0 with a Mixed Workload Domain

The SDDC Manager and management domain are at VCF 4.5.1 with ESXi 7.0 U3, vCenter 7.0 U3, and NSX-T 3.2.1. A workload domain was left at 4.5.0 with ESXi 7.0 U2, vCenter 7.0 U2, and NSX-T 3.1.3. The target is VCF 5.0, whose BOM uses ESXi 8.0, vCenter 8.0, and NSX 4.1. That workload domain has a two-node NSX Edge cluster with one edge node reporting degraded, and its vSAN cluster is at 78% capacity. The customer wants to upgrade the management domain first and then take the workload domain directly to 5.0 to save a maintenance window.

1. Is the proposed upgrade path valid? What sequence and prerequisite upgrades are required?

Read the worked answer

The direct workload-domain jump from 4.5.0 to 5.0 is not valid. VCF 5.0 must be entered from a supported 4.5.x source release, typically the latest 4.5.x release, not from 4.5.0. The management domain at 4.5.1 also needs to reach that source baseline.

Use a two-stage path. First upgrade SDDC Manager, the management domain, and the workload domain to the supported 4.5.x baseline, bringing the workload domain's ESXi, vCenter, and NSX to the 4.5.x BOM. Verify the BOM and health. Then upgrade SDDC Manager to 5.0, followed by the management domain and the workload domain to the 5.0 BOM. The workload ESXi 7.0 U2 and NSX 3.1.3 are below the source baseline and must be corrected in the 4.5.x stage, not skipped during the 5.0 stage.

2. How do the degraded edge node and 78% vSAN capacity affect the upgrade, and what would you do before scheduling it?

Read the worked answer

The degraded edge node is an NSX upgrade blocker. NSX upgrade prechecks require a healthy edge cluster, so resolve the edge node first: check power, network, controller connectivity, certificates, and whether it should be redeployed. Do not upgrade NSX with one edge node degraded.

vSAN at 78% leaves little slack for an ESXi 8.0 upgrade and any vSAN disk-format or policy work. Add capacity or move workloads so the cluster has adequate free space, confirm policy compliance, and ensure no resync is in progress. Validate the hosts against the target ESXi HCL. The upgrade window should not be scheduled until both the edge cluster and vSAN health are clean.

3. What backup and rollback plan would you require before starting?

Read the worked answer

Take and validate an SDDC Manager backup, vCenter backups, and NSX Manager backups before each stage. Confirm the restore procedure, not just the backup job success. Record the current BOM and component versions. Treat the upgrade as forward-only for major component versions; snapshots are not a supported rollback strategy for VCF components. Plan a maintenance window long enough to complete the 4.5.x baseline stage before attempting 5.0, and do not begin the 5.0 stage until the 4.5.x stage is healthy and backed up.