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