[ER] VBR to remember how to connect to each VM and try that first in future

[AlexHeylin]

Current behaviour
During each backup of each VM try each method of connecting to the guest in a set order.
This takes up to 3.5 mins to connect to the guest every backup

Suggested behaviour
On first backup of a VM write to DB which guest connection method was successful.
On subsequent backups of that VM read from DB which method worked last time and try that first. If it fails, fall back to current approach of trying each in sequence. When one works, update the DB for next time.

I estimate this should save at least 2 minutes from the 3.5 min scenario above.
Given the VM task might only take 6-8 mins, that's a substantial time saving of around 28%.
This approach would also speed up the currently rather slow process of testing authentication - which can only be done for all VMs, including those with AAP disabled.

Code: Select all

13/12/2023 10:50:01 :: Queued for processing at 13/12/2023 10:50:01  
....
13/12/2023 10:50:12 :: Using guest interaction proxy MyLittleProxy (Same subnet)  
13/12/2023 10:52:25 :: Failed to inject guest runtime components via GIP, failing over to guest agent connection via GIP  
13/12/2023 10:53:01 :: Failed to connect to guest agent via GIP, failing over to guest runtime components through PowerShell Direct  
13/12/2023 10:53:30 :: Failed to inject guest runtime components through PowerShell Direct, failing over to guest agent connection through PowerShell Direct  
13/12/2023 10:53:40 :: Failed to connect to guest agent through PowerShell Direct, failing over to guest runtime components  
13/12/2023 10:54:22 :: Inventorying guest system  
...
13/12/2023 10:57:22 :: Processing finished at 13/12/2023 10:57:22  

[haslund]

Did you have the persistent guest agent installed on some virtual machines? Because it sounds like that is what was used in the end? If yes, you can under guest processing specify to use that on a per-VM level. I assume the request here would be to avoid doing that?

[AlexHeylin]

Hi hasland,
No, we're not using the persistent agent for this job or VMs.
The request is that once VBR has identified how to connect to each VM that it records it in the DB and tries that connection strategy first next time - rather than run through the whole process all over again next time.
Thanks
Alex

[AlexHeylin]

The HvVssPowerShellDirectPriorityOverNetwork registry value mentioned in microsoft-hyper-v-f25/powershell-direct-t50228.html partly addresses the issue, as we have lots of environments where the backup systems cannot talk to the VMs over the network so trying PowerShell Direct first reduces the delay each time the backup runs.

I suggest that this should be default behaviour in a future release because as PoShDi is supported in all modern Windows OS it's more likely to work than network in a properly network-segmented system (which they all should be) and as far as I can see has no downside because it will fall back to trying to access over the network if PoShDi isn't available.

It would still be good if VBR would remember which connection type to use (what worked last time) for each VM and try that first before falling back to the others. In a world where incremental backups take 5-10 mins to run, having VBR spend ~2-3 mins of that working out how to connect to the VM is suboptimal.

[AlexHeylin]

Instead of "PoShDi is supported in all modern Windows OS" above please read "PoShDi is supported in all supported Windows OS" as everything after Win Svr 2016 supports it, and nothing before that is still in standard support from MS.

[AlexHeylin]

Please also see microsoft-hyper-v-f25/feature-request-t81182.html which is a similar request / challenge.