Migrate to new ESXi Host - Backupchain

Do you have a vCenter this is being backed up via? If so you could look to migrate the VMs between the hosts, whilst retaining the same moref and your backup chains will continue 🙂

No, Im afraid not. Only single ESXi host. :(

The vm migrator utility may not be only for when vCenter is in use. It should treat a standalone host as a vCenter server as far as the cmdlet is concerned. (I haven't tested this yet though). 

I would encourage you to test this for your use case as it will allow you to continue your backup chains.

https://helpcenter.veeam.com/docs/backup/vsphere/vm_migrator_utility.html?ver=120

Thanks, I have read that but not sure I really understand what to do.

The guide is a little vague in my opinion.

Maybe there are any third party tools that can do this.
Starwind v2v maybe?

The “VM Migrator Utility” name is a bit misleading. It is not going to migrate your VM for you, it just updates the Veeam database to associate moved VMs in the new vCenter to backups created via the old vCenter. (Again, I’m not sure if it will work with standalone ESXi hosts, but we can try)

Before I start suggesting some commands, can you tell me if you’ve already added the new ESXi host to Veeam? Is it added with a name different from the old ESXi host?

Have you migrated any VMs yet? If not, when the time comes, you’ll be able to migrate them using “Quick Migration”

To answer if any third party tools can do this, yes there are some that can move the VMs, but no there are none that will update the Veeam database to allow you to keep your backup chains.

Hi!

Yes, I have added the new ESXi to Veeam, they both have different names and IP-addresses.
I also have done some testmigration with different methods, Quick Migrate, Replication with permenent failover.

Ok, start by taking a configuration backup of Veeam, we will eventually be modifying the Veeam database.

When that is complete, perform the following steps:

1. Gather the UUIDs of VMs on the original host (Insert your ESXi hostname in place of oldesxi 

Set-VBRVmBiosUuid -VCenterName "oldesxi"

2. Generate a migration task file (Again inserting your old ESXi hostname in place of oldesxi, and the new on in place of newesxi)

Generate-VBRViMigrationSpecificationFile -ExportPath C:\Temp -NewVCenterName newesxi -OldVCenterName oldesxi

This will create a migration file which will attempt to match vms based on their names, UUIDs, etc. You can also manually modify it.

Can you please share a screenshot of the contents of that file? Also, if there were any errors along the way, let me know. It may indicate that vCenter is a must.

We can cover performing the migration after reviewing that file.

Hi!
Thanks for the answer.

I run

Set-VBRVmBiosUuid -VCenterName "192.168.0.9"

And then

Generate-VBRViMigrationSpecificationFile -ExportPath C:\Temp -NewVCenterName 192.168.0.24 -OldVCenterName 192.168.0.9

The file then contains

	// hosts names
192.168.0.9 	-> 192.168.0.24
	// solid
	// probable
	// old duplicates
	// already migrated
	// not found

Looks weird. :/

Or must I first migrate the VM before running this?

If you're migrating a VM outside of vCenter, the VM's MoRef will change. In this case, you must remap the backup in Veeam to continue the chain.

Go to Home > Backups > Disk.

Right-click the old VM and choose Remove from Configuration (do not delete the backup files).

Go to Home > Jobs > Backup.

Edit the existing job, remove the old VM and add the new one (on the new host).

Under Storage > Backup, use Map backup.

Select the repository and the previous backup chain, save and run the job. Veeam will continue the existing chain even with the new VM.

When a full backup would be triggered:

• If the disks are renamed or in a different order.

• If previous backup files are unavailable.

• If you add the new VM without mapping the backup.

Export Veeam configuration before making changes, test the procedure with a non-critical VM first.

Thanks for reply!

But I don’t have the option to remove from configuration. :(

EDIT: I needed to press CTRL and then right click. :)

I will proceed with your guide.

I powered off the source VM.

Then did a Quick migration to the new host.

I unticked "Delete source VM...."

After it finished, I did "Remove from configuration".

I went to Home → Jobs → Backup
Edited the backupjob.

Storage → Map backup

And the object is gone, I cannot chose it. :(

This isn’t really working for me. :(

You are not able to see anything in the “Existing backups” list because you’re removing it from configuration. You’ll need to run a rescan on the repository to bring it back.

Regardless mapping a backup job to an old backup file will not continue the chain incrementally, as Veeam will see that the migrated VM is a unique one. What you’ll end up with is two vms with the same name in the backup job, basically duplicates. As I understand it, this is not your goal.

Going back to where we left off, can you run the “ Set-VBRVmBiosUuid -VCenterName "192.168.0.9"” command again, perform a migration of a vm (That is backed up at least once by Veeam) to the new ESXi host, then generate the migration file again? 

I am hoping it will find the migrated vm and put it in the task list. Again if nothing shows in the file it’s likely that vCenter is required.

You can rescan the existing repositories, then you should see them under Imported again. 
 

…other question: as you mentioned, you are running a single host, without a vCenter. So my guess is, this could be a very small environment. Why just don’t start with a new backup-chain? Is this also related to space saving?  Your old chain would stay in any case. 

Thanks, but I guess it will still start a new backupchain?

We have about 18 TB backupdata, alot of CAD-files and so on.
The backupstation is about 20 TB, so we are running low on space to start a new chain.

I would first like to investigate the possibility of continuing with the backupchain on the new host, but that seems a little harder then I first thought. :/

Plan B is to cut down on the retantion on current backup so we free up some space, and then start a new backupchain or to buy a new backupNAS and keep the old for a while just in case we need something.

Hi!

I ran

Set-VBRVmBiosUuid -VCenterName "192.168.0.9"

Then I did a Quick Migrate of an test-VM.

When it was finished i ran

Generate-VBRViMigrationSpecificationFile -ExportPath C:\Temp -NewVCenterName 192.168.0.24 -OldVCenterName 192.168.0.9

The migrationfile contains.

	// hosts names
192.168.0.9 	-> 192.168.0.24
	// solid
	// probable
	// old duplicates
	// already migrated
	// not found

Was I doing it in the right order?

​@patrikstar If that file is still blank after those steps, then it confirms that vCenter is a requirement for this method. Thank you for bearing with me to do that testing.

For now I’d agree with ​@Dynamic that you’d be best off starting a new backup chain/job for this. Your idea of reducing the retention to free up some space is valid if your business retention requirements allow for that. Or as you mentioned, considering upgrading your backup target and letting the old backups age out on the current repository.

Thanks!

At least now I know the conditions I have to work with.