Moving vSAN 6.6 cluster from vCenter 6.5 to vCenter 6.7
Background.
A little bit of background for you folks, I wrote a blog post a little while ago on how to deploy a 6.5 VCSA appliance onto Oracle Ravello bare metal. On the back of this, I followed the vMusketeers excellent guide on creating a vSAN cluster on Oracle Ravello.
The issue I have now is at upgrade time, there is no easy way to upgrade the appliance from 6.5 to 6.7 as the VCSA installer expects to see an ESXi server that the VCSA appliance is running on. Running VCSA native on Ravello is not running it on an ESXi host, so the upgrade process fails. VCSA configuration backup and restore is also a none starter as the restore process has to restore to a VCSA that is the same version. If I really wanted to, I could create a backup of the VCSA running on Ravello, build another nested vCenter server on ESXi of the same build number and then import the config. This would then allow for an upgrade and export again back to Ravello.
The whole idea of the import/export was a step too far for me so I went ahead and built a new 6.7 VCSA, following the same procedures I outlined for building a 6.5 VCSA, and tben imported it into Ravello.
I also want to see what happens when a vSAN cluster is imported into a new vCenter server, does it break? Let’s find out!
Configure the 6.7 VCSA.
First steps after powering on the VCSA; create your data center, cluster and add licenses. Do not enable vSAN at this point.
1. DVSwitch.
Next, I wanted to retain the DVswitch config from my 6.5 VCSA. I exported the config from the 6.5 VCSA and imported it to the 6.7 VCSA as follows.
Navigate to the DVSwitch on VCSA 6.5 and export config.
Give the export a description.
Save the configuration export.
Browse to networking on VCSA 6.7 and import distributed switch.
Browse to the file that was exported earlier. I chose to preserve the original identifiers.
Confirm the settings.
And voilà.
2. Enable vSAN on the cluster.
William Lam has written a great blog post on what I am trying to achieve here. The next set of steps are based on Williams findings.
Enable vSAN on the cluster.
Ignore the warning and hit apply.
If this fails for some reason, reboot the VCSA appliance. I had this issue and after a reboot, the screen below also showed dedupe and compression options.
3. Prepare hosts and add to vCenter.
Ensure all the hosts are in vSAN maintenance mode. Log onto the CLI of the first host to be imported and run the following command IF this is a vSAN 6.6 cluster. Please refer to Williams post linked above for more info. Skip this step if vSAN version is older.
1 |
esxcli system settings advanced set -o /VSAN/IgnoreClusterMemberListUpdates -i 1 |
Start host import process. Right-click on the cluster and select add host. Type the hostname to be added.
Add credentials.
Review host summary.
Assign a license to host.
Configure Lockdown mode
Select VM location.
And finish.
4. Add the hosts to DVSwitch.
Once the host has been imported, the host uplinks need to be reassociated with the DVSwitch to allow host to host communications for vSAN traffic.
Select add and manage hosts on the DVSwitch
Select add hosts.
Select the host that has been imported.
Choose to assign uplinks.
You can see what switch the uplinks were assigned to onthe old vCenter which makes it easier for re-assignment.
In my case, uplink 1 is going to be assigned to the DVSwitch.
You end up with something like this.
Click next.
Click next.
You may have some VM networking to migrate at this point.
Finish.
5. Post host import.
Once the hosts have been added to the new vCenter server, the advanced config change that was made earlier needs to be changed back.
CLI input.
1 |
esxcli system settings advanced set -o /VSAN/IgnoreClusterMemberListUpdates -i 0 |
Repeat steps 3 to 5 for all additional hosts to be added to the vCenter server.
For good measure, I rebooted all the hosts after following steps 3 to 5.
vSAN status looking good after the fact.
And we are done.
Ian