First of all, this is not a big deal to us. We had this problem since version 5(that we noticed) and still have it in version 8. But it is of some annoyance to people who have to do VM restore, and don't now Veeam all that well(so then hey call me).
We have an environment that consists of ESX servers of different subnets(sites), with different kind of storage connected to them. On smaller sites they use local storage, on lager sites they have SAN's connected to them.
Not sure if it is of significance to the issue, but our Veeam environment is completely virtual, so our veeam backup repositories are virtual servers with VMDK's on SAN. Backup server and procy's are all virtual too. Of course all the backups are done to offsite locations.
Also we use daily replica's a lot for the smaller sites where we make sure all the VM's on the "first" ESX host are replicated to the "second" ESX host(in case of emergency operators could power on those replica's without having to do a restore) and vice versa.
Now the issue: sometimes when doing a restore(from backup mostly) Veeam selects the wrong backup proxy. A backup proxy that is on the wrong subnet, and more annoyingly does not have access to the local storage on the site/ESX server that we want to restore to. So what happens is that it restores the .vmx, vmxf and .vram files(using network), and then wants to restore the .vmdk files. Off course that won't work(I wants to use SAN mode sometimes too - it should never do that), and then after a few minutes it throws the error "failed to open VDDK file ...." . When I do it again, an manually select the right proxy, it works fine.
The veeam proxy's are up until now all on "automatic"(so selection of datastores and transport mode), but I probably will change that and see if it helps. Local storage datastores all have unique names on the ESX hosts across the network.
I don't think there is any kind of configuration error. Veeam should know that proxy A(on ESX A with local datastore A) does not have access to ESX B(with local datastore B). But it selects it anyway, and therefore the job fails. When I edit proxy A, and see which datastores I can manually configure, datastore B is not one of them(I see the correct datastores there).
Any ideas on why this is happening?
I know that it's probably fixed by manually configure all proxy's(datastores and transport mode), but should work on automatic too right?
Thanks in advance!