Migrating VPGs from one vCenter to another
Zerto support had told us that migrating VPG’s from one vCenter to another was impossible. We could not find any tools to automate this task, which is beyond frustrating when there are hundreds of VM’s and VPG’s to migrate.
The current solution offered by Zerto is to delete all the VPG’s while retaining the data at the DR site, create new VPG’s manually and use the data for pre-seeding the VPG’s. When you’re talking about 50+ VPG’s with 100’s of VM’s and at least quadruple that amount of individual VMDK’s to pre-seed, manual migration could easily take 100’s of man-hours to complete.
After much back-and-forth with Zerto support, searching, and trial & error, we have successfully performed a migration of VPG’s from one vCenter to a new one. The process involved manipulating the XML export from Zerto so that it contains correct information required for importing. All the information needed can be pulled from the vCenter databases with a little Perl Fu.
I’ve attached the PDF doc as a .png. Just download and rename the file, since the forums only support attaching images.
In our case, we were replacing our vCenter server with a newer, more powerful server and a newer version of vCenter installed. We were working in a production environment, which meant change windows for many different customers that needed to be staggered to minimize risk. As such, this required having the old and new vCenter servers online, as well as the old and new ZVM servers online.
Assumptions & Prerequisites
Live (production) vCenter is being replaced
o The new vCenter and associated ZVM for the new vCenter should already be installed and active.
o Communication between the old and new source vCenters, ZVM’s and the DR site should already be
o Networks and distributed switches must be identical on the old and new vCenter servers.
The DR vCenter and ZVM must remain the same
vCenter/vSphere versions do not seem to matter
o We went from v5.1.0 to v6.0.0 with no issues
DRS temporarily disabled during this process to prevent VM’s from moving around.
ESXi hosts containing the protected VPG will be migrated to the new vCenter
o All protected VM’s residing on each ESX host will also be migrated
o It is likely possible to perform this procedure with a completely different ESXi host by editing the XML
accordingly, but we have not had the need to test this theory
Sane/safe settings for Bandwidth Throttling have been configured in the Zerto GUI
ALL protected VM’s for a given VPG must exist on the same ESXi server being migrated
o Simply re-locate any VM’s in vCenter to fix any discrepancies
o DRS must be disabled to prevent separation of VM’s in the VPG’s
RDP access with admin privileges to the ZVM for both the existing vCenter and new vCenter
o moRefFinder.pl, PowerCLI, VMware vSphere PowerCLI and VMware vSphere Perl SDK installed
Admin permissions for the Zerto Diagnostics utility on both ZVM’s
Notepad++ (32-bit!) with “XML Tools” plugin installed
o As of this writing, the 64-bit version does not have plugin support
This has only been tested on Zerto 5.x
See the PDF for the full procedure.
Thanks for your contributions, Aaron!
~HarryTechnology Evangelist at Zerto. Follow me: www.twitter.com/HarrySiii
I spent today writing a script that actually does all the steps you outlined in your document. It compares the old and new files along with a old VM/MoRefID export to generate a new file. We did a VCS migration from a Windows VCS to an appliance and this worked perfectly (VCS3 below). We have two more to go, but these are going to be the big ones. The next one will be doing is a primary target VCS for Zerto (VCS2 below). It looks like migrating a target is more involved. Do you have any documentation on this?
Our environments (with Zerto replication):
VCS3 -> VCS2
VCS1 -> VCS2