Dis-/reconnect ESXnode from VCenter, Veeam backup-job broken

[ThierryF]

Hello,

Due to some issue with one of our Cisco Hyperflex cluster, we had to disconnect and
reconnect all of my ESX Hosts (all hosts from the farm) from the VCenter,
keeping same hostname/IP...

Doing that, Veeam (9.5.3) loses track of vms and I have to edit each jobs
to remove ghost vms from these farm and add them back to job.
I also gave a try to "Recalculate" storage info from VMs within the job
but Storage size remains at 0.

Strange as nothing changed at VM level ...

Bug/Feature ?

Thanks !

TH

[veremin]

VMs got new MorefIDs assigned upon host re-connection. As the result, backup server lost track of them. So, it's expected behaviour. Thanks.

[jhoughes]

This is because when the VMs got added back to the inventory, all of the MoRef IDs of your VMs themselves changed, which is really what was being targeted by the jobs. That inventory change within your vCenter environment that caused this issue within Veeam.

If you build you jobs based on vSphere tags, then you can avoid these types of issues, as any VMs with an appropriate tag will get picked up at every job run.

[ThierryF]

Thanks for your inputs !
Cheers
Th

[veremin]

You're welcome. Let us know, if other questions arise. Thanks.

[arun.kr]

Hello Everyone,

We are migrating VMs from old vCentrer 5.5 to new vCenter 6.5. While configuring the VEEAM backup jobs, we have removed the object (VM to be processed) from old vCentrer and add the object from new vCentrer.

after some days i checked the jobs status and i can see my jobs are completing with one information

VM_Name is no longer processed by this job. Make sure this change is intentional.

Please note - VM display name is same as it was in old setup. Both Vcenters are in same subnet.

just want to know what wold the best practice in such situation if VM names are same as in old setup. Should i configure the new jobs or it is good to modify the job with objects from new location.

Thanks
Arun

[veremin]

VMs are tracked by MorefIDs, not by names. So, the situation described is expected. Thanks.