I recently caught an interesting VMTN thread where a user wanted to move an exiting VSAN Cluster from one vCenter Server to another vCenter Server with minimal impact to the ESXi hosts and running Virtual Machines. The great news is that this can be done without any impact to your ESXi hosts and more importantly, there is no impact to your workloads. I have personally performed this operation on several occasions without any problems and the process is actually quite straight forward and thought I walk you through it because it is literally a couple of steps.

The main reason this is not a challenge is that VSAN has been architected to not have a reliance on vCenter Server for its normal operations. It is true that vCenter Server is required for the configuration and management of the VSAN Cluster and VM Storage Policies, but once those configurations have been applied, then the vCenter Server is no longer in picture from operational point of view. This means if you need to move your VSAN Cluster from a development vCenter Server to a production vCenter Server or if you accidentally destroyed your original vCenter Server, the VSAN Cluster can easily be re-created on a new vCenter Server.

To demonstrate the process, I have a 3 Node VSAN Cluster with a running Virtual Machine on vCenter Server (vcenter55-1) and I have built a new vCenter Server (vcenter55-3) which I would like to move the existing VSAN Cluster over to.

Step 1 - Deploy a new vCenter Server and create a vSphere Cluster with VSAN Enabled.

migrate-vsan-cluster-from-one-vcenter-to-another-0
Step 2 - Disconnect one of the ESXi hosts from your existing VSAN Cluster and then add that to the VSAN Cluster in your new vCenter Server.

Note: Technically, you do not even have to disconnect the ESXi hosts from the old vCenter Server. You could just add the ESXi hosts to the new vCenter Server and once you have confirmed you wish to move the ESXi host, it will automatically be disconnected once added. This would actually save you an extra step.

migrate-vsan-cluster-from-one-vcenter-to-another-1
Once you have successfully added the ESXi host, you should see a warning within the VSAN Configuration page stating there is a "Misconfiguration detected" which is expected. What is happening is that this ESXi has been configured in an existing VSAN Cluster and the ESXi hosts that it is supposed to be able to communicate with are not part of this VSAN Cluster. Once we add the remainder ESXi hosts, then the VSAN Cluster will be happy and this error will go away.

Note: If you try to add all of the ESXi hosts from the existing VSAN Cluster to the new VSAN Cluster at once, you will see an error regarding UUID mismatch. The trick is to add one host first and once that has been done, you can then bulk add the remainder ESXi hosts and you will not have an issue. This is handy if you are trying to automate this process.

Step 3 - Add the remainder ESXi hosts to the VSAN Cluster in the new vCenter Server. Once all hosts have been added to the new VSAN Cluster, you will see the warning icons disappear and your VSAN Cluster is now fully managed by the new vCenter Server. We can also confirm that there are no network partition as all original VSAN configurations have been retained on the ESXi hosts.

migrate-vsan-cluster-from-one-vcenter-to-another-2
Disclaimer: As mentioned there is no impact to the ESXi hosts (other than not being able to manage it while you disconnect and re-connect on the new vCenter Server) and there is no impact to the running Virtual Machines and any VM Storage Policies that have been applied to the VM will still be enforced by each of the ESXI hosts. However, one thing to be aware of is that the VM Storage Policies in your original vCenter Server will not be available in the new vCenter Server. You will need to re-create each of the VM Storage Policies and re-attach them to the existing Virtual Machines. This can of course be automated by using the vSphere API or leveraging the new PowerCLI 5.8 R1 release which includes VM Storage Policie cmdlets.

Here is an example of exporting a VM Storage Policy named "FTT=1" to a file called policy.xml on your desktop:

Export-SpbmStoragePolicy -StoragePolicy (Get-SpbmStoragePolicy -Name FTT=1) -FilePath C:\Users\Administrator\Desktop\policy.xml

Currently this is the only impact by moving a VSAN Cluster from one vCenter Server to another and of course this assumes you have created VM Storage Policies aside from the default policies.

I received a couple of questions regarding the networking setup for my VSAN Cluster. In the above example I was using VSS (Virtual Standard Switch). I did however, retest this scenario completely on VDS (Virtual Distributed Switch) and the results were the same. When all ESXi hosts have been added to the new vCenter Server, you will see a warning about proxy host switch. The key to properly migrating the networks (VMkernel & VM Portgroup) is to add each ESXi hosts to the new VDS that you will need to create. If you original vCenter Server is still available, you can export and import the VDS configuration. If it is not available, then you will need to manually re-create the Distributed Portgroups before proceeding.

The first step is to go to the Networking view and right click select "Add and Manage Hosts"

migrate-vsan-cluster-from-one-vcenter-to-another-3
Go ahead and walk through the guided wizard and make sure you only add one hosts at a time, as I saw issues when trying to add multiple hosts at a time. Once the ESXi host has been added to the new VDS and its uplinks, VMkernel and VM Portgroups are all connected. You should now see two VDS under the Networking view of ESXi host under "Manage".

migrate-vsan-cluster-from-one-vcenter-to-another-4
This can be seen clearly using the vSphere C# Client as it allows you to view both on the same screen. Once you have confirmed that the everything looks good, then you can go ahead and remove the old VDS switch as shown in the screenshot above. At this point, your ESXi hosts networking is now running on the new VDS. You will continue this same workflow for the remainder ESXi hosts until they all have been migrated over to the new VDS.

16 thoughts on “How to move a VSAN Cluster from one vCenter Server to another?

  1. Hi William,
    Thanks for your blog but I have a question. What type of virtual switch do you use? VSS or VDS?
    According to my testing, there is a problem for vDS if you use vDS. Of course VSAN is running well in the new vCenter. But since vDS is created in the old vCenter and the VSAN vmk is created on that vDS, you can’t do any operation related to vDS in the new vCenter.
    For example, you can not change the VSAN vmk ip address, can not change the uplink NIC, can not set traffic shaping, etc…

    • Victor,

      My setup was using VSS, however I just re-tested the scenario using VDS (VMkernel + VM Portgroup) and it does work. I’ve updated my article to provide the procedure that I used and I was able to migrate over. If you need to change the VSAN VMkernel IP, you should wait until the ESXi hosts have been migrated to the new VDS, either that or change the IP prior but I wouldn’t recommend performing so many changes as well as migrating to new VDS

  2. Hi, William!
    Thanks for your blog!
    I have question about moving hosts to new vCenter server.
    I have vSAN cluster of 5 hosts. 3 of them granted there disks groups to vSAN.
    I want to move only this 3 hosts to new vCenter.
    I did as you wrote.
    BUT!
    On each host I got error:
    Found host(s) participating in the Virtual SAN service which is not a member of this host’s vCenter cluster.

    My question is: How to delete this host, which i don’t move to new vCenter, from cluster configuration?

    • Hi Victor,

      You can not just migrate a subset of the 5 hosts who originally contributed storage to the VSAN Datastore. If you only wish to migrate 3, then you need to first ensure ALL data from the other two have been completely migrated off. This would also assume that the 3 hosts can run all workloads that were initially provisioned across the 5 hosts.

      This is the reason you’re seeing the message because VSAN knows that you’ve only migrated a portion of its capacity. If you delete or destroy the remainder two hosts, then you will negatively impact your environment.

      • William, yes, I already migrated all workloads.
        I just need to reconfigure vSAN to FORGET about 2 of my UNNECESSARY hosts.

        • When you say “migrated all workloads” its not just the VMs but ensure you have migrated the actual data off of the disks on those 2 hosts as well. Remember, data in VSAN is distributed across all hosts contributing storage. You can do this by placing the host into maintenance mode using the vSphere Web Client and you will have several options on VSAN mode, one of which is full data migration. Once that’s been done, you can then remove the hosts from the VSAN Cluster

          • Yes, I migrated ALL.
            But, as I understand, all of 3 hosts, that I try to connect to NEW vCenter REMEMBER about 2 another hosts, which left on OLD vCenter.

  3. Hi William,

    I have the following scenario:

    One vCenter Server managing several Clusters, including a vSAN Enabled Cluster. In that vSAN Cluster ( 3 hosts ) I have deployed a new vCenter Server ( VCSA + External Oracle DB ). The objective is to migrate all hosts from all the clusters to this new vCenter Server and ditch the old vCenter Server.

    The difference of my scenario from yours is that the new vCenter Server in actually residing on the vSAN Cluster that I intend to migrate first.

    It seems to me that the operation will be peaceful, but I just want to make sure that I am not overlooking any detail.

    Thank you on your comments,

    Regards,
    _
    Pedro.

    • Pedro,

      Yep, this will work perfectly fine. Once VSAN has been configured, it’ll continue to work with or without VC (similiar to HA) and of course you won’t be able to make any configuration changes until you have access back to VC.

  4. Hi William,

    is it advisable to change the vSAN vmkernel IPaddress in the existing configuration.Currently we using the management & VSAN in different vswitch with same vlan. Planning to change the vSAN network to a different vlan.

  5. Hi William!

    Would there be any additional considerations when moving a VSAN cluster from vCenter 5.5 to vCenter 6?

    I am imagining that any additional complications should only surface post move when I decide to upgrade to VSAN 6. Is that correct?

  6. Hi William, how easy/hard is it to change an existing set of VSAN vmkernel IP addresses? I have a 6 node cluster and want to change the last octet on each vsan vmkernel to a slightly lower number. The subnet, gateway and vlan all stay the same.. Have you tried this? thanks Paul.

  7. Greetings William,
    Great and very informative site!! So far, I’ve learned a ton – Thank you!!

    I have a few questions about migrating VMs from 1 datacenter to another datacenter. We’re relocating our datacenter to another site that we already have. One little twist, we’re planning on upgrading our current version vSphere 5.1 to 5.3 U3 on the new hardware. Also, we’re not using vStack. We’re strictly Fiber channel shop.

    Should I move our current vSphere cluster first and then do the upgrade? The pipe between the location is only 100MB pipe.

    Please let me know what else you need on my end before you can give me a recommendation.

    Thank you,

    Joe Peterson

  8. I’ve got an interesting problem WRT VSAN. I have a host that was in a VSAN cluster, it did not contribute any disk space to the cluster, it was just a user of the VSAN. I moved that host to a different vCenter, but the host still thinks it should have access to the VSAN in its old cluster. How do I tell it that the VSAN is no longer available?

  9. Awesome work. Here some updates concerning Streched Clusters (vSpehre 6)

    Move Stretched Cluster
    • Unconfigure Stretched
    • Move Hosts one after another
    • Move Witness
    • (remove witness from cluster manual if it didnt work)
    Esxcli vsan cluster leave
    • Remove disk groups from Witness
    esxcli vsan storage remove -s mpx.vmhba1:C0:T1:L0
    • Reconfigure Streched

Thanks for the comment!