So I'm finding out tonight that the "minor" update from 2.0.2 to 2.5 is now requiring 443 to be open thought the firewall to my hosts. This seems rediculous that they would change what ports are needed and not mention this except in one document ( page 183). The pictures don't even show this clearly, they show 443 for your VI client to ESX but VC to ESX shows 902. No other document mentions or shows communication between VC and ESX needing 443. Is anyone else effected by this? I will have to redesign my infrastructure as infosec will not allow 443 to be open to my hosts on external DMZs.
Someone please tell me this isn't so. What was wrong with using just port 902? Worked fine for us for so long.
902 is just for VC communication to ESX Host.
To protect against misuse of ESX Server services such as the internal Web server that hosts VI Web Access, most internal ESX Server services are accessible only through port 443, the port used for HTTPS transmission. Port 443 acts as a reverse proxy for ESX Server
You do not need 443 to manage esx from vc. I have just disabled 80 and 443 on my ESX host's firewall, but all functions remain in tact from vc. Only 902 is required for VC - ESX communication. The 80/443 for ESX is to connect with webaccess.
-KjB
VirtualCenter Server listens on 80, 443 and 902
443 is used by the VI WebClient
902 is the way which your ESX hosts will talk to Virtual Center
443 is also used with VCB 1.1 and VC 2.5
If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points
Can anyone clarify what is needed to add ESX hosts to VC 2.5? The diagram and documentation do not claim 443 is needed yet I cannot connect hosts and the firewall shows 443 getting dropped. I need to know which way 443 is needed and if it is UDP or TCP so I can re-architect my environment. The documentation is not clear:
443 HTTPS access.
The default SSL Web port. Use Port 443 for the following:
Connection to VI Web Access from the Web.
VI Web Access and third‐party network management
client connections to the VirtualCenter Server.
Direct VI Web Access and third‐party network
management clients access to ESX Server 3 hosts.
VI Client access to the VirtualCenter Server.
Direct VI Client access to ESX Server 3 hosts.
WS‐Management.
VMware Update Manager.
VMware Converter.
Incoming TCP
Against which server IP of yours is 443 getting dropped (from ESX to VC, from client to VC, etc.) You do not need 443 to connect your ESX servers, that's what 902 is used for. 903 is used for some console communication, but 443 is not used for vc <-> esx communication, unless you are running your browser from the VC host connecting to ESX.
-KjB
443 is being attempted by VC to ESX. I would like to agree that 443 isn't needed but my VMWare SE is telling me it IS needed.
If 443 is not needed why will my 3.0.2 hosts not connect to VC2.5?
2008-04-16 22:44:41.317 'App' 416 error Authd error: 551 There is no VMware process running for config file vmware-vpxa
2008-04-16 22:44:41.317 'App' 416 error Failed to connect to host tcesx30p.fnb.fnni.com:902. Check that authd is running correctly (lib/connect error 11)
Ah, 3.0.2 not connecting to 2.5 vc is different question.
I've had this issue several times with my 3.0.2 hosts.
This is what I did:
Remove server from vc
Remove the rpm for the vc client
Delete the vpxuser.
Makesure /tmp/vmware-root directory exists
Re-add server to vc.
This fixed my issues.
You can also check this out: http://communities.vmware.com/thread/103637
-KjB
Please check your settings in the Virtual Center Runtime Settings by clicking your Administration link and then Virtual Center Management Server Configuration. Click on RunTime Settings and make sure that your PORT is set to 902. Also check Web Service and your settings should be HTTP Port 80 HTTPS Port 443
Hope that helped.
I have been down the standard roads of restarting, removing, manually installing the vpx client and removing the vpxuser.
root@tcesx30p vmware-root# rpm -qa | grep vpxa
root@tcesx30p vmware-root# users
root
root@tcesx30p vmware-root#
Hosts are all connected fine before the upgrade and then show disconnect after the upgrade. Tested on a new VC server with a fresh database and get "Unable to access the specified host. It either does not exist, the servers software is not responding, or there is a network problem."
Good find KJB007,
they way you want to do that is putty into your host and type;
Service vmware-vpxa stop
rpm -qa | grep vpxa this will show you your vpxa number. Then to remove it you want to type
rpm -e VMware-vpxa-2.5.0-84767. This is an example of mine NOT YOURS. Your number will be different.
Service vmware-vpxa restart
Now reconnect to your VC. This should work.
Hope that helped.
There was a step in there that caused me a LOT of grief. When you are manually installing the vpx client, check to make sure the /tmp/vmware-root folder exists. I spent a week of the same hassle, until I found this folder was not there, after which I re-installed the vpx client, and things started working correctly.
-KjB
The service is not installed. So attempting to stop it results in:
root@tcesx30p vpx# service vmware-vpxa stop
vmware-vpxa: unrecognized service
The folder /tmp/vmware-root exists:
/tmp/vmware-root:
total 8.0K
drwxr-xr-x 2 root root 4.0K Apr 9 15:45 .
drwxrwxrwt 10 root root 4.0K Apr 18 04:02 ..
Do you get the same error if you type
service vmware-vpxa restart
Now, I would delete the vpxuser (userdel vpxuser) and try to connect host to vc.
-KjB
Yes, NOW try to reconnect, once you have reconnected thes do the
service vmware-vpxa restart
Hope that helped.
Mabey open a SR with VMWare and see what they say. It couldn't hurt because you shouldn't have to open a sucured port. Let us know what the fix is if you open the ticket with VMware.
Hope that helped.
Just stood up a 3.5 ESX host to test. Cannot connect that to my test VC2.5 install. Looks like 443 is needed.