Unable to find Hyper-V hosts where VM is registered after moving subnet

[RGijsen]

Hi,
as I'm not sure if I've had enough coffee, I'd like to consult here before opening a ticket. Yesterday we had planned maintenance, and one of the things done was to move the Management OS interfaces of all our Hyper-V hosts to our management VLAN. Until now they were in the VLAN were (most) of our VM's actually belong. The Veeam server was still in that production LAN, as that's were the hosts reside, and therefore no need to route all traffic through the firewalls (offhost never worked well for us). I opened ALL protocols (UDP, TCP, ICMP and all others) from the Veeam server to the Hyper-V hosts, and vice versa. I know about the firewall requirements, but for now I just allowed all.

Still, I now got messages like:

22-10-2018 06:22:14 :: Unable to allocate processing resources. Error: Unable to find Hyper-V hosts where VM '<VM GUIS>' is registered

However, in the job themselves, I could see the VM's just fine, application aware tests worked fine, the hosts themselves were accessible and 'rescannable' without issues, repositories were available. I just could not find any communications issue, as, well everything was opened up.
In the end I ended up moving the Veeam host to the management VLAN as well, which was an open point anyway now the Hyper-V hosts had moved, and after that everything works as expected again. However, I still wonder why I was getting these issues. Anyone with some insights?

[Mike Resseler]

What I am assuming here is that (I can't give a reason at this moment, maybe I also need coffee ) the Veeam server needs to use the specific VLAN to query the GUIDs. I am assuming this was at the start of a job?

[jmustonen]

I had this same "Unable to find Hyper-V hosts where VM '<VM GUIS>' is registered" after I did change IP-addresses for the hosts in Hyper-V clusters. All tests passed just fine, but jobs were not able to backup vm's.

The fix was easy, I just had to reboot the Veeam-server. I think it may have been sufficient just to restart Veeam services, but I did install Windows Updates, so reboot was necessary anyways.

I believe that Veeam has some sort of cache of the Hyper-V Hosts and VM's, and this gets cleared on service/server restart. But I'm only guessing here..

[foggy]

Yes, most likely infrastructure rescan (happened automatically every few hours or triggered manually) would have also helped in this case.

[thats2odd]

I also experienced this issue and a Backup server reboot fixed the issue. I did try to rescan the host and the scan compiled successfully but I would still get the error. Reboot was a complete fix

[EricF]

I just have this error. Services restart corrected the problem.

[Coppens]

I had the same issue after I changed the windows domain account(s) password.
Just changing the credentials in Veeam was not enough. Reboot of the backup server after change and then run it did the trick.

[Mossmak]

Restarting the VEEAM services will also fix this, avoiding a server reboot.

[JCat]

Not Necessary to Restart as indicated by others. Reset password in Veeam Credential Manager; Stop "all" Veeam Services, then Start "all" services. Rescan your Host Server and Rescan the backup Inventory. Run a QuickBackup to make sure things are working.
I recommend using a BU standard (one where PWD doesn't automatically change) Service Account. Not sure whether Veeam BR supports Active Directory MSA or GMSA, but in general I am seeing people say that the VBR should not be on a Domain Joined computer so that may settle that question.

[PetrM]

Hello,

And one more recommendation: please always create a support case for any technical issue. Without debug logs analysis and infrastructure examination, we cannot guarantee that a workaround provided on the forum would help in every case.

Thanks!