This video demonstrates how to troubleshoot Virtual SAN on-disk format upgrade to 3.0, which may fail in small Virtual SAN clusters or ROBO/stretched clusters.
Attempting an on-disk upgrade in certain VSAN configurations may result in failure. Configurations that can cause these errors include:
- The stretched VSAN Cluster consists of two ESXi Hosts and the Witness Node (ROBO configuration)
- Each Host in the Stretched Cluster contains a single VSAN Disk Group
- A Virtual SAN cluster consists of three normal nodes, with one disk group per node
- A Virtual SAN cluster is very full, preventing the “full data migration” disk-group decommission mode
To allow an upgrade to proceed in these configurations, a compromise as to availability must be made. Data accessibility will be maintained, but the redundant copy of the data will be lost and rebuilt during the upgrade process. As a result, data will be exposed to faults and failures such as the loss of a disk on another node may result in data loss. This exposure to additional failure risk is referred to as “reduced redundancy,” and must be manually specified in the Ruby vSphere Console (RVC) to allow the upgrade to proceed. It is not possible to specify reduced redundancy when using the vSphere Web Client to start the upgrade.
Caution: During upgrade, a single point of failure is exposed. Follow all VMware best practices, and your business practices, regarding the backup of important data and virtual machines.
The post Troubleshooting Virtual SAN on-disk format upgrade to 3.0 failures appeared first on Support Insider.