vSphere 6.0 – Page 21

Quick Tip - Changing default port for HTTP Reverse Proxy on both vCenter Server & ESXi

10.27.2015 by William Lam // 11 Comments

If you decide to use a custom port for the HTTP Reverse Proxy (rhttpproxy) on vCenter Server which uses port 80 (HTTP) and 443 (HTTPS) by default, you should also apply the same change on all ESXi hosts being managed by that vCenter Server for proper functionality. The configuration files for the rhttpproxy has since changed from the early days of vSphere 5.x and in vSphere 6.x, there are now different.

UPDATE (04/27/18) - With release of vSphere 6.7, VMware now officially supports customizing the Reverse HTTP(s) Ports on the VCSA. Below is a screenshot using the VCSA Installer UI and this can also be customized in the JSON configuration file using the VCSA CLI Installer for automation purposes.

Below are the instructions for modifying the default ports for rhttproxy service for both Windows vCenter Server, vCenter Server Appliance (VCSA) and ESXi host.

Note: If you change the default ports of your vCenter Server, you will need to ensure that all VMware/3rd Party products that communicate with vCenter Server are also modified.

vCenter Server for Windows

On Windows, you will need to modify C:\ProgramData\VMware\vCenterServer\cfg\vmware-rhttpproxy\config.xml and look for the following lines to change either the HTTP and/or HTTPs ports:

Once you have saved the changes, you will need to restart the VMware HTTP Reverse Proxy service using Windows Services Manager.

vCenter Server Appliance (VCSA)

On the VCSA, you will need to modify /etc/vmware-rhttpproxy/config.xml and look for the following lines to change either the HTTP and/or HTTPs ports:

Once you have saved the changes, you will need to restart the rhttpproxy service by running the following command:

/etc/init.d/rhttpproxy restart

ESXi

Disclaimer: VMware does not officially support modifying the default HTTP/HTTPS ports on an ESXi host.

Pre-ESXi 8.0 - Use the following instructions:

On ESXi, you will need to modify /etc/vmware/rhttpproxy/config.xml and look for the following lines to change either the HTTP and/or HTTPs ports:

Once you have saved the changes, you will need to restart the rhttpproxy service by running the following command:

/etc/init.d/rhttpproxy restart

For ESXi 8.0 - Please see Changing the default HTTP(s) Reverse Proxy Ports on ESXi 8.0 for updated instructions
For ESXi 8.0 Update 1 and later - Please see Changing the default HTTP(s) Reverse Proxy Ports on ESXi 8.0 Update 1 for updated instructions

Automating full configuration of a VSAN Stretched Cluster using RVC

10.23.2015 by William Lam // Leave a Comment

A couple of weeks back I had spent some time setting up several VSAN Stretched Clusters in my lab for some testing and although it was extremely easy to setup using the vSphere Web Client, I still prefer to stand up the environment completely automated 🙂

In looking to automate the VSAN Stretched Cluster configuration, I was interested in something that would pretty much work out of the box and not require any additional download or setup. The obvious answer would be to use the Ruby vSphere Console (RVC) is a really awesome tool that is available as part of vCenter Server included in both Windows vCenter Server and the VCSA.

For those of you who have not used RVC before, I highly recommend you give it a try and you can take a look at this article to see some of the cool features and benefits. I am making use of the RVC script option which I have written about in the past here to perform the VSAN Stretched Configuration. One of the new RVC namespaces that have been introduced in vSphere 6.0 Update 1 is the vsan.stretchedcluster.* commands and the one we are specifically interested in is the vsan.stretchedcluster.config_witness command.

There are a couple of things the script expects from an environment setup, so I will just spend a few minutes covering the pre-reqs and the assumptions before diving into the script. I will assume you already have a vCenter Server deployed and configured with an empty inventory. I also assume you have already deployed at least two ESXi hosts and a VSAN Witness VM that meets all the VSAN pre-reqs like at least one VSAN enabled VMkernel interface and associated disk requirements. Below is a screenshot of the vSphere Web Client of the initial environment.

Next, we will need to download the RVC script deploy_stretch_cluster.rb and upload that to your vCenter Server. Before you can execute the script, you will need to edit the script and adjust the variable names based on your environment. Once you have saved the changes, you can then run the RVC script by running the following command:

rvc -s deploy_stretch_cluster.rb [VC-USERNAME]@localhost

Here is a screenshot of running the script on the VCSA using Nested ESXi VMs + VSAN Witness VM for the Stretched Clustering configuration:

If everything executed successfully, you should see a "Task result: success" which signifies that the VSAN Witness VM was successfully added to the VSAN Stretched Cluster. If we now refresh the vSphere Web Client and under the Fault Domains configurations in the VSAN Cluster, we now see both our 2-Node VSAN Cluster and the VSAN Witness VM.

Hopefully this script can also benefit others who are interested in quickly standing up a VSAN Stretched Cluster, especially for evaluation or testing purposes. Enjoy getting your VSAN on!

Heads Up - Workaround for changing Mac OS X VM display resolution in vSphere & Fusion

10.22.2015 by William Lam // 51 Comments

For customers who are running Mac OS X 10.9 (Mavericks) or newer in a Virtual Machine, you may have noticed that you can no longer set a custom display resolution beyond the default 1024x768 in either VMware Fusion and vSphere, regardless of the amount of video memory that has been allocated. The reason for this behavior is that Apple has changed the way in which it remembers previously used modes and would automatically fall back to this versus retaining the custom mode using the Display Preferences. Given this is a non-trivial fix, VMware Engineering has been working hard on a providing a workaround which would still allow users to set a custom resolution from within the GuestOS.

The workaround that has been developed is a tiny standalone command-line utility called vmware-resolutionSet which runs within the Mac OS X Guest and allows you to configure a custom display resolution. You will need to ensure you have VMware Tools installed and running before you can use this utility. As of right now, customers can get a hold of this utility by filing an SR with VMware Support and referencing PR 1385761. Although this tool has not been officially released and must go through the standard release process, the plan is to include it in a future update of VMware Tools and will available for use with both VMware Fusion and vSphere.

UPDATE (12/11/15) - Thanks to reader @elvisizer, it looks like the latest VMware Fusion 8.1 release now includes an updated version of VMware Tools (10.0.5) which includes the vmware-resolutionSet utility. You can find it under '/Library/Application Support/VMware Tools'. One thing to note is that there is a known issue right now for VMware Fusion 8.1 related to NAT and port forwarding, you may want to hold off on upgrading if you rely on this feature.

The syntax for the vmware-resolutionSet utility is pretty straight forward, it accepts a width and height argument. Make sure to use "sudo" if you want the display resolution to persist through a system reboot. For example, to set a 1920x1080 resolution, you would run the following command:

./vmware-resolutionSet 1920 1080

Note: Ensure you have sufficient video memory configured for your VM for larger display resolutions. In the example above, I have 16MB configured for my Mac OS X VM which would give you a max resolution of 2560x1600.

If everything was successful, you should see that both the "Requested resolution" and the "Effective resolution" match in the output. If output does not match, it most likely means you need to increase the video memory and you can refer to this VMware KB 1003 for more details. If we take a look at our Mac OS X VM, we should now see that our new custom display has taken effect. Below is a screenshot of a Mac OS X 10.11 (El Capitan) running on vSphere 6.0 Update 1 configured with a 1920x1080 resolution.

One other thing to note is if you plan on using higher display resolution than 2560x1600, you may need to configure some additional VM Advanced Settings due to use of framebuffers that are larger than 16MB. In this case, you would need to also add the following two advanced settings to the VM which can be done using the vSphere Web/C# Client or the vSphere API. For example, if I want a 2880x1800 display resolution, I would add the following:

svga.maxWidth = "2880"
svga.maxHeight = "1800"

Lastly, I would like to give a big thanks to Michael Udaltsov, the Engineer who is responsible for creating the workaround and providing me with some additional context to this change in behavior. I know our customers will greatly appreciate this workaround!