VM moved to new vCenter

[veremin]

David, just so you know - the KB article has been updated.

[wojciech.bajorek]

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.

[foggy]

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?

The behavior will be the same, since, regardless of how VMs are added, they are tracked by their IDs.

[foggy]

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.

Wojciech, could you please clarify, did you use vCenter Migration Utility discussed in this thread?

[wojciech.bajorek]

Support guys assigned to this case tried to use it but the generated txt file was a mess (too many conflicts and occurrences).
I used SQL Management Studio and Notepad as, sorry to say but, the whole problem is located within Veeam DB only.

It's not a problem of VMware and their changing IDs.
Of course, MoRef change during ESXi move between vCenters is painful, but this is just data that needs to be updated in the database of the backup system...

[foggy]

Got it, so you've managed to map IDs manually directly in the Veeam B&R database.

[wojciech.bajorek]

Exactly.

The following SQL sentence solved my replica's migration problem to the new VC:
UPDATE dbo.Replicas
SET target_location='NEW_VC\CLUSTER_NAME', target_vm_ref='NEW_MOREF_ID'
WHERE target_vm_name='VM_REPLICA_NAME';

Notes:
1. It worked for 9.0. It seems that there is a need to make changes in 9.5 as the database layout is different.
2. It worked in my environment, but it's best to check it out first in your environments (create test VM, create test replication job with test VM, make several replications, move VM replica to single ESXi and migrate all others VM replicas to other ESXi hosts, disconnect ESXi with test replica, connect ESXi to new vCenter, refresh VC in B&R, update SQL, test replication job after changes).
3. DC/CL/Folder layout was the same in both VC.
4. You have to write down old and new MoReF IDs.
5. I did several replica restore tests - all of them worked for me.

Maybe this will help anyone with replicas migration.

[eric]

A virtual machine was removed and readded to vCenter. This caused backup and replication jobs (Veeam 7) to fail.
The jobs were edited to remove and add the vm.
However the jobs created new backups and replication machines for the vm.
How can the vm be pointed back to the original backups and replication machine?

TIA,

~eric

[foggy]

Hi Eric, the behavior is expected due to VM getting new ID upon re-registration in vCenter. You can map the jobs to existing backups/replicas, however, the entire VM will still be read during the first job cycle after this. Please reveiw the thread above for additional considerations.

[deesloop]

I'm implementing a new Vcentre 6.1u3 virtual appliance
I have a 5.5 just now and wondered if there were any issues migrating from one to the other that could affect Veeam.
Aside from the changes in names etc?
Once complete I'll migrate 5.5 hosts to 6 also.

Thank you

[deesloop]

I migrated all my VMs to a new Vcentre
I used the tool to do the donkey work and it appeared to have worked.

However
All my backups fail, and I'm not sure how to do handle replication.

Having run the tool I did a recalculate on all the backup jobs and they all changed size which suggest they were at least scanned.

However Im getting a connection issue

Error: Cannot get service content. Soap fault. TimeoutDetail: 'connect failed in tcp_connect()', endpoint: 'https://172.16.64.45:443/sdk' SOAP connection is not available. Connection ID: [172.16.64.45]. Failed to create NFC download stream. NFC path: [nfc://conn:172.16.64.45,nfchost:host-94,stg:datastore-62@Term1/Term1.vmx].

When can I power off the old VCentre?

[foggy]

Hi Darren, have you re-pointed your jobs to VMs via new vCenter?

[deesloop]

Yes I have. I logged this with support but just as I did the fuirst backup worked.
However I now have issues backing up to the cloud.
Nothing ever straightforward.

[tinto1970]

hallo, i'm posting a new "experience" with the use of vCenter Migration Tool:

we had a 2 ESXi 5.5 host cluster, using NFS on NetApp datastore. Backup from storage snapshot was working fine. In the upgrade path to new vSphere version, we have installed a new VCSA 6.5 appliance, and we have connected the ESXi hosts to the new vCenter. We have remapped our existing jobs to the new vcenter using the vCenter Migration Tool. Than we have performed a rescan of the vCenter and a rescan of the NetApp storage system.

Jobs run fine but they are failing back to network mode, instead of using storage snapshots.
But I tried to deploy a new VM for test purpose, and created a new Backup Job saving only this VM: in this case, backup from Storage Snapshot works fine.

I know the tool is not officially supported, but i tried to open a ticket [ID# 02120021]

The B-plan is to recreate new jobs from scratch (i have enough space in my repo to host full backups before deleting the old ones).

[veremin]

Before re-creating everything from scratch, can you re-create one particular job, map it to already created backup files and see whether this fixes problem with processing mode?

[tinto1970]

yes: it works.
By doing so, the task " Collecting disk files location data " is executed and, once again, it retieves data from storage snapshots

[veremin]

Then, it might be worth proceeding and making the same changes for all existing jobs. Most likely changes done by custom utility lead to job inability to leverage the given processing mode, and jobs recreation is needed. Thanks.

[deesloop]

This didn't work for me and the only way to resolve it was to create all new jobs.
Very time consuming and a real disappointment.

[tinto1970]

Then, it might be worth proceeding and making the same changes for all existing jobs. Most likely changes done by custom utility lead to job inability to leverage the given processing mode, and jobs recreation is needed. Thanks.

i did so.
Cloning the old jobs, deleting the old ones and and mapping the new ones to the files has worked

[veremin]

Thank you, so, some manual efforts such as job re-creation and job mapping might be needed in case infrastructure using backup from storage snapshots is migrated to new vCenter server.

[tinto1970]

yes, it could be worth the case to add some line in the vCenter Migration Tool Documentation.
This behaviour is not immediately evident if the jobs have enabled the "failover to standar backup", because backups still work, but loose the advantages of storage integration.
Luckily i like to double check things

As mentioned before, performing a clone of the job, deleting the old one and mapping new job to the old files is fast to be done, and ensure that new job has exactly the same setting of the former one.

P.S.: It's also a good idea to try a restore, after all this work

[eltonhsu]

Hello,
I have a bad/failed vCenter Server Appliance which I could no longer access from vSphere client, web client or Veeam.
My question is if I reinstall the appliance, would it break the backup chain once I add, or re-authenticate the server back to Veeam? I intend to keep the same server name, domain(actually AD) and the same AD account and password.

Thanks,
Elton

[Vitaliy S.]

Hi Elton,

Yes, all VMs IDs will be changed to new ones (assigned by the new vCenter Server). You will need to re-map all existing backup files to the new VMs.

P.S. maybe a workaround in this topic will help, please take a look at the last 2 pages.

Thanks!

[sconley]

I am likely going to have to rebuild our primary vCenter server due to OS issues. If I re-map all of our production jobs to the new server what can I expect? I am assuming/hoping this does not trigger full backups. Will it mean that I can expect a longer backup window on the initial run as it will have to do a full scan of all the VM disks?

[jmmarton]

If you rebuild the server but keep the original vCenter database, you shouldn't have an issue. But if you're starting everything over from scratch, then all VMs will have new IDs so by default the next run will be a full backup. However if you contact support they could help you modify the IDs in the VBR database to match what's in the new vCenter database so that you continue the existing chains. I believe there's also a script that can help you do this.

Joe

[albertwt]

Thank you, so, some manual efforts such as job re-creation and job mapping might be needed in case infrastructure using backup from storage snapshots is migrated to new vCenter server.

Hi Vladimir,

So which backup method can be done to backup VM quicker after the VCenter rebuild?

My current VMs are now backed up using the hotadd method and it is very slow due to the CBT reset.

[foggy]

It's not down to the transport mode, but to the fact that entire VM has to be re-read after CBT reset.

[albertwt]

Hi Alex,
So in this case, there is now way to get around it or reduce the backup window due to CBT reset ?

[foggy]

If it's due to the fact that VMs have changed their IDs, the only way is to perform ID matching in Veeam B&R database prior the first job run after the change, using the tool discussed in this thread. In case your jobs are already running, just wait for the completion, the next run will use CBT as usual.

[albertwt]

Ok,

I have re added the VM backup to the existing backup job, so if I run the script, does the incremental will continue from before I deploy the new VCenter server ?