Failover to VIX incredibly slow in v13

[cmaier]

Case #07902693

Hello,

Some of our VMs are located in isolated networks that cannot be accessed by the backup server and the proxies. In version 13, failover to VIX is incredibly slow compared to version 12.

Here is an example of a machine that was backed up under v12:

Code: Select all

25.11.2025 22:45:13 Succeeded : Network traffic will be encrypted
25.11.2025 22:45:21 Succeeded : Using guest interaction proxy Proxy2 (Different subnet)
25.11.2025 22:46:10 Succeeded : Failed to inject guest runtime components via GIP, failing over to guest agent connection via GIP
25.11.2025 22:46:34 Succeeded : Failed to connect to guest agent via GIP, failing over to guest runtime components through VIX via GIP
25.11.2025 22:48:42 Succeeded : Inventorying guest system (0:00:39)

The same machine under v13:

Code: Select all

27.11.2025 19:26:12 Succeeded : Network traffic will be encrypted
27.11.2025 19:26:22 Succeeded : Using guest interaction proxy Proxy1 (Different subnet)
27.11.2025 19:28:22 Succeeded : Failed to inject guest runtime components via GIP, failing over to guest agent connection via GIP
27.11.2025 19:41:20 Succeeded : Failed to connect to guest agent via GIP, failing over to guest runtime components through VIX via GIP
27.11.2025 19:43:13 Succeeded : Inventorying guest system (0:00:13)

The execution time has increased from 3 to 17 minutes. When a machine is stuck in failover, it also blocks a connection to the repository, meaning that at some point no further tasks can be executed in parallel. This messes up our entire backup chain.

Is this a known issue? Are there some reg keys to accelerate the failover to VIX for certain jobs or VMs?

Thanks, regards
Christian

[Amarokada]

There is a registry setting listed here: https://veeam-best-practices-guide-v9.r ... ssing.html

This can make VIX attempts happen before RPC attempts (but frustratingly doesn't affect the credentials test screen). I'm hoping this reg key still works in v13.

I would be very interested if you already have this reg key in place, or what happens afterwards, as we also have issues since going to v13 and we are using this reg key. In our case it seems the whole vix communication path /agent injection is taking longer than before and in many cases timing out, so we've disabled AAP on those jobs until we have a fix. I do have a ticket open where I have already given in-guest logs, and the next request has been to capture a VSS trace but I haven't got around to it yet, maybe later today I can do that.

[Mildur]

Hi Christian

I have replaced your contract ID #03 with the case number #07.
The key (InverseVssProtocolOrder) should still work in version 13.

@cmaier
I haven't heard yet of similar issues. Therefore please continue with our customer support team.
If required, the case will be escalated to the next tier. You can ask for an escalation yourself if necessary (by using the Talk to a Manager option).

@Amarokada
Can you please share your case number?

Best,
Fabian

[Amarokada]

Yes, it is in my post about this similar (if not the same) issue.

vmware-vsphere-f24/aap-failing-on-most- ... 01160.html

Also, the first line I got back from the service desk chap was:

"Thank you for the logs. I'm currently investigating this, as there seem to be a number of similar cases already after v13 upgrade."

Still waiting for it to pop into the "Top Issues tracker" sometime soon.

[cmaier]

Ok, thanks Mildur. Let's see how it goes.

InverseVSSProtocolOrder still works in v13, yes. But only 10% of our VMs are in an isolated network. For the rest of the machines, this reg key has negative effects. And there are also machines that could be reached by the backup server but still attempt a failover because something with VIX is not functioning. This failover also takes an extended period of time.

[jry]

I saw these same messages in the servers that are failing since v13 due to hypervisor timeout. Most are on different subnet from proxy due to being behind a firewall. They were all fine before v13. I have also noticed it being slower but hard to tell because when they hang, they hang for a long time with 0 read/write, then fail, then retry so it goes through it all again, fails again then moves on so tracking overall end time in the morning varies. Prior to V13 I had 2 times where a server hung and never failed or moved on and I was told there is no timeout you can set to force it to kill it and move on. In those cases none of other chained jobs ran until I manually stopped it the next day after running like 7-10 hrs on one server. I haven't seen that yet with v13 but it has only been 2 wks.