Hello,
We will debug the problem once the migration to vSphere 7 is 100% finished. Just in case somebody's else is interested in the vCenter migration:
We have already hot-migrated one of the vCenters 6.5 to version 7 using the "lift" or "elevator" system: The lift arrives, the VMs get in, the lift goes up to the new vCenter and the VMs leave the lift without interruption.
We did a new vCenter installation (best option whenever possible to avoid trailing old settings) using v.7. We also intend to consolidate several vCenters to this new one.
Some new ESX hosts (new hardware, etc.) with v. 7. Some old hosts will be reinstalled with ESX 7.
Source and target clusters were configured with EVC. New hosts are EVC compatible with the old ones.
Source, lift and target hosts can see the datastores where the VMs are currently running.
Preparation:
Create one cluster per vCenter to use for lifting VMs. EVC enabled.
1 Host, the "lift", with ESX 6.x highest version compatible with the old and new vCenter, hardware compatible (EVC) with old and new hosts.
Confirm that the lift can do vMotion with both worlds (old/new). Document the changes needed if required when switching environments (we required new VLANs for vMotion on the new one).
Make sure you have a recent, compatible powercli powershell module to avoid delays updating it (we lost a lot of time with this)
Export all VM Tag assignment using Power-CLI if you use tags (we map VMs+Guest processing settings+Credentials using tags, for instance)
Procedure:
Disable the concerned backup jobs.
Connect the lift to the old vCenter, cluster "Lift".
vMotion of some VMs to the lift.
Disconnect the lift. Connect the lift to the new vCenter, "lift" cluster.
vMotion to the new cluster/hosts, respools, etc.
Use the Veeam's vCenter migration utility to remap IDs (
https://www.veeam.com/kb2136) (read the doc, when it is applicable and when it is not).
- Prepare migration task.
- Review mappings file and leave only the VMs you intend to migrate (and the vc-old -> vc-new line)
- Use get-vm lab1_GW|select-object Name,Id on the new and old vCenter to help you identify the VMs in case of doubt.
- Duplicated VMs are commented out and must be uncommented (remove the // before the ID). This is not clear in the tool's documentation.
- Unneeded lines can be deleted for clarity shake, instead of commenting them out. (also not clear in the doc).
- Execute migration task.
Test a "quick backup" with one VM to validate it succeeds (
DO NOT reenable the backup jobs yet). It must succeed.
Disconnect the lift from the new vCenter.
Reconnect the lift to the old vCenter.
Remove the old, now orphaned VMs from the old vCenter.
Reassign the new backup tags (we scripted everything to avoid errors).
Repeat the procedure with a new batch of VMs or reenable the backup jobs if you are done for today (we did the migration in 2 days, during office hours)
Advantages:
Greenfield (everything is fresh installed, tested, qualified, documented, no trash migrated).
No downtime.
Old and new vCenter stay always functional (No impact to DRS, VDI provisioning, etc.).
No loss of redundancy of any cluster (we aren't disconnecting production hosts).
No need for extra storage (no copy/import of VMs, no restores, no replica failovers, etc.)
No broken backup chains.
CBT working. No need to fully read the VMs again (we are considering to do that by phases anyway to make sure CBT is clean)
Progressive: you set the pace of the migration. You can migrate a couple of VMs, test and when you are confident, migrate some other VMs another day.
This is a bit of kung-fu but every time I use this system, my colleagues and boss are quite happy with the results
.
Best regards.
.