{{ $t('productDocDetail.guideClickSwitch') }}
{{ $t('productDocDetail.know') }}
{{ $t('productDocDetail.dontRemind') }}
6.11.3
{{sendMatomoQuery("Sangfor Cloud Platform (SCP)","Upgrade Methods")}}

Upgrade Methods

{{ $t('productDocDetail.updateTime') }}: 2025-12-18

HCI currently supports three methods. Active Upgrade (Quick Upgrade), Rolling Active Upgrade and Offline Upgrade.

Active Upgrade (Quick Upgrade):

A quick upgrade is applicable to upgrade scenarios with the same host OS kernel version and is commonly used for upgrading a minor version to another of the same series (for example, 6.7.0_R2 > 6.7.0_R3) or upgrading one version to another released within a short period of time (for example, 6.7.0 > 6.8.0). Specifically, all physical nodes are directly upgraded without changing the run location and running status of VMs in the cluster. With the process of active restart technology, a quick upgrade will only cause a business system jitter which will last for 3 seconds or less and will not interrupt the business system. A quick upgrade of the cluster takes a shorter time to complete.

Rolling Active Upgrade:

In the event of host OS changes or kernel or driver version upgrades, all clustered nodes must be restarted, which will cause business service interruption. With live migration technology, rolling active upgrades can significantly minimize the impacts on the services.

The rolling upgrade's functionality is migrating the VMs running on a node that needs to be upgraded to other nodes or clusters through live migration before restarting the node or cluster so that business services will not be interrupted. A rolling upgrade will not affect the business services, except that the live migration of VMs during the upgrade can cause business service fluctuations for about 1 second, and the overall upgrade process can be arranged.

The rolling upgrade will migrate production VMs running on nodes that need to be upgraded to other nodes in the same cluster and then migrate them back after the upgrade is complete and the upgraded nodes are restarted. The cluster to be upgraded must have sufficient resources.

Offline Upgrade:

Offline upgrade requires all clustered nodes to be restarted. All clustered nodes must be restarted in the event of host OS changes or kernel or driver version upgrades. The cluster restart requires all business VMs to be shut down, making the business system unavailable.