Migrating ESX hosts to new VCSA / Veeam Migration Tool

[culusahin]

Currently we are running a 6.5 vCenter (VCSA). We recently built a brand new vCenter 6.7 U2 vCenter and looking to move all our hosts from the old 6.5 to this new 6.7 vCenter. The 6.5 vCenter is in bad shape and we are not looking to do an in-place upgrade.

NOTE - we are looking to move the hosts in stages AND NOT IN ONE BIG BANG!

Moving the hosts in stages presents a problem with our Veeam backups.

As the VMs move from one vCenter to the other the MoRef IDs will change, this in turn will trigger full backups for each VM. Now Veeam has provided a tool (https://www.veeam.com/kb2136) to replace MoRef IDs in the Veeam database with the new IDs, so the existing backups are not disrupted, however this tool seems to be designed for BIG BANG moves, since under the Considerations and Limitations section of the document - it states 'Old vCenter should not be used by Veeam Backup & Replication any more after migration'. We are also not sure if the tool is supported with 6.7 vCenter!

NOTE - We will be carrying out backups on VMs managed by both vCenter servers, until all hosts are moved to the new vCenter.

So, I've been digging around in the Veeam database to come up with a manual approach.

TEST 1 (successful):

1. I first isolated a host in the old vCenter, created a Test VM on it, run a full backup and an incremental backup for the VM
2. I then queried the MoRef ID of VM using script: get-vm VMName | select name,id, recorded ID
3. Then I disconnected the host from the vCenter and connected it back to the same vCenter
4. I then queried the MoRef ID of VM using script: get-vm VMName | select name,id, ID changed, recorded new id
5. I opened SQL Management Studio on the Veeam server and run the following sql query:

UPDATE [dbo].[BOobjects]
SET [object_id] = ‘NEW ID’
WHERE [object_id] = ‘OLD ID’

Modifying the object_id value.

6. Then I run another backup - worked fine, the resulting backup was incremental!

TEST 2 (unsuccessful):

1. I first isolated a host in the old vCenter, created a Test VM on it, run a full backup and an incremental backup for the VM
2. I then queried the MoRef ID of VM using script: get-vm VMName | select name,id, recorded ID
3. Then I disconnected the host from the vCenter and connected it to the NEW vCenter
4. I then queried the MoRef ID of VM using script: get-vm VMName | select name,id, ID changed, recorded new ID
5. I opened SQL Management Studio on the Veeam server and run the following sql query:

SELECT [dbo].[BObjects].id, [dbo].[BObjects].object_id, [dbo].[BObjects].host_id, [dbo].[BObjectsSensitiveInfo].object_name, [dbo].[BObjectsSensitiveInfo].path
FROM [dbo].[BObjects]
INNER JOIN [dbo].[BObjectsSensitiveInfo] ON [dbo].[BObjectsSensitiveInfo].bObject_id=[dbo].[BObjects].id
WHERE object_name = 'VMName'

Confirming single entry for the VM in BObject table.

6. Then I added the new vCenter to Veeam and modified backup job by removing VMs, then adding them back in using new vCenter.
7. I opened SQL Management Studio again on the Veeam server and run the following sql query:

SELECT [dbo].[BObjects].id, [dbo].[BObjects].object_id, [dbo].[BObjects].host_id, [dbo].[BObjectsSensitiveInfo].object_name, [dbo].[BObjectsSensitiveInfo].path
FROM [dbo].[BObjects]
INNER JOIN [dbo].[BObjectsSensitiveInfo] ON [dbo].[BObjectsSensitiveInfo].bObject_id=[dbo].[BObjects].id
WHERE object_name = 'VMName'

To confirm nothing changed in the BObjects table.

At this point the script was returning 2 rows with the same VMName, one with host_id of old vCenter and the other with the new vCenter.

8. I ignored that, and run the SQL script to modify the object_id value in the table:

UPDATE [dbo].[BOobjects]
SET [object_id] = ‘NEW ID’
WHERE [object_id] = ‘OLD ID’

9. Then I run another backup, unfortunately this time a completely new full backup was produced for the VM!

My theory is, once the job was modified in Veeam, the job started using the new row in the BObjects table to identify VM. Based on further tests modifying the old row makes no difference to the backup job outcome, after job is modified.

I recon the id column value of the BObjects table is somehow related with the existing backup sets for the VM, and pointing the job to the old row after modifying the job, then modifying the object_id and host_id values of that row may fix the issue.

I might be completely wrong with my thinking! I’m in the dark here, and this is all trial and error.

NOTE – host names associated with host_id values can be found in the dbo.Hosts table.

Although highly unlikely, I'm hoping Veeam can disclose the SQL queries they are using in the tool so that I can see what the tool does on the database end, and how the different tables / columns / rows are linked to each other.

I think I’m accurate in saying a lot of other people are looking to do such migrations in a staged manner.

[culusahin]

I forgot to add this in the post >>> we don’t have the capacity to run full backups for 1800+ VMs

And the questions I'm looking to get answered:

1. Can you confirm the tool is designed for BIG BANG moves only, and staged migrations are not possible?
2. Has the tool been tested with 6.7 vCenter?
3. Will Veeam disclose the SQL queries used in the tool?

[foggy]

Hi Cengiz,

1. Yes, the tool was designed for one-off migrations.
2. I believe the tool maintenance stopped after the migration tool from VMware became available.
3. We don't recommend direct interference with the Veeam B&R database so do not typically publish any SQL queries. You may try to ask our support for assistance, they might be able to check.