WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

How to change the default ports on the vCenter Server Appliance in vSphere 6.0?

01.20.2016 by William Lam // 13 Comments

When deploying the vCenter Server Appliance (VCSA), there are a set default network ports that are already pre-defined by VMware. It is generally recommended to stick with these defaults unless you have a really good reason to modify them. I am a big fan of strong defaults which can help reduce the number of steps it takes to deploy the VCSA, however I do understand that there are some organizations who may have specific security requirements which requires them to change some of the default ports. It is also important to note that changing the default network ports post-installation is not supported.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

If you deploy the VCSA using the new Guided UI installer, you will not be able to modify the default network ports. However, if you deploy using the new Scripted CLI installer, you do have the option of overriding some of the default ports. Below is a table of the ports that can be modified which includes the variable name, default port number and their port usage which is described in the vSphere 6.0 documentation here. The variable port names are required in the JSON configuration file if you decide to modify from the default.

Variable Name Port Port Usage
rhttpproxy.ext.port1 80 HTTP Reverse Proxy Port
rhttpproxy.ext.port2 443 HTTPs Reverse Proxy Port
syslog.ext.port 514 Syslog Service Port
vpxd.ext.port1 902 ESXi Heartbeat port
syslog.ext.tls.port 1514 Syslog Service TLS port
netdumper.ext.serviceport 6500 ESXi Dump Collector port
autodeploy.ext.serviceport 6501 Auto Deploy Service port
autodeploy.ext.managementport 6502 Auto Deploy Management port
sts.ext.port1 7444 Secure Token Service port
vsphere-client.ext.port1 9443  vSphere Web Client port

Under the "Networking" section of the JSON configuration file, there is a "Ports" field which accepts a JSON encoded string of the ports you wish to modify. It actually took me a bit of time to figure out the exact syntax as this was not clearly documented anywhere. Lets say we wish to change the default HTTPS Reverse Proxy from 443 to 13443 and PSC's STS port from 7444 to 7441, you will need to specify it as shown in the example below. The key is properly escape the inner-double quotations since ports accepts a single string input.

"network": {
    "hostname": "192.168.1.140",
    "dns.servers": [
        "192.168.1.1"
    ],
    "gateway": "192.168.1.1",
    "ip": "192.168.1.140",
    "ip.family": "ipv4",
    "mode": "static",
    "prefix": "24",
    "ports": "{\"rhttpproxy.ext.port2\":\"13443\",\"sts.ext.port1\":\"7441\"}"
},

If everything was successful, when you connect to the VCSA, you should see that we no longer use the default port of 443 to connect to the vCenter Server as you can see from the screenshot below.

changing-default-vcenter-server-appliance-ports
If you ever wonder what ports were selected for either a vCenter Server or Platform Services Controller, you can easily find that by following the instructions in this article.

For customers using the Windows version of vCenter Server, you do have the option of modifying the default ports using the Guided UI since there is no guarantee these ports are not in use as VMware does not control the underlying OS. You can also use the Windows Scripted CLI to modify the default ports which you can find more information here.

vcenter-server-appliance-default-ports-1

Categories // Automation, VCSA, vSphere 6.0 Tags // platform service controller, psc, rhttpproxy, vcenter server appliance, VCSA, vcva, vSphere 6.0

Quick Tip - How to mount CIFS & NFS volumes on Photon OS?

01.13.2016 by William Lam // 9 Comments

I caught the following tweet from Christian this morning and thought I do a quick blog post on how to mount an external volume like a CIFS or NFS share on VMware's Photon OS.

Hm, anyone tried to get CIFS mount-points
in Photon?

— Christian Mohn™ (@h0bbel) January 12, 2016

For mounting an NFS volume, an NFS client is required and this is provided through the nfs-utils package which is not installed by default on Photon OS. To install the package, you just simply need to run the following command:

tdnf -y install nfs-utils cifs-utils

Screen Shot 2016-01-13 at 8.47.11 AM
Once the nfs-utils is installed, you can mount your NFS volume by using the mount command like the following:

mount -t nfs [NFS-SERVER]:/path/to/share /mountpoint

If you want to ensure the volume is automatically mounted, you will need to add an entry to /etc/fstab. If you want more details, you can perform a quick Google search for further instructions

For mounting a CIFS or SMB volume, you need to install cifs-utils package and then specify the "cifs" mount type like the following:

mount -t cifs //[CIFS-SERVER]//path/to/share /mountpoint

If you require authentication to your CIFS or SMB volume, you just need to specify -o username=[USERNAME],password=[PASSWORD]

Lastly, I also want to mention that the instructions above is not specific to Photon OS but applies to any other *Nix platform.

Categories // Cloud Native Tags // cifs, mount, nfs, nfs-utils, Photon, tdnf

Hidden OVF 2.0 capablity found in the vSphere Content Library

01.12.2016 by William Lam // 5 Comments

There are a number of new and useful capabilities that have been introduced in the OVF 2.0 specification. One such capability which I thought was really interesting and that could easily benefit VMware-based solutions is the ScaleOutSection feature. This feature allows you specify the number of instances of a given Virtual Appliance to instantiate at deployment time by making use of pre-defined OVF Deployment Options which can also be overriden by a user.

Lets use an example to see how this actually works. Say you have a single Virtual Appliance (VA) and the application within the appliance can scale to N, where N is any number greater or equal to 1. If you wanted to deploy 3 instances of this VA, you would have to deploy it 3 separate times by either by running through an OVF upload or deploying it from a template. In either case, you are performing N-instantiations. Would it not be cool if you could still start with a single VA image and specify at deployment time the number of instances you want to deploy and only need to upload the VA just once? Well, that is exactly what the OVF ScaleOutSection feature provides.

Below is a diagram to help illustrate this feature further. We start out with our single VA, which contains several pre-defined Deployment Options which can contain any text you wish for the logical grouping. In this example, I am using the terms "Single", "Minimal" and "Typical" to map to number of VA's to deploy which are 1, 3, and 4 respectively. If we choose the "Minimal" Deployment option, we would then get 3 instantiated VA's. If we decide that the defaults are not sufficient, we could also override the default by specifying a different number which the VA supports.

OVF20_ScaleOut
A really cool use case that I had thought about when I first came across the ScaleOutSection feature was to make use of it with my Nested ESXi Virtual Appliance. This capability would make it even easier to standup a vSphere or VSAN Cluster of any size for development or testing purposes. Today, vSphere and many of the other VMware products only support OVF 1.x specification and as far as I know, OVF 2.0 was not something that was being looked at.

Right before holiday break, I was chatting with one of the Engineers in the Content Library team and one of the topics that I had discussed in passing was OVF 2.0 support. It turns out that, although vSphere itself does not support OVF 2.0, the vSphere Content Library feature actually contains a very basic implementation of OVF 2.0 and though not complete, it does have some support for the ScaleOutSection feature.

This of course got me thinking and with the help of the Engineer, I was able to build a prototype version of my Nested ESXi Virtual Appliance supporting the ScaleOutSection feature. Below is a quick video that demonstrates how this feature would work using a current release of vSphere 6.0. Pretty cool if you ask me!? 🙂

Demo of Prototype Nested ESXi Virtual Appliance using OVF 2.0 ScaleOut from lamw on Vimeo.

Now, before you get too excited. There were a couple of caveats that I found while going through the deployment workflow. During the deployment, the VMDKs were not properly being processed and when you power on the VMs, it was as if they were empty disks. This was a known issue and I have been told this has already been resolved in a future update. The other bigger issue is how OVF properties are handled with multiple instances of the VA. Since this is not a supported workflow, the OVF wizard is only brought up once regardless of the number of instances being deployed. This means that all VAs will inherit the same OVF values since are you are only prompted once. The workaround was to deploy the VAs, then go into each individual VA and update their OVF properties before powering on the VMs. Since OVF 2.0 and the ScaleOutSection feature is not an officially supported feature, the user experience is not as ideal as one would expect.

I personally think there are some pretty interesting use cases that could be enabled by OVF 2.0 and ScaleOutSection feature. A few VMware specific solutions that I can think of off the top of my head that could potentially leverage this capability are vRealize Log Insight, vRealize Operations Manager and vRealize Automation Center to just name a few. I am sure there are others including 3rd party and custom Virtual Appliances that have been developed and I am curious to hear if this is something that might be of interest to you? If you have any feedback, feel free to leave a comment and I can share this with the Content Library PM.

Categories // ESXi, Nested Virtualization, OVFTool, vSphere Tags // content library, ova, ovf, ovf 2.0, ScaleOutSection, virtual appliance

  • « Previous Page
  • 1
  • …
  • 333
  • 334
  • 335
  • 336
  • 337
  • …
  • 567
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...