Migrating a vSAN cluster to a new vCenter

This blog post covers a quick write up of how I moved a vSAN cluster to a new vCenter in my homelab

A big warning here before we proceed. This was done in a LAB environment. Please make sure you take appropriate steps to make sure this won't break anything in a Production environment

In the setup used in this blog post we'll have four hosts. The vCenter is running the latest 8.0.2 version, the hosts is running 8.0.1 and the Cluster is running vSAN ESA. We have not enabled things like Encryption, File Services etc.

The migration procedure is documented in this official KB article from VMware.

Steps needed

Highlevel steps includes:

  • Deploy new vCenter
  • Ensure networking is working on existing hosts
  • Migrate vDS to new vCenter
  • Create new cluster object
    • Note! No services (HA, DRS) should be enabled
  • Enable vSAN on new cluster
  • Create vSAN policies on new vCenter
    • This step is needed to ensure minimal resyncing operation after migration
  • Maintain/document unicast networking
  • Prevent Cluster updates
  • Migrate networking on host to standard switch
  • Disconnect one host from old cluster
  • Connect host to new vCenter
    • Note! Do not add directly to cluster
  • Move host to new cluster
  • Migrate networking on host to vDS
  • Verify functionality
  • Move remaining hosts (one-by-one)
  • Enable cluster updates
  • Verify connectivity
  • Verify Storage Policies
  • Enable Cluster services (DRS, HA)

New vCenter

So we have a fresh vCenter deployed

New vCenter deployed

Verify existing operations

Now, let's check the existing cluster and ensure that there's no warnings on our existing hosts

Existing cluster

So we can see that we have four hosts and that there's no immediate errors in the cluster

Migrate vDS

The hosts have three vmkernel adapters, one for management, one for vSAN and one for vMotion. There's two different DVSwitches in play

Existing host networking

So we'll export the configuration of the two distributed switches

Export one of two switches

And we can go ahead and import the switches to the new vCenter

Import switch

Do not preserve existing identifiers

Do not select to preserve identifiers

After importing both configs, our two switches should be available in our new vCenter

Switches imported

Create cluster and enable vSAN

Create a new cluster, note that you do not have to keep the existing name

Create new cluster

Now let's enable vSAN on the cluster

Enable vSAN on cluster

Create Storage Policies

Next step is to create Storage Policies on the new cluster. Note that the default policies will be created once we enable vSAN on the cluster so this step is required for adding your own custom policies. Also, if you do not add these policies the cluster will function, but there will be some extra resyncing that needs to be done

Document and verify vSAN Unicast networking

Now we'll verify the unicast networking.

On each host we'll gather information about the IP and the UUID of the host to build the list. Then finally we'll on each host verify that it has the correct information about it's peers

The commands used in this example

1esxcli vsan network list
2esxcli network ip interface ipv4 get | grep <vmk>
3cmmds-tool whoami

Gather host information

In my example I have gathered information about the four hosts

Host UUID IP
192.168.110.111 64de08f0-8893-bc1d-3a38-a4ae111ca298 192.168.103.111
192.168.110.112 64ddf710-b616-0c62-21d9-a4ae111ca838 192.168.103.112
192.168.110.113 64ddcf68-8962-eca4-1ff2-a4ae111ca945 192.168.103.113
192.168.110.114 64de0e85-4cc5-d4f7-4e22-a4ae111caf28 192.168.103.114

And after gathering information about all hosts we'll run the verify unicast cmd on each host and compare to the unicast list

1esxcli vsan cluster get

Unicast list from a host

Note that the host you run the command on should not be in the list of hosts

A more detailed explanation about the unicast agent list can be found in this KB article

Prevent cluster updates

Now, we'll set the "IgnoreClusterMemberListUpdates" setting on each of the hosts

1esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

IgnoreClusterMemberListUpdates

Verify the cluster host count in vSAN cluster

Verify Cluster host count

Migrate networking to Standard switch

Now, before disconnecting the host from vCenter, please make sure that you take care of the networking of the host. This differs a lot between hosts and environments, e.g. multiple NICs, DV Switch vs Standard Switches etc.

In essence the point is to move one or more adapters to a Standard Switch on the host and migrate the networking over to this. You will need to add portgroups for the VMs on the Standard Switch and also the vmkernel adapters to avoid downtime.

Please refer to this KB article to learn more

Disconnect host from existing vCenter

Disconnect host from vCenter

Now, let's remove it from the inventory

Remove host from inventory

Connect host to new vCenter

The host is now ready to connect to the new vCenter. Note! Do NOT add the host directly to the cluster since this might put the host in maintenance mode. Add it to the Datacenter object first, and then move it to the cluster

Connect host

Move host to new cluster

And after the host has been connected we can move it to the cluster. I opted to fix the networking also before adding the host to the cluster.

Migrate networking to vDS

Before continuing on to the next host make sure that the networking is working and that the host can communicate with the other hosts, both on the management network and on the vSAN network.

Proceed with additional hosts

After connecting all hosts over to the new vCenter and moving them into the new cluster we should still be operational, but there is some final tasks to take care of

Verify cluster after moving all hosts

Cluster is operational on new vCenter

Now we'll verify the cluster from one of the hosts, and on each host we will turn on the ClusterList updates

1esxcli vsan cluster get
2esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates

Verify cluster and turn Cluster updates back on

Fix storage policies

Lastly we'll go over the Storage Policies and make sure that our VMs have the correct ones.

You might have to update the cluster optimal policy which this Skyline Health alert instructs you to

Skyline alert on policy

The Troubleshooting part of the alert let's us easily update the default

Update optimal policy

Make sure that you check the Skyline Health view frequently during this whole process, but also note that some of the alarms might fix themselves (e.g. Hosts contributing stats etc)

Enable cluster services

And lastly we can enable Cluster services like HA and DRS

This page was modified on March 24, 2024: vSAN migrate post