VM Migration - Hyper-V

[DavidM]

When migrating a VM from one host/cluster to another, the host_id will be updated as will the object_id (unless using Veeam Backup & Replication to migrate the VM and select to preserve the VMID)
There is a VM Migrator Utility for VMWare, however there is no similar tool for Hyper-V
This means that if migrating a VM from one Hyper-V based host/cluster to another, the backups would need to be rebased
I did ask Veeam Support if there was any process to link the current backup of the VM on the old host/cluster to the VM on the new host/cluster but was advised there wasn't a way to do this

After a little research, I found that the host_id & object_id for the id could be updated in the Veeam Backup database resulting in the backups not needing to be rebased when moving from one host/cluster to another

Please note that this is not supported by Veeam and performing any of the actions outlined in this post is at your own risk
Also note that the scenario I had was moving from an Azure Local cluster to a single Hyper-V host. I'm unsure if this method would work for migrating a VM from a VMWare host/cluster to a Hyper-V host/cluster (I can see there's a platform column in the BObjects table that would probably also need to be updated)
My Veeam Database is on PostgreSQL (there's plenty of information other there on connecting to the Veeam Backup database - if you're unable to do this, you probably shouldn't procced with the below)

1. Gather Information for Current Backup
   Review the BObjects table

   Code: Select all

   SELECT * FROM BObjects;

   Example output

   Code: Select all

                    id                  | type |               host_id                |                            object_id                             |  viobject_type  |   usn    | platform |                 uuid                 |          unique_key_hash           |             platform_id              |              parent_id               |               hash_v2                |                                    tag
   -------------------------------------+------+--------------------------------------+------------------------------------------------------------------+-----------------+----------+----------+--------------------------------------+------------------------------------+--------------------------------------+--------------------------------------+--------------------------------------+----------------------------------------------------------------------------
   
   01234567-89ab-cdef-0123-456789abcdef |    1 | abcdef01-2345-6789-abcd-ef0123456789 | fedcba98-7654-3210-fedc-ba9876543210                             | Virtual machine | 123456789 |        1 | aaaabbbb-0123-4567-89ab-cdef01234567 | \x00112233445566778899aabbccddeeff | 00000000-0000-0000-0000-000000000000 | 00000000-0000-0000-0000-000000000000 | aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee | oldhost.domain.comfedcba98-7654-3210-fedc-ba9876543210
   

   id = The Veeam Backup & Replication ID for the object - in this case a Hyper-V VM
   host_id = The Veeam Backup & Replication ID for the host the VM is on
   object_id = The Hyper-V VM ID
2. Gather Information for New Host/Cluster
   Add Server in Veeam Backup & Replication
   Migrate one VM from the old host/cluster to the new host/cluster (if using Veeam Backup & Replication - select Generate new VM ID for ease of identifying the new Veeam ID)
   Add the VM to a Veeam Backup & Replication Job
   You don't need to run the backup job etc., just adding to the Veeam Backup & Replication Job is enough
   Review the BObjects table again

   Code: Select all

   SELECT * FROM BObjects;

   Example output

   Code: Select all

                    id                  | type |               host_id                |                            object_id                             |  viobject_type  |   usn    | platform |                 uuid                 |          unique_key_hash           |             platform_id              |              parent_id               |               hash_v2                |                                    tag
   -------------------------------------+------+--------------------------------------+------------------------------------------------------------------+-----------------+----------+----------+--------------------------------------+------------------------------------+--------------------------------------+--------------------------------------+--------------------------------------+----------------------------------------------------------------------------
   
   01234567-89ab-cdef-0123-456789abcdef |    1 | abcdef01-2345-6789-abcd-ef0123456789 | fedcba98-7654-3210-fedc-ba9876543210                             | Virtual machine | 123456789 |        1 | aaaabbbb-0123-4567-89ab-cdef01234567 | \x00112233445566778899aabbccddeeff | 00000000-0000-0000-0000-000000000000 | 00000000-0000-0000-0000-000000000000 | aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee | oldhost.domain.comfedcba98-7654-3210-fedc-ba9876543210
   98765432-10ab-cdef-0123-456789abcdef |    1 | fedcba01-2345-6789-abcd-ef0123456789 | abcdef98-7654-3210-fedc-ba9876543210                             | Virtual machine | 123456789 |        1 |                                      |                                    | 00000000-0000-0000-0000-000000000000 | 00000000-0000-0000-0000-000000000000 | 00000000-1111-2222-3333-444444444444 | newhost.domain.comabcdef98-7654-3210-fedc-ba9876543210
   

3. Update the Veeam backup Database
   For the old Veeam Backup & Replication ID, update the Veeam Backup & Replication ID for the host the VM and the Hyper-V VM ID

   Code: Select all

   UPDATE BObjects (I didn't update the tag column but you could)
   SET host_id = 'fedcba01-2345-6789-abcd-ef0123456789', object_id = 'abcdef98-7654-3210-fedc-ba9876543210'
   WHERE id = '01234567-89ab-cdef-0123-456789abcdef

   The database will now look like

   Code: Select all

                    id                  | type |               host_id                |                            object_id                             |  viobject_type  |   usn    | platform |                 uuid                 |          unique_key_hash           |             platform_id              |              parent_id               |               hash_v2                |                                    tag
   -------------------------------------+------+--------------------------------------+------------------------------------------------------------------+-----------------+----------+----------+--------------------------------------+------------------------------------+--------------------------------------+--------------------------------------+--------------------------------------+----------------------------------------------------------------------------
   
   01234567-89ab-cdef-0123-456789abcdef |    1 | fedcba01-2345-6789-abcd-ef0123456789 | abcdef98-7654-3210-fedc-ba9876543210                             | Virtual machine | 123456789 |        1 | aaaabbbb-0123-4567-89ab-cdef01234567 | \x00112233445566778899aabbccddeeff | 00000000-0000-0000-0000-000000000000 | 00000000-0000-0000-0000-000000000000 | aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee | oldhost.domain.comfedcba98-7654-3210-fedc-ba9876543210
   98765432-10ab-cdef-0123-456789abcdef |    1 | fedcba01-2345-6789-abcd-ef0123456789 | abcdef98-7654-3210-fedc-ba9876543210                             | Virtual machine | 123456789 |        1 |                                      |                                    | 00000000-0000-0000-0000-000000000000 | 00000000-0000-0000-0000-000000000000 | 00000000-1111-2222-3333-444444444444 | newhost.domain.comabcdef98-7654-3210-fedc-ba9876543210
   

   Delete the row for the new Veeam Backup & Replication ID

   Code: Select all

   DELETE FROM BObjects
   WHERE id = '98765432-10ab-cdef-0123-456789abcdef'

   And you'll be left with

   Code: Select all

                    id                  | type |               host_id                |                            object_id                             |  viobject_type  |   usn    | platform |                 uuid                 |          unique_key_hash           |             platform_id              |              parent_id               |               hash_v2                |                                    tag
   -------------------------------------+------+--------------------------------------+------------------------------------------------------------------+-----------------+----------+----------+--------------------------------------+------------------------------------+--------------------------------------+--------------------------------------+--------------------------------------+----------------------------------------------------------------------------
   
   01234567-89ab-cdef-0123-456789abcdef |    1 | fedcba01-2345-6789-abcd-ef0123456789 | abcdef98-7654-3210-fedc-ba9876543210                             | Virtual machine | 123456789 |        1 | aaaabbbb-0123-4567-89ab-cdef01234567 | \x00112233445566778899aabbccddeeff | 00000000-0000-0000-0000-000000000000 | 00000000-0000-0000-0000-000000000000 | aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee | oldhost.domain.comfedcba98-7654-3210-fedc-ba9876543210
   

You can now take backups and continue the current backup chain
CBT will warn the first time you backup after doing the above, but the next backup the warning is resolved
For any subsequent VMs, you can just use the same host_id and get the Hyper-V ID from the Hyper-V host etc.

[PetrM]

Hi David and Welcome to Veeam R&D Forums!

I want to commend you for the clear and detailed description and note that it's a very complex task from a technical standpoint, especially for someone who does not have access to our internal resources, labs, etc. Unfortunately, I cannot recommend applying this workaround in a production environment. We cannot predict what kind of issues we may face, and there is no official support for this procedure. Therefore, we will not be able to fix any problems if something goes wrong after this procedure is executed.

I have worked for many years in the technical support team, and I can't even count how many times I solved different issues by fixing broken links in the configuration database. The most complicated research was always related to manual database entry updates that had no records in the logs or the support case history.

Thanks!