Cross vCenter Migration (xVMotion) Supportability for Virtual Machines Consuming CNS-CSI Persistent Volumes

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

^{Administrators managing vSphere environments with Kubernetes workloads may attempt to perform a Cross vCenter Migration (xVMotion) to move virtual machines—specifically Kubernetes worker nodes—from one vCenter Server to another.}

^{Common question regarding this operation include:}

• ^{Is Cross vCenter Migration supported for virtual machines utilizing the vSphere Container Storage Plug-in (CNS-CSI)?}

^{Important Clarification: While standard Storage vMotion within the same vCenter Server is fully supported, Cross vCenter Migration (xVMotion) is explicitly NOT supported for virtual machines consuming Persistent Volumes (PVs) provisioned via the CNS-CSI driver.}

Cause

^{This limitation is due to the architectural design of the Cloud Native Storage (CNS) control plane.}

^{When the vSphere CSI driver provisions a Persistent Volume for a Kubernetes pod, it creates a First Class Disk (FCD) on the vSphere datastore. Both the FCD metadata and the CNS database itself are tightly coupled to the specific vCenter Server's inventory and unique UUID.}

^{If a Kubernetes worker node is natively migrated to a completely separate vCenter using xVMotion, the destination vCenter's CNS database has no historical awareness of those FCDs. Because the databases do not sync across vCenter boundaries, migrating the node severs the underlying storage mapping, immediately breaking the Persistent Volumes and resulting in data unavailability for the Kubernetes cluster.}

Resolution

^{Instead of attempting to move the stateful workloads at the vSphere infrastructure layer, the supported architectural approach is to migrate the workloads at the Kubernetes application layer.}

^{To safely migrate stateful Kubernetes clusters to a new vCenter Server, please follow this validated procedure:}

     ^{1. Provision Destination Infrastructure: Deploy and configure your new Kubernetes clusters natively within the fresh destination vCenter environment. Ensure the destination cluster has the vSphere CSI driver installed and configured to point to the new vCenter.}

     ^{2. Deploy Velero: Install and configure the Velero Plugin for vSphere on your source Kubernetes clusters. Ensure Velero is connected to an S3-compatible object storage repository that is accessible by both the source and destination clusters.}

     ^{3. Backup and Restore: * Execute a Velero backup on the source cluster to capture the Kubernetes namespaces, cluster state, and the stateful workloads (including the actual data within the Persistent Volumes).}

• • ^{Execute a Velero restore on the destination cluster. Velero will recreate the PVCs, instruct the new vCenter's CNS to provision new FCDs, and restore the volume data securely into the new environment.}

Additional Information

^{For a comprehensive list of supported and unsupported storage operations, please refer to the official VMware documentation:}

^{🔗 vSphere Functionality Supported by vSphere Container Storage Plug-in}