During one of the upgrades in my VCF lab, I accidentally installed an ESXi 7.x build outside that VCF release’s validated design. This historical example records the lab recovery I tried. It is not a general production downgrade procedure.

Warning: For a VCF-managed host or a production downgrade, stop and engage Broadcom Support. Downgrading can remove or replace drivers and components, can be incompatible with the current vCenter/NSX/firmware combination, and might leave the host unable to boot or rejoin its cluster. Use a supported rollback, reinstall or restore procedure when directed.

ESXi 7 reached End of General Support on October 2, 2025. This page preserves the original lab target; it is not a recommendation to deploy or remain on ESXi 7.

Prepare the Host and Enter Maintenance Mode

Broadcom’s current esxcli patching procedure requires maintenance mode before applying an image profile. Before attempting any version change:

  • Confirm the exact supported recovery method and compatibility of the target build, server firmware, hardware, vCenter Server and integrated products.
  • Take and verify an ESXi configuration backup. Ensure installation media and a tested recovery route are available; not every version change can be rolled back from the alternate boot bank.
  • Migrate or shut down every user VM. DRS can evacuate workloads when configured; do not manually power off or migrate vCLS VMs unless Broadcom Support directs you to do so.
  • Confirm that the remaining hosts can satisfy the intended vSphere HA failover policy while this host is unavailable.
  • For vSAN, verify health and object compliance, confirm there are no active resynchronizations, select the appropriate data-migration mode, and wait for evacuation to finish. Do not choose No data migration without understanding the availability risk.
  • For an NSX-prepared host, verify that the target ESXi build and NSX kernel modules match the supported sequence in Broadcom KB 312013.

Enter maintenance mode from the vSphere Client, then confirm the state from the ESXi shell:

vim-cmd hostsvc/hostsummary | grep inMaintenanceMode

Continue only when the result is true.

Finding the Historical Target in an Offline Bundle

The original public online depot is retired, so its executable URL has been removed. If Broadcom Support directs you to use a particular offline bundle, upload that exact artifact to a datastore and set its path:

OFFLINE_BUNDLE='/vmfs/volumes/DATASTORE/updates/APPROVED_ESXI_DEPOT_BUNDLE.zip'
esxcli software sources profile list -d "$OFFLINE_BUNDLE"

In this historical lab I was specifically looking for build 18426014, so I filtered the same bundle output:

esxcli software sources profile list -d "$OFFLINE_BUNDLE" | grep 18426014

The command above returned 2 versions for me. One with VMware tools and one without

ESXi-7.0U2c-18426014-standard     VMware, Inc.  PartnerSupported  2021-08-24T00:00:00  2021-08-24T00:00:00
ESXi-7.0U2c-18426014-no-tools     VMware, Inc.  PartnerSupported  2021-08-24T00:00:00  2021-08-04T11:40:25

We are specifically interested in the first part of each line

ESXi-7.0U2c-18426014-standard and ESXi-7.0U2c-18426014-no-tools

Running the Downgrade with –allow-downgrades

I first tried the ordinary profile-update form:

esxcli software profile update -p ESXi-7.0U2c-18426014-standard -d "$OFFLINE_BUNDLE"

Without the explicit downgrade option, profile update applies updates and new VIBs rather than lower versions. In this lab, --allow-downgrades was the option that permitted lower VIB versions. That flag is not approval to use this recovery method in another environment. With an exact support-approved target, run only the dry-run form first:

esxcli software profile update --dry-run --allow-downgrades -p ESXi-7.0U2c-18426014-standard -d "$OFFLINE_BUNDLE"

Only after that output is clean and the downgrade is explicitly approved should the live command be run separately:

esxcli software profile update --allow-downgrades -p ESXi-7.0U2c-18426014-standard -d "$OFFLINE_BUNDLE"

Reviewing the Result and Rebooting

This actually installed the lower versions of the packages associated with that build number and removed the later packages. The output in my case was

Update Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMware_bootbank_clusterstore_7.0.2-0.20.18426014, VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014, VMware_bootbank_crx_7.0.2-0.20.18426014, VMware_bootbank_esx-base_7.0.2-0.20.18426014, VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014, VMware_bootbank_esx-update_7.0.2-0.20.18426014, VMware_bootbank_esx-xserver_7.0.2-0.20.18426014, VMware_bootbank_gc_7.0.2-0.20.18426014, VMware_bootbank_loadesx_7.0.2-0.20.18426014, VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014, VMware_bootbank_vdfs_7.0.2-0.20.18426014, VMware_bootbank_vsan_7.0.2-0.20.18426014, VMware_bootbank_vsanhealth_7.0.2-0.20.18426014
   VIBs Removed: VMware_bootbank_clusterstore_7.0.2-0.25.18538813, VMware_bootbank_cpu-microcode_7.0.2-0.25.18538813, VMware_bootbank_crx_7.0.2-0.25.18538813, VMware_bootbank_esx-base_7.0.2-0.25.18538813, VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.25.18538813, VMware_bootbank_esx-update_7.0.2-0.25.18538813, VMware_bootbank_esx-xserver_7.0.2-0.25.18538813, VMware_bootbank_gc_7.0.2-0.25.18538813, VMware_bootbank_loadesx_7.0.2-0.25.18538813, VMware_bootbank_native-misc-drivers_7.0.2-0.25.18538813, VMware_bootbank_vdfs_7.0.2-0.25.18538813, VMware_bootbank_vsan_7.0.2-0.25.18538813, VMware_bootbank_vsanhealth_7.0.2-0.25.18538813
   VIBs Skipped: VMW_bootbank_atlantic_1.0.3.0-8vmw.702.0.0.17867351, VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014, VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014, VMW_bootbank_brcmfcoe_12.0.1500.1-2vmw.702.0.0.17867351, VMW_bootbank_brcmnvmefc_12.8.298.1-1vmw.702.0.0.17867351, VMW_bootbank_elxiscsi_12.0.1200.0-8vmw.702.0.0.17867351, VMW_bootbank_elxnet_12.0.1250.0-5vmw.702.0.0.17867351, VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014, VMW_bootbank_iavmd_2.0.0.1152-1vmw.702.0.0.17867351, VMW_bootbank_icen_1.0.0.10-1vmw.702.0.0.17867351, VMW_bootbank_igbn_1.4.11.2-1vmw.702.0.0.17867351, VMW_bootbank_irdman_1.3.1.19-1vmw.702.0.0.17867351, VMW_bootbank_iser_1.1.0.1-1vmw.702.0.0.17867351, VMW_bootbank_ixgben_1.7.1.35-1vmw.702.0.0.17867351, VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014, VMW_bootbank_lpnic_11.4.62.0-1vmw.702.0.0.17867351, VMW_bootbank_lsi-mr3_7.716.03.00-1vmw.702.0.0.17867351, VMW_bootbank_lsi-msgpt2_20.00.06.00-3vmw.702.0.0.17867351, VMW_bootbank_lsi-msgpt35_17.00.02.00-1vmw.702.0.0.17867351, VMW_bootbank_lsi-msgpt3_17.00.10.00-2vmw.702.0.0.17867351, VMW_bootbank_mtip32xx-native_3.9.8-1vmw.702.0.0.17867351, VMW_bootbank_ne1000_0.8.4-11vmw.702.0.0.17867351, VMW_bootbank_nenic_1.0.33.0-1vmw.702.0.0.17867351, VMW_bootbank_nfnic_4.0.0.63-1vmw.702.0.0.17867351, VMW_bootbank_nhpsa_70.0051.0.100-2vmw.702.0.0.17867351, VMW_bootbank_nmlx4-core_3.19.16.8-2vmw.702.0.0.17867351, VMW_bootbank_nmlx4-en_3.19.16.8-2vmw.702.0.0.17867351, VMW_bootbank_nmlx4-rdma_3.19.16.8-2vmw.702.0.0.17867351, VMW_bootbank_nmlx5-core_4.19.16.10-1vmw.702.0.0.17867351, VMW_bootbank_nmlx5-rdma_4.19.16.10-1vmw.702.0.0.17867351, VMW_bootbank_ntg3_4.1.5.0-0vmw.702.0.0.17867351, VMW_bootbank_nvme-pcie_1.2.3.11-1vmw.702.0.0.17867351, VMW_bootbank_nvmerdma_1.0.2.1-1vmw.702.0.0.17867351, VMW_bootbank_nvmxnet3-ens_2.0.0.22-1vmw.702.0.0.17867351, VMW_bootbank_nvmxnet3_2.0.0.30-1vmw.702.0.0.17867351, VMW_bootbank_pvscsi_0.1-2vmw.702.0.0.17867351, VMW_bootbank_qcnic_1.0.15.0-11vmw.702.0.0.17867351, VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014, VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014, VMW_bootbank_qfle3_1.0.67.0-14vmw.702.0.0.17867351, VMW_bootbank_qfle3f_1.0.51.0-19vmw.702.0.0.17867351, VMW_bootbank_qfle3i_1.0.15.0-12vmw.702.0.0.17867351, VMW_bootbank_qflge_1.1.0.11-1vmw.702.0.0.17867351, VMW_bootbank_rste_2.0.2.0088-7vmw.702.0.0.17867351, VMW_bootbank_sfvmk_2.4.0.2010-4vmw.702.0.0.17867351, VMW_bootbank_smartpqi_70.4000.0.100-6vmw.702.0.0.17867351, VMW_bootbank_vmkata_0.1-1vmw.702.0.0.17867351, VMW_bootbank_vmkfcoe_1.0.0.2-1vmw.702.0.0.17867351, VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014, VMW_bootbank_vmw-ahci_2.0.9-1vmw.702.0.0.17867351, VMware_bootbank_elx-esx-libelxima.so_12.0.1200.0-4vmw.702.0.0.17867351, VMware_bootbank_esx-ui_1.34.8-17417756, VMware_bootbank_lsuv2-hpv2-hpsa-plugin_1.0.0-3vmw.702.0.0.17867351, VMware_bootbank_lsuv2-intelv2-nvme-vmd-plugin_2.0.0-2vmw.702.0.0.17867351, VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-5vmw.702.0.0.17867351, VMware_bootbank_lsuv2-nvme-pcie-plugin_1.0.0-1vmw.702.0.0.17867351, VMware_bootbank_lsuv2-oem-dell-plugin_1.0.0-1vmw.702.0.0.17867351, VMware_bootbank_lsuv2-oem-hp-plugin_1.0.0-1vmw.702.0.0.17867351, VMware_bootbank_lsuv2-oem-lenovo-plugin_1.0.0-1vmw.702.0.0.17867351, VMware_bootbank_lsuv2-smartpqiv2-plugin_1.0.0-6vmw.702.0.0.17867351, VMware_bootbank_qlnativefc_4.1.14.0-5vmw.702.0.0.17867351, VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.42-1vmw.702.0.0.17867351, VMware_locker_tools-light_11.2.6.17901274-18295176

I then rebooted the server while it remained in maintenance mode.

After the host has finished booting, verify the version and active profile, then validate management networking, physical NIC and storage drivers, datastores and cluster health:

vmware -vl
esxcli software profile get

For a vSAN host, wait for any resynchronization and confirm object health. For an NSX-prepared host, confirm transport-node and datapath status. Exit maintenance mode only after all validation succeeds:

vim-cmd /hostsvc/maintenance_mode_exit