Case #07109835 for those interested.
Have a VBR server with 20+ replication jobs and 130+ servers, replicating to our DR environment with multiple hosts and clusters (vmware). We have new hosts that were added to existing clusters, replacing the existing hosts. VM's (including replicas) were vmotioned off the old hosts onto the new hosts before they were removed from the cluster.
Almost all of the replication jobs now give me an error:
1/29/2024 5:01:42 AM :: Failed to create processing task for VM **vmname** Error: Host with id 'f*******-e***-4***-9***-1***********' was not found.
Implying the job needs the old host in order to run, even though the replica exists in the cluster and shouldn't be dependent on a host.
What is way more frustrating is that I cannot EDIT these jobs - it gives me the error below if I try to edit:
"Object reference not set to an instance of an object"
- If I try to clone the job, the cloned job gives me the same error.
- - - I tried cloning them in powershell and it has the same result
- I also can't DISABLE most of the jobs, so those jobs are continuing to run and fail repeatedly throughout the day, absolutely spamming my email with hundreds of failures.
- - - I tried disabling the jobs in powershell and it has the same result "Object reference not set to an instance of an object".
- We tried adding an "old" host back into vcenter temporarily to see if it would change anything, but no luck. I am thinking the "host id" doesn't stay the same when a host is removed and later added back to vcenter.
I had a similar issue with this last fall due to a host failure, and I ended up having to rebuild the jobs, as well as rebuild my Orchestrator Datalab from scratch.
Anyone know why a Replication Job, which does NOT point to any hosts directly, can't handle new hosts replacing old ones? It should be a pretty common situation, but I don't see a ton of forum posts out there with the issue, especially with no ability to edit, disable, or even clone jobs, which is extremely frustrating and non-sensical.