When building or expanding VMware Cloud Foundation (VCF) environments, administrators may occasionally encounter the error: "The vSAN host cannot be moved to the destination cluster."
This message can be caused by residual vSAN metadata that still exists on the host.
Understanding the Root Cause
Even after a host has been removed from a vSAN cluster, re-imaged, or repurposed for a new VCF workload domain, it may retain information from its previous vSAN membership. This hidden state can prevent the host from joining a new vSAN-enabled cluster.
Common remnants include previous vSAN cluster membership information, vSAN cluster UUID associations, disk group metadata, and orphaned or empty vSAN datastores.
How to Verify Existing vSAN Membership
Connect to the ESXi host via SSH and run:
This command displays the current vSAN cluster details known to the host, including cluster membership and UUID information.
Removing the Stale vSAN Association
If the host is still associated with a previous cluster, run:
esxcli vsan cluster leave
This removes the host's vSAN cluster membership and clears the associated configuration.
Afterwards, verify the status again using:
esxcli vsan cluster get
Adding the Host to the New Cluster
Once the stale vSAN state has been removed, return to vCenter Server and retry adding the host to the destination cluster. In most cases, the process will complete successfully.
Best Practices
• Properly remove hosts from vSAN clusters before decommissioning.
• Verify vSAN membership has been cleared before repurposing hardware.
• Check for residual vSAN datastores after re-imaging hosts.
• Include vSAN state validation in VCF host commissioning procedures.
Conclusion
The error typically results from leftover vSAN metadata rather than an issue with the destination cluster. Using esxcli vsan cluster get and esxcli vsan cluster leave allows administrators to quickly identify and remove stale cluster associations so hosts can be successfully added to their new vSAN environments.
