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.
oliverL wrote:Can we except the same behavior if the hosts with the VMs are on a new vCenter (no upgrade Installation vCenter 5.5 to 6.0 ) (and still have their corresponding tags?) or will Veeam work flawlessly since it needs to build the vm list anyways?
wojciech.bajorek wrote: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.
Users browsing this forum: Google Feedfetcher, Mahdi-t and 1 guest