Moving a vSAN cluster from one vCenter Server to another
search cancel

Moving a vSAN cluster from one vCenter Server to another

book

Article ID: 326849

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

This article explains how to move a vSAN cluster from one vCenter Server to another vCenter Server.

Impact/Risks:

If performed within the parameters listed below, the migration will be seamless. However, if performed incorrectly, data availability may be temporarily affected until missing or misconfigured parameters are corrected.

Note: Moving a vSAN File Service enabled cluster from one vCenter to another is not supported, since the data associated with vSAN File Service cannot be migrated. 

Environment

VMware vSAN 6.x
VMware vSAN 7.0.x
VMware vSAN 8.0.x

Resolution

The following steps can be followed when migrating vSAN clusters from one vCenter to another vCenter and when the original vCenter is offline permanently or unable to be restored from backup.

Notes:

  • Always maintain current and tested VM backups of critical Virtual Machine workloads.
  • Review this document in its entirety before proceeding with the migration.
  • For stretched clusters, to disable stretched cluster from Fault Domains (Cluster > Configure > vSAN > Fault Domains > Stretched Cluster > Disable) prior to migrating the cluster to the new vCenter. Once the cluster has been fully migrated then enable stretched cluster again.
  • If forgot to disable stretched cluster in Fault Domains configuration or vCenter failed and had to be redeployed, see KB 77163

Base Steps:
1. Build a new vCenter server with a build version equal or greater than the version of the ESXi Hosts being migrated.
    Version differences may affect the Skyline vSAN Health services in rare cases. 

2. Prior to migrating the cluster, please be sure to test the vSAN VMkernel, Host Management, vMotion, and any additional dependent network routing schemes.

3. Determine if the host networking is configured with vDS, vSS, or NSX-T NVDS virtual switches.

- When using vSphere Standard Virtual Switch no additional steps are required other than ensuring the physical networking routes are working as designed.
- When using vSphere Distributed Switch, please reference further material/instruction KB links below to prepare the vDS for migration.

Note: While importing vDS settings, do not select preserve original distributed switch port group identifiers as this could negatively impact the migration.

- When using NSX-T NVDS with standalone host configuration, no additional steps are required other than ensuring the physical networking routes are working as designed.        

Note: If using Transport Node Profile for NSX-T NVDS, then need to migrate to standalone host configuration.

For more information on the migration of Hosts, see Moving an ESX/ESXi host with vDS from one vCenter Server to another
For more information on migration of vDS see  Exporting/importing/restoring Distributed Switch configs using vSphere Web Client

Backing Up and Restoring a vSphere Distributed Switch Configuration

For more information on vSphere see https://docs.vmware.com/

- Once the cluster networking configuration requirements are satisfied, then may proceed with the next steps of the migration.

4. Determine if vSAN Data at Rest Encryption is in use and make certain that keys and the KMS configurations are well known. See the guide for further guidance in preparing the cluster for migration.

Also, See further details in this instruction on step 7a.
Document: Using Encryption on a vSAN Cluster

5. Create a new cluster with DRS, vSphere HA, and EVC Disabled.  These options should only be enabled after the cluster is moved and stable on the new vCenter.

6. Create a new cluster Inventory object.

7.  a. Enable vSAN along with required services matching the original cluster parameters such as Encryption and or Deduplication and Compression.

       - If the original vCenter is not available to compare configurations, the following command can be used to list the vSAN services in use.

localcli vsan storage list |grep -i 'Device\|Is ssd\|Is Capacity Tier\|DEDUPLICATION\|COMPRESSION\|In CMMDS\|ENCRYPTION:' |sed 'N;N;N;N;;N;N;s/\n//g' | sort -k9;

        localcli vsan storage list |grep -i 'Device\|Is ssd\|Is Capacity Tier\|DEDUPLICATION\|COMPRESSION\|In CMMDS\|ENCRYPTION:' |sed 'N;N;N;N;;N;N;s/\n//g' | sort -k9;
                 Device: mpx.vmhba0:C0:T1:L0   Is SSD: true   In CMMDS: true   Deduplication: false   Compression: false   Is Capacity Tier: false   Encryption: true
                 Device: mpx.vmhba0:C0:T2:L0   Is SSD: true   In CMMDS: true   Deduplication: false   Compression: false   Is Capacity Tier: true   Encryption: true

      b. When KMS Encryption service is in use -
          Make certain to add the KMS servers to the newly built vCenter server with the same KMS-Cluster names and complete all required steps to add the KMS servers into the new vCenter server.

    • If it is not sure about the KMS cluster procedures, please reference KMS documentation and/or contact VMware Global Support to consult.
    • If it is unsure about the KMS cluster name and the original cannot be recovered, to obtain the KMS details about KMS-cluster info by using "esxcli vsan encryption kms list" and  "esxcli vsan encryption info get" on any of the hosts in the cluster, where vSAN encryption was enabled. Other additional information such as host-key and certs can be fetched using "esxcli vsan encryption hostkey get" and "esxcli vsan encryption cert get".     

          Example:
 

                # esxcli vsan encryption kms list
        Cluster               Name   KMS Address        Proxy Address  Proxy Port  Username
        --------------------  -----  -----------------  -------------  ----------  --------
        ####-KMS-Cluster      KMS-1  ##.###.##.##:####  N/A            N/A         N/A
     
        # esxcli vsan encryption info get
        Attribute            Value
        -------------------  -----
        kekId                ########-####-####-####-############
        dekGenerationId      1
        enabled              True
        hostKeyId            ########-####-####-####-############
        eraseDisksBeforeUse  False
        changing             False


           8. Create the Virtual Machine vSAN storage policies that match the vSAN policies from the old cluster. Ensure that rulesets have matching policies. If the VMs are migrated without matching policies, vSAN may need to perform a resync to ensure the VMs and objects are compliant.

If the policy names and policy attributes were unknown due to old vCenter unavailability, the following commands can be used to obtain the policy settings:

"esxcli vsan debug object list | grep spbmProfileId | sort | uniq" or "esxcli vsan debug object list | grep spbmProfileName | sort | uniq"
Review the attributes for each object using the policies by running "esxcli vsan debug object list |less" and search by the policy name (found above).

Example :

         # esxcli vsan debug object list | grep spbmProfileId | sort | uniq

           spbmProfileId: ########-####-####-####-############
           spbmProfileId: ########-####-####-####-############

         # esxcli vsan debug object list | grep spbmProfileName | sort | uniq

           spbmProfileName: VM Storage Policy-DN
           spbmProfileName: vSAN Default Storage Policy

An example is provided below of the policy attributes for the spbmProfileName: vSAN default storage policy

           Run Command: esxcli vsan debug object list | less

Example:

            Object UUID: ########-####-####-####-############
            Version: 10
            Health: healthy
            Owner: server.com
            Size: 15.00 GB
            Used: 0.89 GB
            Policy: ** CONTENT BELOW INDICATES POLICY ATTRIBUTES**
                cacheReservation: 0
                forceProvisioning: 0
                spbmProfileId: ########-####-####-####-############
                proportionalCapacity: 0
                spbmProfileGenerationNumber: 0
                stripeWidth: 1
                spbmProfileName: vSAN Default Storage Policy
                CSN: 16
                hostFailuresToTolerate: 1

            Configuration:

                RAID_1
                    Component: ########-####-####-####-############
                    Component State: ACTIVE,  Address Space(B): 16106127360 (15.00GB),  Disk UUID: ########-####-####-####-############,  Disk Name: naa.###############:2
                    Votes: 1,  Capacity Used(B): 486539264 (0.45GB),  Physical Capacity Used(B): 478150656 (0.45GB),  Host Name:server.com
                    Component: ########-####-####-####-############
                    Component State: ACTIVE,  Address Space(B): 16106127360 (15.00GB),  Disk UUID: ########-####-####-####-############,  Disk Name: naa.###############:2
                    Votes: 1,  Capacity Used(B): 486539264 (0.45GB),  Physical Capacity Used(B): 478150656 (0.45GB),  Host Name:server.com
                Witness: ########-####-####-####-############
                    Component State: ACTIVE,  Address Space(B): 0 (0.00GB),  Disk UUID: ########-####-####-####-############,  Disk Name: naa.###############:2
                    Votes: 1,  Capacity Used(B): 12582912 (0.01GB),  Physical Capacity Used(B): 4194304 (0.00GB),  Host Name:server.com

            Type: vdisk
            Path: /vmfs/volumes/vsan:###############-########-##############/########-####-####-####-############/VCSA####_6.vmdk (Exists)
            Group UUID: ########-####-####-####-############
            Directory Name: N/A

        
        
9. In vSAN 6.6 and above, it is critical to maintain vSAN virtual networking unicast communication between hosts on the vSAN network.  Please see KB for configuration details.


Configuring vSAN Unicast networking from the command line


10. Set the following configuration via CLI on each ESXi vSAN Cluster Member Host to be migrated.


esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

This will ensure when the hosts are disconnected from the original vCenter, they will not lose their unicast configurations and therefore their connectivity between hosts. If this step is skipped, the unicast address table will be cleared and data availability will be affected temporarily until the table is manually repopulated.


11. Run the command "esxcli vsan cluster get" from any hosts in the cluster and take note of the host count to ensure the count matches before and after the migration.


12. Disconnect one host from vCenter by right clicking the host and using the disconnect option. (**Not applicable if old vCenter is unavailable)


13. Remove the host from inventory. Make sure to follow KB 337625 if using a vDS  (**Not Applicable if old vCenter is unavailable)


14. Add the hosts only to the DataCenter level of the new vCenter inventory. Do NOT add the hosts directly to the new vSAN enabled cluster otherwise, the host will be forced into Maintenance Mode. (Avoiding Maintenance Mode is key for a seamless downtime migration.)


15. Once the host is registered in the new vCenter inventory, under the DataCenter Inventory Object, it can safely be dragged and dropped into the new vSAN enabled cluster from within the vCenter UI.

16. Before moving on to the next host, verify there is host-to-host vSAN communication. Run the command "esxcli vsan cluster get" from ESXi CLI and take note of the host count to ensure the count matches.

It is good to practice this command each time a host is disconnected, moved, and connected. If the host is not communicating, i.e. the host count is less than expected then it is highly likely a critical step has been missed. Please review the steps and ensure each host's unicast tables are complete and host-to-host communication on the vSAN network is fully functional.
To verify unicast agent table, use below command -


esxcli vsan cluster unicastagent list


17. Once the first host is moved and connectivity checks are performed, move forward with the remaining hosts. Please be certain to follow the steps carefully and check the cluster membership along the way to prevent any data availably impacts.

18. Once all hosts have been added to the new cluster and access to the VMs has been verified, revert the hosts' unicast table configuration. This procedure should be completed at the completion of the migration, and before the hosts are rebooted next. Host rebooting is not necessary for the procedure's success.


esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates
 

19. Again verify host and VM connectivity again by pinging the new vCenter from the management interface on each host.


20. Apply the vSAN storage policy to the VMs. 

 

Click OK. Assuming the policy is consistent with the old policy and all the hosts have remained in a healthy state, a resync shouldn't be triggered. It is recommended to perform this action, one at a time. The goal is to move gradually to prevent creating a major resync in the cluster.


21. Repeat this action for the remaining VMs. When performed correctly, there will be no reconfigurations/resyncs. If the VMs start resyncing then there is an inconsistency in the ruleset from the original to the new storage policies. Please allow the resync to complete before proceeding. 

 

 

22. Verify by browsing to Menu, Policies and Profiles, VM Storage Policies, desired storage policy, and VM Compliance.  All the VMs should be shown.

 

Additional Information