Veeam V11 and Moref id migration tool

[FrenchBlue]

Hello,

I know it is not supported anymore, but has anyone used successfully the migration tool with Veeam V11? We are moving from a Vsphere 6.7/NSX-V cluster to a new one in Vsphere 7.0 (new Vcenter)/NSX-T and we definitely need to keep the existing backup jobs, backups, etc....

Thanks.

[Mildur]

Hi FrenchBlue

It was never supported in the first place. See the note in the KB Article.
Accordingly to the KB article, it will work with Veeam V11.

vCenter Migration Utility

[Regnor]

I havn't used it with V11, but with V10 it was working.
Take a configuration backup before and be very careful to not make any mistakes.
And like Mildur wrote, you won't get support from Veeam for the tool.

[FrenchBlue]

Hello,

Clear, thanks for the answers.

[blackwindow]

hello,
I am trying to use the tool with Veeam V12. But I guess the migration tool is expecting MS SQL DB and not PostgressSQL

"Preparing for migration started
Error: Microsoft SQL server hosting the configuration database is currently unavailable. Possible reasons are heavy load, networking issue, server reboot, or hot backup.
Please wait, and try again later."

[FrenchBlue]

Hi,

For sure it won't work anymore with Postgre.

[Mildur]

Checking.
If the migration tool does not work with PostgreSQL, we will add a note to the KB.

Best,
Fabian

[filippot]

Hello,
I am interested in the information too.
Have used it in the past and was very useful

[Mildur]

Hello guys

I checked the tool myself in the lab.
The tool reads the database configuration from the registry.
We changed the path of the database configuration in Windows regitsry in V12, which makes the tool fail for both MSSQL and PostgreSQL configuration databases. For PostgreSQL, there are additional registry keys to check, which the tool is not aware about.

The tool is not compatible with V12. Either with MSSQL or PostgreSQL.
We will update the kb article to reflect that.

Best,
Fabian

[GianlucaCroci]

We migrated to V12 a couple of months ago, and now we need to migrate VCenter too. For organizational reasons we were unable to proceed with an update of the Vcenter but we had to create a new machine. So we will also take advantage of this to do some cleaning in the config, especially on the Permissions and Tags side.

This Migration Tool would have been a valuable help for us, as we're also faced with space problems on the Repositories.
If we were not in a hurry, we could move some VMs of some jobs, and once the retention period has passed, delete the old saves to proceed with another group of servers.
Problem that the old Hosts are no longer under maintenance and the migration to the new infrastructure must take place within very tight deadlines.
As mentioned, the Migration Tool would be the ideal tool if it worked with V12.

Unfortunately we've a combination of factors that doesn't help in the operation

[ryan.christensen]

Is there any talk internally of Veeam bringing back a tool like this but maybe built into the main interface? I work for a large MSP. We have lots of clients that get onboarded these days with very old vCenter versions and frequently upgrading vCenter fails and requires a re-deployment. That means new full backups to both onsite and the immutable offsite repo.

[Gostev]

No short-term plans for a built-in experience... hard to justify vs. other priorities. Also, it seems ultra-counter-intuitive as this approach means every single vSphere management vendor out there would have to be building this experience independently, for each and every product. When it should really be solved on the vSphere side?

For example, isn't it possible for you to backup & restore vCenter configuration instead? It seems "vCenter lost" should be quite a common case for a variety of reasons and I can't believe VMware does not provide at least some rudimentary way to backup and restore vCenter configuration? I did not check on this recently but it would be really strange for an enterprise infrastructure platform not to provide this capability for its most critical component, literally the brain?

[GianlucaCroci]

Thanks Gostev.

Our problem, as I wrote, is that we wanted to clean up part of the current configuration, and above all some things can't be brought into the new infrastructure as they currently are because it would mean stopping production for several hours (for example the Rancher infrastructure) and being a hospital, some things can't stay off for even 5 minutes.
Hence the fact of having configured a new VCenter, and wanting to move the machines from one to the other.
The problem to be solved now is backups as the disk space of the Repositories doesn't allow a doubling of the saves (we need to maintain the old chain, old retention, until the new chain is complete).

[ryan.christensen]

VMware does provide the ability to backup and restore vCenter configurations but it's in its infancy still in my opinion. You can't take a backup from 6.5 and restore it to 6.7 for example. It has to be the exact same version of vCenter, even the exact same patch, for the restore to work. But yes, it's true that if VMware provided an easier method for keeping MoRef IDs when migrating VMs between vCenters this would be a non issue.

[GianlucaCroci]

So no way to move the VM from a VCenter to another one, without do a FULL backup?

[jsvr]

We have the same issue.
Anyone already tried the database workaround on v12, like posted here: https://www.myitblog.co.uk/veeam/change ... -database/ ?

[Mildur]

Hello Jsvr

This is not an officially supported solution offered by Veeam. We cannot ensure that your backup chains will be capable of continuing or, even worse, that your data can be successfully restored. If you encounter any technical issues in your environment after implementing this unsupported solution, our support team will be unable to assist you.

So no way to move the VM from a VCenter to another one, without do a FULL backup?

There is a way by using our quick migration technology. When you move a VM with quick migration, we can update the MoRefID in our database. Because we know 100% which VM we have moved. This only works if the VM is powered on while doing the quick migration process.

Best,
Fabian

[Gostev]

To be clear, the main risk is people matching wrong VMs and ending up with unrecoverable backups. The script we provided before required human review which was often either neglected completely or just not performed carefully enough, resulting in unrecoverable backups of critical VMs later due to incorrect matching during the migration.

[jsvr]

Hello Jsvr

This is not an officially supported solution offered by Veeam. We cannot ensure that your backup chains will be capable of continuing or, even worse, that your data can be successfully restored. If you encounter any technical issues in your environment after implementing this unsupported solution, our support team will be unable to assist you.


There is a way by using our quick migration technology. When you move a VM with quick migration, we can update the MoRefID in our database. Because we know 100% which VM we have moved. This only works if the VM is powered on while doing the quick migration process.

Best,
Fabian

Quick migration is not a good tool to use when to migrate cross vcenter, destination network of the vm cannot be selected.

[tyler.jurgens]

The ability to set the destination network is a great feature request, but I'd rather use Quick Migrate and fix the networking than having to run an active full backup again. Right now its a bit of a 'pick your poison' type situation.

[jsvr]

this means downtime for the migrating vm, we have 2000 vm's to go, so not a good idea...

[tyler.jurgens]

Cross vCenter vMotion and take active full backups on 2000 VMs. No downtime!

[FrenchBlue]

This breaks the backup chain.

[GianlucaCroci]

Anyone already tried the move VM from a VCenter to another one, backuped by v12?
We don't have so much space on the Repository to do a complete Full Backup of all VM, and we can't loose the old Backups.

[FrenchBlue]

You won't <lose> the old backups, but the backup chain will be broken and you will have to manage expiration of the old backups manually. And yes, using more space then, since you will restart with "fresh" full backups.

[GianlucaCroci]

Sorry, I expressed myself badly. I meant without losing the old chain.
Having a month of retention, if a new chain starts, I can't delete the old one until I've a month with the new chain again.
Having little space, this isn't possible.
As well as managing the manual deletion of old saves, although it would be possible as we run a full game every week.
But having many jobs, it becomes a very burdensome management.

Also how does this operation behave with immutable repositories?

[FrenchBlue]

I don't think there is currently a possibility to migrate the VMs to a new Vcenter without losing the backup chain unfortunately, unless something changed recently, others please correct me if I'm wrong.

The tool was previously supplied "as is" and not supported, but since V12 its is clearly forbidden by Veeam to use it.

[Mildur]

Hi guys

I wanted to update this topic.
Last week, we reintroduced our vCenter migration tool (Veeam VM Migrator Tool). The tool is supported starting in version 12.2 and is compatible with configurations using both MSSQL and PostgreSQL databases.

Please check the Knowledge Base article for more information: https://www.veeam.com/kb2136

Best,
Fabian

[FrenchBlue]

Hi,

Good news, thanks! Does it allow partial migration or still "big bang" ?

[Mildur]

Hi FrenchBlue

It's still a "big bang" migration.
We have requests for "per-VM" as well, but no information or ETA to share.
Do you have scenarios where you would require "per-VM" on a regular interval?

Best,
Fabian