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.