arthur.reed wrote:Just got a response from support:
"Here's my response from what I'm seeing in the notes: VMware does not support changing MoRef IDs manually, so neither do we. You'll notice that, even with our conversion tool, it is emphasized that we offer it as a convenience and do not support it.
Once that MoRef id has changed, you will have to re-add the VMs into the job. As such, the original backup job will run an active full. and the Backup Copy job will run a full. There really is no way around this."
So it looks like I'm screwed and the only thing I can do is pay for a reseed. I replied that I wouldn't think that you were changine the MoRef ID's on the VM but rather changing them in the VEEAM database to map the new ID's.
Sorry for bringing this quotation up front as it is one month old already.
Can anyone explain this to me: "Once that MoRef id has changed, you will have to re-add the VMs into the job."?
If I understand it right, then it's just a bullsh**.
If I understand it right v2, then this is something I had a rough fight with support during last year. 2-3-4 engineers and in the end I received "sorry, we can't help and this will not work - all replica chains must be removed, we can only use VM seeding to keep single replica file.".
Yep, it worked flawlessly (100% success) and for me, who nearly had no knowledge about Veeam database, it took only several hours to find a solution.
I successfully migrated source VMs and replicas from old vCenter to the new one preserving replicas' chains. No dirty DNS hacks.
What is more important I didn't have to buy 100TB+ storage only for vCenter migration... Sad, but true.