Migrate a 2-node (ROBO) vSAN from Windows vCenter (v6.2) to a VCSA (v6.5)

One of my good friends from VMware Poland, Aleksander Bukowinski, contacted me recently on behalf of one of our customers. The customer wished to move their 2-node vSAN cluster and the witness to a new vCenter server. They were currently managing their vSAN with a Windows vCenter server (version 6.2), and wanted to move the vSAN cluster to a new appliance based vCenter Server (version 6.5), which we commonly refer to as the VCSA.

We discussed the steps we thought were needed, and these can be summarized as follows:

1. On the new vCenter create a new vSphere cluster and enable vSAN (manual mode).
2.  Assign a vSAN license to the new vSAN cluster.
3. On the old vCenter disconnect the ESXi hosts and the witness appliance.
4. Add one (only one) ESXi host to the new vSphere cluster.
5. Wait until the operation is fully completed and add other ESXi hosts, one by one.
6. Connect the witness appliance to the new vCenter. Do not add it to any clusters.
7. Login to the new vCenter as root.
8. Start RVC and run:
   # rvc [email protected]@localhost
   # vsan.stretchedcluster.config_witness <path_to_vsan_cluster> <path_to_witness_app> <preffered fault domain>
   e.g.:
   # vsan.stretchedcluster.config_witness /localhost/DC/computers/CLS /localhost/DC/computers/witness-1.vlab.net/host Preferred-FD
9. Refresh the Web Client and check if the configuration is reflected in “Fault Domains & Stretched clusters”
10. Check the vSAN health status if everything is fine

Step 8 has to be done via RVC, and not the UI. If tried via the UI, it requires that the witness is not part of any vSAN cluster, and the disks have to be clean/empty.

Aleksander first tested this out in his lab environment, and everything went well. He also deployed some virtual machines in his lab, and ensure that these were all still functional after the migration, which they were.

He then implemented the procedure at the customer’s site, and this also proceeded as expected. No issues to report. There was no need to remove the witness from the vSAN cluster, no need to destroy and recreate the disk groups, or do any resyncing of components. The next step would be to update the ESXi host to version 6.5 to get the full benefits of the 6.5 features.

Thanks Aleksander for sharing this with us. Kudos also to William Lam’s blog post here, which provided good guidance. The consensus is that the same workflow could be used for vSAN stretched clusters which has the same architecture to ROBO.