[vLCR] Steps to migrate Protected VMs from one vCenter to another vCenter server.
book
Article ID: 372292
calendar_today
Updated On:
Products
VMware Live RecoveryVMware Cloud Disaster Recovery
Issue/Introduction
Due to various reasons at times it is required to rebuild/install vCenter server or change the IP of the vCenter registered with VMware Live Cyber Recovery and move the workloads to new vCenter server. This articles provides steps and considerations to migrate the Virtual machines already protected by VMware Live Cyber recovery solution and registering the new vCenter server as protected site.
Environment
VMware Live Cyber Recovery 7.27.x
Resolution
Follow steps below to migrate the protected Virtual machines in a protection group from existing vCenter to new vCenter server without disrupting the current configured recovery plans, replication schedules and historical snapshots.
Register new vCenter server in the same site.
Register new connector virtual appliances.
Stop schedules of the Protection Groups for those Virtual machines, which are being migrated. Note: Non critical virtual machines first.
Move the Virtual Machines to new vCenter server.
Create new Protection Group under the new vCenter server and add the Virtual machines.
Perform a manual snapshot.
Wait for manual snapshot to complete and then validate the Virtual Machine snapshots from Virtual Machine Tabs.
Use the Restore Guest file and list the available snapshots, if it has successfully taken the vddk uuid then it will show the snapshots from new Protection Group as well as old Protection Group
Things to consider :
Do not delete the Old Protection Groups, deleting the Old PGs will result in all the old snapshots being deleted. Retailn the old Protection groups if those snapshots are to be used for recovery.The old snapshots can only used for Guest File Restore OR Failover to recovery SDDC. It may not be possible to failback or perform full VM restore using old snapshots which will have the old vcenter details.
If MoRef as well as underlying datastore both has changed, then it may fall back to a full sync. However, if it were able to pick the vddk information then it will be incremental sync. There may be some delay if the CTK information is lost as it will be doing a full validation of block changes available on Ingest datastore vs what are the recent block changes and then start the incremental sync.
Note: It is recommend to test it first with smaller and less critical Virtual Machines and if that works then proceed with other Virtual Mmachines which needs to be migrated.