Owner host for VM "server" is unavailable after upgrading from B11-12

[stkvskivecollege]

Hello. Case #05977413

We recently upgraded our Veeam Backup & Replication build from version 11 to 12.
After the update we ran our backup jobs and recieved an error on 70% of the jobs.

the error states: "Owner host for VM "server" is unavailable"
We got 2x VM host groups, one of them seems to be working flawless after the update,
while the other VM host group seems to be having some problems, the group is hosted on 4 servers with only servercore installed, so that means no desktop available.

What we have tried so far:
Rediscovered disk and volume info
Removed the affected VM's from the backup job and added them back again.
Removed and reinstalled Veeam Installer Service, Veeam HV integration and Veeam Transporter on the affected host

Any else had this problem and came up with a fix?

[Mildur]

Hi Stefan

I found two other cases.
One was created by your organization and then closed.
The second one was resolved by rebooting the affected hosts.

I'll suggest to keep working with our support team. Ask them if the logs are showing connection issues to the VM hosts.

Best,
Fabian

[stkvskivecollege]

Hi Fabian,

I've tried working with your support team, but the contact is scarce, its 1 mail pr 8 hour ish,
and we had the problem for 9 days now. Assuming you guys are busy
Thats why i tried my luck in here, it could be that somebody had the same issue

[Mildur]

Hi Stefan

You can always Contact Veeam Support Management if you feel the case is going nowhere:
https://www.veeam.com/kb2320

I'll ask support management to have a look at the case.

Best,
Fabian

[stkvskivecollege]

Still searching for a solution

[Mildur]

Hi Stefan

I'm sorry to hear that.
Is only one host affected?
Do you still have VMs without any backups or was there a workaround provided for those VMs?

Best,
Fabian

[stkvskivecollege]

Hi Fabian,

yes, it's 1 of ours 2 clusters which is affected
Sadly we still have no backups for the last 28 days.

[Mildur]

Hi Stefan

Thanks.
I'm in contact with support management regarding your case.

Would it be possible to use Agent backups as a workaround until the issue with the cluster is solved?
Just for the most critical server.

Best,
Fabian

[stkvskivecollege]

Hi Fabian,

Our case was escalated to another tier last week, so they might be looking at it atm, but we dont know since we haven't heard from them.
My hope was just that, somebody on the forum, since my last post had figured out the issue.

It might be a possibility use Agent Backups for now, ill look into that

Best Regards
Stefan

[Mildur]

Hi Stefan

Yes, I saw the escalation.
Please be aware, escalation doesn't mean that there is a solution the same day. But you should have gotten at least an answer from an escalation engineer about the next steps. That's why I started the discussion with support management.

My hope was just that, somebody on the forum, since my last post had figured out the issue.

Understandable. I never saw this issue myself, so I cannot provide more information about it.

Best,
Fabian

[dgn]

So after digging for a long time we found the solution.
For some reason, our VMM had 25.000 planned VM's running in our environment and Veeam couldn't find the realized ones.
I have no clue why this has happened, but luckily we were able to clear all the planned ones without destroying any VM's (Even VM's that hasn't been running for more than 2 years had 300+ planned)
After we cleared it seemed that the error disappeared as the log file came down below 999 entries.
After searching it all through again and seeing that no one else seems to be dealing with this problem than us, I guess this was just an unlucky coincidence.
But I must mention, I am pretty sure, that a script-change somewhere from version 11 to version 12 did this.
E.g. We were told to run this PS-script from the support:

Code: Select all

Get-WmiObject -Namespace "root\virtualization\v2" -Query "SELECT VirtualSystemIdentifier, BiosGuid, VirtualSystemType FROM Msvm_VirtualSystemSettingData"

If this was changed to

Code: Select all

Get-WmiObject -Namespace "root\virtualization\v2" -Query "SELECT VirtualSystemIdentifier, BiosGuid, VirtualSystemType FROM Msvm_VirtualSystemSettingData where VirtualSystemType='Microsoft:Hyper-V:System:Realized'"

I'm pretty sure we would've never had the issue in the first place.
Even tho' we had to figure it out ourselves, I wanna say thank you to all the supporters we had helping us on our ticket, for guiding us down this path and eventually finding the error. Even if we feel like the answering hours could/should be shorter in cases like this.
Best- Daniel

[AngusThermopyle]

What was the script that actually fixed this? We're seeing this crop up more and more on random hosts. Sometimes a reboot fixes for weeks, other times it doesn't fix it at all.

[kavoshz]

So after digging for a long time we found the solution.
For some reason, our VMM had 25.000 planned VM's running in our environment and Veeam couldn't find the realized ones.
I have no clue why this has happened, but luckily we were able to clear all the planned ones without destroying any VM's (Even VM's that hasn't been running for more than 2 years had 300+ planned)
After we cleared it seemed that the error disappeared as the log file came down below 999 entries.
After searching it all through again and seeing that no one else seems to be dealing with this problem than us, I guess this was just an unlucky coincidence.
But I must mention, I am pretty sure, that a script-change somewhere from version 11 to version 12 did this.
E.g. We were told to run this PS-script from the support:

Code: Select all

Get-WmiObject -Namespace "root\virtualization\v2" -Query "SELECT VirtualSystemIdentifier, BiosGuid, VirtualSystemType FROM Msvm_VirtualSystemSettingData"

If this was changed to

Code: Select all

Get-WmiObject -Namespace "root\virtualization\v2" -Query "SELECT VirtualSystemIdentifier, BiosGuid, VirtualSystemType FROM Msvm_VirtualSystemSettingData where VirtualSystemType='Microsoft:Hyper-V:System:Realized'"

I'm pretty sure we would've never had the issue in the first place.
Even tho' we had to figure it out ourselves, I wanna say thank you to all the supporters we had helping us on our ticket, for guiding us down this path and eventually finding the error. Even if we feel like the answering hours could/should be shorter in cases like this.
Best- Daniel

Hello

I have the same problem after updating from 12.0 to 12.2.
I would be happy if you could give me more tips to solve this problem.
Which script did you actually use for that?

Thanks

[Mildur]

Hi

I don't have a case number from DGN, so I can't check for you.
Please contact our customer support team and let them investigate the logs of your environment.

Best,
Fabian