New vCenter Same Name

[Zew]

Hello all you legends,

Since my last post got "locked" let me clear a few assumptions that were incorrect.
1) "you're facing an environment-specific issue after making some significant changes to your production environment."
- a) It was a minor change (a very simple SQL edit statement)
- b) In my lab environment

2) "The forum rules displayed when you click New Topic specifically request that you don't bring environment-specific issues to this community, as this is not a support forum."
-c) I wasn't asking for support, I was asking for help, in a very proper form area for educational purposes.

It's your forms, your rules, I won't deny that and I'll try to do better, but I did not do the following, they were assumed.

Now on to the topic of this discussion/thread, I have asked three times now how to use the "supported" tool.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

It seems that the file I had question about is created using "Generate-VBRViMigrationSpecificationFile"https://helpcenter.veeam.com/docs/backu ... ml?ver=120

which shows it needs the "old vCenter name" and the "New vCenter name". What if vCenter was recreated using the original vCenter name, do I simply enter the same name in both fields?

[david.domask]

Hi Zew,

I'll address the cmdlet question here, and pardon, but will avoid re-litigating what was already discussed in another thread with regards to the rest save a quick comment on the SQL edit.

Follow the process linked here including the optional steps. Your situation where the "new" vCenter has same name as old vCenter is covered by the cmdlet Set-VBRVCenterName cmdlet which simply will append _old to the old vCenter, and you can proceed with the steps as prescribed in the User Guide.

As for the SQL edit, while in practice such a change is simple, such edits can have far reaching consequences that don't present in an obvious way, and as such are always unsupported. The configuration database has evolved a lot since that workaround was invented, and I would not rely on it or any configuration database edits you may come across online as such edits must always be done with Veeam Support supervision. Any other way is unsupported and will likely present issues at some point.

[Zew]

Hey David,

Thanks for the guidance, I'll give it a shot. I'm still a bit confused as to what it renames to old vCenter, I can only assume you mean some references as defined within the DB. Since in my case scenario there's always only 1 vCenter and it is functional in Veeam after being rescanned. So what exactly gets renamed with _old?

[david.domask]

You're very welcome Zew.

This situation is part of what the Set-VBRVCenterName cmdlet is for -- if you are migrating but keeping the same vCenter name, the process will be:

1. Manual Configuration Backup (always best practice to have a backup "just in case")
2. Run both of the optional cmdlets Set-VBRVmBiosUuid and Set-VBRVCenterName
3. Confirm in UI that the current vCenter has "_old" appended to its name and proceed
4. Add the "new" vCenter -- normally Veeam would prevent adding "duplicates", but in this case it's allowed.
5. Follow the rest of the steps in the User Guide

The Set-VBRVCenterName cmdlet allows for the drop-in replacement scenario you're describing where new vCenter has same name/hostname as old vCenter. So temporarily you will have the vCenter twice in VBR, then you will run the cmdlets as prescribed. Once all looks good (jobs are working normally), remove the _old vCenter.

[Zew]

Hello and thank you again for some more clear step. However, I still believe there's an assumption being made here. I have already "added" my new vCenter to Veeam. AKA The Steps that took place as of right now:

1) Old vCenter is physically gone with no config backup available. (Veeam software know nothing about this.)
2) Run the vCenter installer, creating a brand new vCenter using the exact same name as the old vCenter that was destroyed. (Again at this stage Veeam software know nothing about this)
3) the ESXi hosts with their registered VMs are added to new vCenter (the MoREID have now changed, Again Veeam software knows nothing of this).
4) In Veeam, Infrastructure -> vCenter (right click context menu -> Properties) -> go through wizard accepting new certificate. (Veeam now see the vCenter just like it did orginally, but any job will fail as it doesn't know which VM is what, the MoREID problem).

Am I to understand the commands you told me to run is suppose to take place WITHOUT me "rescanning" the vCenter instance and accepting the new certificate? What would I do in the situation I am in right now? I fixed this via again, my blog post and the "simple backend DB change" which, I am well aware is not supported.

[david.domask]

Got it; indeed I'm trying to imagine a bit on your setup as I didn't see the topic where you discussed it.

> 4) In Veeam, Infrastructure -> vCenter (right click context menu -> Properties) -> go through wizard accepting new certificate. (Veeam now see the vCenter just like it did orginally, but any job will fail as it doesn't know which VM is what, the MoREID problem).

Do you have a configuration backup (Veeam) from before you did this step? This is the step where you would start the migration process.

The VM Migrator cmdlets compare two vCenters added to a given VBR and then update the Veeam configuration database accordingly to do the "migration". This comparison is done with data already in the Veeam configuration database. So in your case, if you can restore Veeam's configuration database to before you made these changes, instead of your step 4 there, you will begin the migration procedure and use the Set-VBRVCenterName cmdlet on the existing vCenter in Veeam, re-add your newly rebuilt vCenter to Veeam, and then perform the migration.

[Zew]

Hello David,

Thanks again for helping me out here. I think I now know what's going on thanks to your help. Let me answer your question on if I have a Veeam Config Backup. Yeah In my locked thread I mentioned how I restored Veeam from fresh (it was a different issue, that came about from my own processes not following supported methods). So while, I do have one, I'll try avoid using it and instead attempt to replicate my issue by simlpy re-installing vCenter and attempting the migration.

To bring me to a clean "supported" DB, I would instead install Veeam fresh, and recreate all my jobs fresh mapping them to the old chains. I'll attempt another case study in my lab with all the knowledge that I now have and will report my findings.

Thanks again for helping me understand how the tool operates and what it expects.