Relink VM MoRef IDs to Veeam Backup Restore-Points

In this post I will show how to use Veeam Migration Utility in cases when you have to migrate a whole cluster to a new vCenter, but you can’t afford to cut existing backup chains.

The Good

Upgrading a vCenter Server Appliance (VCSA) has become a commodity in recent times. All you have to do is to run an upgrade wizard and point to the old VCSA. Thanks to VMware developers it’s one of these “Next-Next-Finish” deployments. At the end you’ll have an upgraded vCenter with same settings, name, IP, and (if you like) historic data.  This is great! I can remember vCenter on Windows upgrades that were a PITA.

The Bad

In some rare (but ugly) occasions you simply can’t use the wizard and you have to migrate your hosts to a completely new VCSA without data migration. You’ll have to rebuild every setting, datacenter, cluster, folder, pool, group, rule, etc from scratch to match your old environment.

Now you might ask, why the hell didn’t you use that wonderful wizard? Well, in that specific case we had to change the IP address of vCenter. Basically not a showstopper. It can be changed from the GUI in more recent versions or by using dirty tricks in older versions. There’s one exception: if someone decided (deep in the past) to assign the IP address instead of a hostname to the vCenter appliance, it cannot be changed. It will act as  unique identifier and will be there forever. Your only chance to get out of this deadlock is to bite the bullet setup a new VCSA with name as hostname and then move hosts to the new vCenter.  It’s a lot of work and therefore you can use the occasion to roll out the latest VCSA.

We went from VCSA 6.0 to 6.7. Additionally we had to get rid of vShield which was part of vCloud Networking and Security (vCNS) and is no longer supported for vCenter 6.5 and upwards. Read in my post “vShield to NSX migration” how to do that.

Moving hosts under full load

A cold migration wasn’t an option. So we had to move host from the old vCenter to the new one under full sails.  Adjust all settings in new vCenter to match your needs. Disable HA and DRS in the old vCenter, disconnect host and add it to your new vCenter. The host will carry its license to the new vCenter. Accept to import and re-use it. Repeat host after host.

After a lot of work hopefully all of your host reached the safe harbour of the new vCenter. Time for beer-o-clock? Sorry, no!

The Ugly

Once a host with VMs gets registered to a new vCenter, all VMs will be assigned a new MoRef ID (Managed Object Reference ID), which is unique within that vCenter. There’s an old blogpost by William Lam about Managed Object Reference IDs.

So what’s the problem?

If you’re using a backup solution like Veeam Backup and Replication you may wish to match your old restorepoints with the new MoRef IDs. Using the MoRef to identify VMs is a good idea, because VM names might change over time. A VM “Exchange2016_Migration” may be renamed to “ExchangeEMEA” for example. But once you join a new vCenter server all of your restorepoints are cut off and backup jobs won’t find the VM object anymore. And even if you replace the VM object in a job, Veeam can’t link it to an existing backup-chain on its repositories, because of a changed MoRef ID.

Of course you may cut off your backup chains and start over with new VM objects. But maybe there is neither enough space on the repositories nor do you have a time window to run all jobs in active full. Checkmate! But wait, there’s help. Move on to the next page to see how it works.