Enter the https server's thumbprint: xx:xx:xx:xx:xx:-------
Connecting to vCenter [win-gu0ugqsk9mv.egi1.vdi.local]...
Cannot connect to the vCenter. Run the script again. If the problem continue, reopen PowerCLI.
ERROR: The process with PID 14584 could not be terminated.
Reason: There is no running instance of the task.
———————————————————————
Note: I changed the thumbprint above from the actual value.
So yes, it appears that the IP address of the vCenter server is not accessible on port 65101, which is correct. I cannot connect to my vCenter server on that port. No, there is no firewall on that system, so the question is what service is supposed to be running on that port?
There is nothing in the install that I saw that shows anything about running a service on vCenter prior to installation.
The IP address questions were confusing, because I've never had a program ask for the IP of the system I am on. I tried multiple combinations, and the IP in the example was actually that of the vCenter server. Using the IP of the system I was on produced a different set of errors.
I did find a solution. The problem turned out to be that the FQDN does not work in your PowerShell script, even though I can ping the FQDN with no problems. That is "ping xxx.a.b" where xxx is the hostname and a.b is domain works fine from the powershell command line. BUT, it does not work in your script.
So the solution was to use the IP address instead of the FQDN, and then everything worked. Seems like a bug somewhere in the script, or at the very least room for enhancements.
Can you please clarify whether 172.16.1.84 is the IP address of the vCenter server, or the Windows box you are running the plugin from? Or are you running the plugin from the vCenter server itself?
Sometimes the plugin isn't working great when it's running on the vCenter host - one of the fastest workaround is to manually deploy an SVM, install the IM Gateway manually (rpm -i, the installation packages are under "install" folder in /root directory of the SVM) and use Advanced installation - then point the plugin to the freshly installed Gateway, rather than to the Windows host where you are running the plugin from - in 95% of cases this trick allows you to register the plugin quickly and flawlessly,without need to debug Windows services (which can be painful).
RussFellows
1 Rookie
•
4 Posts
1525
2
Posted May 17th, 2016 08:00
Thanks for the pointers.
The IP address questions were confusing, because I've never had a program ask for the IP of the system I am on. I tried multiple combinations, and the IP in the example was actually that of the vCenter server. Using the IP of the system I was on produced a different set of errors.
I did find a solution. The problem turned out to be that the FQDN does not work in your PowerShell script, even though I can ping the FQDN with no problems. That is "ping xxx.a.b" where xxx is the hostname and a.b is domain works fine from the powershell command line. BUT, it does not work in your script.
So the solution was to use the IP address instead of the FQDN, and then everything worked. Seems like a bug somewhere in the script, or at the very least room for enhancements.
Thanks.