Proxy.xml which we use to modify to enable HTTP for vSphere SDK is not found in ESXi 5.1 server @ /etc/vmware/hostd while the documentation claims it is. Is this file located in a different location on ESXi 5.1 server. How do we enable HTTP for ESXi 5.1 server.
I'm having the same problem, the file just isn't there..
I really need to change the listening ports from the defaults 80, 443 and 902 to other values.
I tried looking into the advanced settings in the vSphere Client, but no luck there either..
In ESXi 5.1, the proxy configurations for service endpoints no longer live in /etc/vmware/hostd/proxy.xml and now reside in /etc/vmware/rhttpproxy and within that directory, there is a new general configuration for the reverse proxy called config.xml and a new endpoint configuration file called endpoints.conf
This new change allows you to make proxy configuration changes without needing to restart hostd, you just now need to restart the rhttpproxy service (/etc/init.d/rhttpproxy restart).
Thank you! Will look into it tomorrow when I have shell access to the host.
Okay, so I edited /etc/vmware/rhttpproxy/config.xml to read:
<proxy>
<!-- default location of the proxy config file -->
<endpoints>/etc/vmware/rhttpproxy/endpoints.conf</endpoints>
<!-- HTTP port to be used by the reverse proxy -->
<httpPort>8080</httpPort>
<!-- HTTPS port to be used by the reverse proxy -->
<httpsPort>8081</httpsPort>
</proxy>
The host still respond at ports 80 and 443 and not at all on 8080 or 8081. I have rebooted to make sure changes was read in, still no change.
hm, I'm seeing the same in my home lab:
~ # esxcli network ip connection list | grep rhttp
tcp 0 0 127.0.0.1:52618 127.0.0.1:8307 ESTABLISHED 4888270 rhttpproxy-work
tcp 0 0 127.0.0.1:443 127.0.0.1:59750 ESTABLISHED 4888265 rhttpproxy-work
tcp 0 0 0.0.0.0:443 0.0.0.0:0 LISTEN 4888262 rhttpproxy-work
tcp 0 0 :::443 :::0 LISTEN 4888262 rhttpproxy-work
tcp 0 0 0.0.0.0:80 0.0.0.0:0 LISTEN 4888262 rhttpproxy-work
tcp 0 0 :::80 :::0 LISTEN 4888262 rhttpproxy-work
rhttpproxy is still listening on port 80 & 443 ... I'm not sure if this is expected or not.
Do you mind filing an SR with VMware Support?
Will do. Thanks for the confirmation!
Actually I can't since the Hypervisor isn't covered regarding support.. :smileyplain: I don't have a commercial licence.
You should get a license I'll see if I can ping some folks internally and see if there's an issue with this.
In the meantime, I did find a quick "workaround". It looks like the port info isn't being read from the configuration file but if you specify it on the command line, it does in fact work (make sure you add the ports to ESXi firewall else it you won't be able to connect).
Edit /etc/init.d/rhttpproxy (you'll need to make a copy then mv it back) and locate the this line:
/sbin/watchdog.sh -d -s $RHTTPPROXY_TAG rhttpproxy ++min=0,swapscope=system,group=hostd -r /etc/vmware/rhttpproxy/config.xml
and just add the following
/sbin/watchdog.sh -d -s $RHTTPPROXY_TAG rhttpproxy ++min=0,swapscope=system,group=hostd -r /etc/vmware/rhttpproxy/config.xml -a 8080 -b 8081
where -a is for http and -b is for https
Then just restart the rhttpproxy service and you can confirm that the ESXi host is now listening on the new ports specified and I was able to connect using the vSphere C# Client using the modified ports.
That didn't work at all for me. It says that the proxy is killed, then started, but it doesn't show up as listning at all.
When I reboot, the system restores the original /etc/init.d/rhttpproxy so it's a catch-22.. :smileyplain:
Double check your steps, I've been able to get it working. Regarding persistenance, you can use VIB Author to create a custom VIB, take a look at this article once you've got it working http://www.virtuallyghetto.com/2012/09/creating-custom-vibs-for-esxi-50-51.html
Oh well, hopefully it'll be sorted out soon if you can get in touch with someone as you mentioned.
For now I simply route the ports in my firewall to the standard ports on the host, so when I'm in a remote location I switch configuration files for the client to use the alternative port. Not optimal, but it works.
Hello, I still see this issue on a 5.5 U3 build build-4179633. I see that the workaround resolve the issue. The issue is not seen from 6.0 onwards.
Does this mean it's a known issue in 5.5.x and 5.1 ? I'll compare the rhttpproxy.log b/w the failing and passing versions to see if we can get more info.