ERROR CODE [91:139]: Unable to connect to virtual machine host

Hey @GNeal!  Thanks for the new topic.  Quick question for you (as I have seen this be the cause numerous times).

Are you typing the password in manually or copying and pasting?  Assuming the latter, make sure you don’t have any trailing space, and are copying out of notepad.  I’ve seen Word copy and paste actions bring in some invisible formatting ‘characters’ that throw the password out of whack.

With that in mind, is this AD account in use across multiple agents?  Are they all failing or only some?

Where exactly did you update the password?  another common cause is that the password gets updated in one place, but not another (which is the hang up).

I manually type since I was aware of the copy & paste issue. AD account used in multiple areas and have used the “user account management” feature in control panel and also manually by going to each areas where credentials are set.  It’s weird because it works sometimes and then sometimes not, with no interaction from me so that I could try to pinpoint failure point. I notice we are currently on 11.19 v16, so next move is to upgrade to 11.20

I am not aware of any change from 11.19 to 11.20.  Definitely strange as it is inconsistent.

I searched our ticket history for the error and found some items that might help:

1. Disable the account lockout in vCenter as well as disable password history requirements
2. Temporarily moved VMs to a new subclient to isolate the issue, but a full backup ran successfully for the affected VMs and upon moving them back they continued to back up successfully (though in your case, it might help to narrow down the issue)

These are two separate items though you can see if either help.  If not, we should get the log files to see what the greater detail shows us.

I’ll also get some other eyes on this thread.

So the first question I would have is which log is reporting the error. vdiscovery or vsbkp as this will tell us where the communication error is and what phase of the job.

If the proxy is Windows machine, you can simulate the login by connecting to the vcenter using Internet Explorer (without /sdk) and try to login with those credentials.

The log error example would be:

####### CVMWareInfo::Connect() - Connecting to Url=[https://vcenter.example.com/sdk] User=[domain\user]

The proxy needs access to the Vcenter on port 443 and all the ESX hosts on 902.

https://documentation.commvault.com/commvault/v11_sp20/article?p=96273_2.htm

In an environment with firewalls, the vCenter, ESX servers, and Virtual Server Agent must be able to communicate with each other. To ensure that all components can communicate through the firewall, ensure that the ports for web services (default: 443) and TCP/IP (default: 902) are opened for bidirectional communication on each of these machines.

Sometimes the error can be caused by other issues, like vCenter timing out on getting back to CV or being temporarily unavailable etc. as @Aplynx mentioned, might be worth taking a quick look at the vsdiscovery or vsbkp logs to see if there is more information.

@GNeal is it possible to created a new vcentre machine while the old vcentre is still powered on and the request is forwarded to it.

Hey @GNeal!  Following up on the great advice above.  Anything here resolve the issue for you?

Thanks!

Thanks, @GNeal !  I marked that as the Best Answer but if it fails, come update the thread.