The re-homing task does not complete and hangs indefinitely.
The initial error observed might be vcPrime Edit is failing.
The Destination Management Cluster shows signs of instability, such as:
Inconsistent VM states in the vCenter UI.
Broken "Cluster Diagnosis" checks in the TCA UI.
Critical pods (such as kube-vip) are down or unreachable in the destination cluster.
TCA: 3.2
TCP: 5.0
Prepare the Environment
Verify the health of the Source Management Cluster and ensure its CAPI/CAPV resources are running.
Identify the exact names of your clusters:
<WORKLOAD_CLUSTER_NAME>: The name of the cluster being moved.
<SOURCE_MC_NAME>: The name of the original (healthy) Management Cluster.
Access the TCA Database SSH into the TCA Manager appliance as the admin user
Connect to the PostgreSQL database pod:
kubectl exec -it postgres-0 -n tca-mgr -- psql -d tca -U tca_admin -h localhost
Revert NodePool Relationships Check if the NodePools are mapped to the broken destination cluster, and revert them to the source.
Check current mapping:
select val->'metadata'->>'mgmtClusterName' from "K8sClusterDetails" where val->>'rowType'='nodePool' and val->'metadata'->>'clusterName'='<WORKLOAD_CLUSTER_NAME>';
select val->'metadata'->>'mgmtClusterName' from "K8sClusterNodeConfiguration" where val->>'rowType'='nodePool' and val->'metadata'->>'clusterName'='<WORKLOAD_CLUSTER_NAME>';
Update mapping (Run only if the output above shows the Target/Destination management cluster):
UPDATE public."K8sClusterDetails" SET val = jsonb_set(val, '{metadata, mgmtClusterName}', '"<SOURCE_MC_NAME>"') where val->>'rowType'='nodePool' and val->'metadata'->>'clusterName'='<WORKLOAD_CLUSTER_NAME>';UPDATE public."K8sClusterNodeConfiguration" SET val = jsonb_set(val, '{metadata, mgmtClusterName}', '"<SOURCE_MC_NAME>"') where val->>'rowType'='nodePool' and val->'metadata'->>'clusterName'='<WORKLOAD_CLUSTER_NAME>';
Revert Addon Relationships Check and revert the management cluster association for Addons.
Check current mapping:
select val->'metadata'->>'mgmtClusterName' from "K8sClusterDetails" where val->>'rowType'='addOn' and val->'metadata'->>'clusterName'='<WORKLOAD_CLUSTER_NAME>';
Update mapping:
UPDATE public."K8sClusterDetails" SET val = jsonb_set(val, '{metadata, mgmtClusterName}', '"<SOURCE_MC_NAME>"') where val->>'rowType'='addOn' and val->'metadata'->>'clusterName'='<WORKLOAD_CLUSTER_NAME>';
Revert Cluster Relationship Check and revert the main cluster object association.
Check current mapping:
select val->'metadata'->>'mgmtClusterName' from "K8sClusterDetails" where val->>'rowType'='cluster' and val->'metadata'->>'name'='<WORKLOAD_CLUSTER_NAME>';
Update mapping:
UPDATE public."K8sClusterDetails" SET val = jsonb_set(val, '{metadata, mgmtClusterName}', '"<SOURCE_MC_NAME>"') where val->>'rowType'='cluster' and val->'metadata'->>'name'='<WORKLOAD_CLUSTER_NAME>';
Clear Re-homing Error Flags Remove the status flags that indicate a stuck pivot operation:UPDATE public."K8sClusterDetails" SET val = val #- '{status, hasPivotError}' where val->>'rowType'='cluster' and val->'metadata'->>'name'='<WORKLOAD_CLUSTER_NAME>';
UPDATE public."K8sClusterDetails" SET val = val #- '{status, pivotAccepted}' where val->>'rowType'='cluster' and val->'metadata'->>'name'='<WORKLOAD_CLUSTER_NAME>';
Sync State via UI
Log out of the database and the SSH session.
Log in to the TCA Manager UI.
Locate the Workload Cluster (it should now reflect the Source Management Cluster).
Trigger an Edit operation on the Workload Cluster.
Do not make any changes; simply click Next through the wizard until you reach Apply.
Click Apply. This forces the TCA Manager to refresh the database state and reconcile the cluster status.
Once the Workload Cluster is successfully secured back on the source management cluster, choose one of the following cleanup options:
Delete the broken Destination Management Cluster.
Deploy a new, healthy Destination Management Cluster.
Run the Cluster Diagnosis workflow to verify health before attempting the re-home operation again.
To prevent duplicate CR registration states across both source and target management clusters, you must manually purge the stale Workload Cluster CRs on the target management cluster.
Delete all nodepools (will also delete all associated MachineDeployments)
kubectl delete -n <WORKLOAD_CLUSTER_NAME> tknp --all
Delete the TKC object (will also delete the TKCP and all associated cluster-api resources)
kubectl delete -n <WORKLOAD_CLUSTER_NAME> tkc <WORKLOAD_CLUSTER_NAME>
Delete the Workload Cluster namespace to remove all remaining orphaned resources
kubectl delete ns <WORKLOAD_CLUSTER_NAME>