vcsa

Is a DNS server still required when using a Static IP for VCSA?

12/20/2018 by William Lam 2 Comments

When deploying a vCenter Server Appliance (VCSA), customers have two options for setting up a static network address: using either a hostname (Fully Qualified Domain Name) or just a static IP Address (e.g. no DNS). In the first option when using an FQDN, it should be no surprise that you need to also specify a valid DNS Server which the VCSA UI/CLI Installer will automatically validate both the forward and reverse address. This is the most common deployment model for customers in both production as well as for development environments such as a vSphere home lab.

In the second scenario, where a static IP Address is used, a DNS server is not required because we are NOT using an FQDN for the hostname but rather an IP Address. Having said that, if you have ever used the VCSA UI or CLI, you will find that the DNS Server entry is actually a required field and you can not proceed without providing an address.

VCSA UI Installer:

VCSA CLI Installer:

"network": {
    "ip_family": "ipv4",
    "mode": "static",
    "ip": "192.168.30.151",
    <strong>"dns_servers": [
        "192.168.30.1"
    ],</strong>
    "prefix": "24",
    "gateway": "192.168.30.1",
    "system_name": "192.168.30.151"
}

"network": {

"ip_family": "ipv4",

"mode": "static",

"ip": "192.168.30.151",

<strong>"dns_servers": [

"192.168.30.1"

],</strong>

"prefix": "24",

"gateway": "192.168.30.1",

"system_name": "192.168.30.151"

}

As mentioned earlier, we know that it should not be required but currently the VCSA Installer is a bit overly cautious in its pre-checks and does require a value today. This is something that has already been shared internally and the team will be relaxing this requirement in the future.

With that said, this leads us back to the original question posed in the blog title, do we need a valid DNS server when using a static IP for the VCSA?

Enabling shell access for Active Directory users via SSH to vCenter Server Appliance (VCSA)

10/09/2017 by William Lam 4 Comments

I had a question the other day on whether it was possible to enable shell access for Active Directory users when logging into the vCenter Server Appliance (VCSA) via SSH? The answer is yes and though this is documented here, it is not very clear whether this is only applicable to SSO-based users only. In any case, the process to enable this is pretty straight forward and simply requires two steps which I have outlined below.

Step 0 - Ensure that your VCSA and/or PSC is joined to Active Directory before proceeding to the next step. If not, take a look at the documentation here for more details.

Step 1 - Login to vSphere Web Client and under Administration->System Configuration->Nodes->Manage->Settings->Access, go ahead and enable boh SSH and bash shell options. The first setting turns on SSH to the VCSA and the second setting allows users (local, SSO and AD) to access the shell on the VCSA.

Step 2 - In the vSphere Web Client and under Administration->Single Sign-On->Users and Groups->Groups, select the SystemConfiguration.BaseShellAdministrators group and add either an AD User and/or Group that you wish to allow to access the shell.

Once you have completed the steps above, you can now SSH to your VCSA/PSC using the AD user (UPN format) that you had authorized earlier. In the example below, I am logging into one of my VCSA using user primp@primp-industries.com and as you can see, I am placed into the appliance shell by default.

At this point I can access all the appliancesh commands just like I normally would if I had logged as a root or administrator@vsphere.local.

If we wish to change to bash shell, we simply just type "shell" which will enable shell access, assuming you had performed Step 2.

One thing that I noticed is that the default home directory for the AD user is /var/lib/nobody and apparently that does not exists by default, so users end up in / directory by default after enabling shell access. I am not sure if this is also related, but the username shows up as nobody as you can see from the prompt. This is something I will share with Engineering to see if we can improve upon as I am sure most of you would rather see the user that is actually logged in.

The good news from an auditing and logging standpoint is that for operations that are logged, it does properly show the username even though the prompt is showing up as nobody.

Quick Tip – List all open ports on the VCSA / PSC

07/20/2017 by William Lam Leave a Comment

The list of required ports for both a vCenter Server Appliance (VCSA) and Platform Services Controller (PSC) are pretty well documented here (6.5), here (6.0) and here (5.5) for customers who require this information to setup external connectivity within their networking infrastructure. Having said that, it is may not always be clear on what ports are actually opened as they will usually depend on the type of deployment and the services that are running. Instead, some customers have inquired about getting a list of all open ports directly from the VCSA/PSC to ensure they have the actual configuration which can be used to build firewall rules and/or for auditing purposes.

Today, the only method is to login directly into the VCSA/PSC via SSH (you could also use GuestOps API, so that SSH is NOT required) and fetching this information using iptables. Hopefully, in the future, this can be made available as part of the VAMI API since it already covers some basic inbound firewall rule capabilities. In the mean time, below are examples of how to get all the open ports for both VCSA/PSC

Run the following command to view all open ports on VCSA/PSC:

iptables -L port_filter -n --line-numbers

You will notice in the output above, there is also a chain number on the far left side which is associated with each rule. This chain number can be used to inspect the rule further and some rules include a nice alias to help you identify what the port might be used for.

For example, we can run the following to inspect chain rule #30 and find out this port is being used for syslog. If we want the port number, we simply add the -n option.

iptables -L port_filter 30
iptables -L port_filter 30 -n

Not all of the firewall rules have an alias name and even if they do, it still may not be apparent on what service is opening that particular port. We can actually look at the firewall rule definitions which are located under /etc/vmware/appliance/firewall and you will see a JSON file for each of the VCSA/PSC services that require firewall rules to be opened up. For a given port, you can just grep in this directory to identify the service that is requiring the port.

For example, if we take a look at the vmware-syslog, we see that it requires tcp/udp 514 and tcp 1514 under the "rules" array which defines the list of external ports open. You can ignore the internal ports as those are not exposed to the outside world but used by internal services. In case the services are still not clear, you can always reference the port number back to the documentation which I had linked above to get more details about the particular port.

Native OVF support for Fusion/Workstation 2017 Tech Preview

07/18/2017 by William Lam 1 Comment

The VMware Fusion and Workstation team just released their 2017 Tech Preview releases and there is a ton of new and awesome capabilities which you can read more about here and here. One of the exciting new features, which I was very fortunate to have been involved with is finally here, native OVF property support! Although customers have had the ability to import OVF/OVAs for some time now, if they included OVF properties, they would be ignored and often times this would result in a failed deployment as those properties are required for the initial setup.

A great example of this is trying to run the vCenter Server Appliance (VCSA) on either Fusion or Workstation. Today, the only workaround is to manually edit the VMX file and supplying the correct OVF properties which I have blogged about here. With the latest TP release of Fusion/Workstation, when you import an OVF/OVA that contains OVF properties, the UI will automatically render the required information directly into the UI without needing users to manually touch the VMX files.

Here is a screenshot of deploying the latest VCSA 6.5d OVA (jump to bottom for some additional VCSA tidbits when deploying to Fusion/Workstation):

Visualizing live network traffic on the vCenter Server Appliance using net-glimpse

07/17/2017 by William Lam Leave a Comment

Last week I came across a really interesting OSS project called net-glimpse which allows you to easily visualize your network traffic in real-time and making that available using any standard web browser. I thought it would be neat to see what this might look like running on the vCenter Server Appliance (VCSA). I got it up in running in just a couple of minutes and even shared the results on Twitter as you can see from the tweet below:

Thought it be interesting to see the network traffic visualization on VCSA by running net-glimpse https://t.co/xyznnHnmkx #NotSupported pic.twitter.com/IjeoCV2QTx

— William Lam (@lamw) July 14, 2017

I had couple of folks ask about the setup and I figure I would post a quick write up. While looking at the project, I found that net-glimpse includes quite a bit of customizations in the colors, data collection and how data is displayed. Specifically, rather than relying on the well-known ports that have already been pre-defined, you can also add additional custom ports and specify the label that it should automatically used. This gave me an idea, instead of a generic visualization of the VCSA, we could get specific service information and have those label automatically get displayed.

How to automate the deployment of an un-configured VCSA 6.5 (Stage 1 only)?

12/19/2016 by William Lam 2 Comments

In vSphere 6.5, the VCSA deployment has changed from a "Single" monolithic stage where a user inputs all of the required parameters up front and then the installer goes and deploys/configures the VCSA. In the new VCSA UI Installer, we still continue to provide a "Single" monolithic user experience but behind the scenes, the deployment is now actually composed of two distinct stages, creatively called Stage 1 and Stage 2.

Stage 1 - Initial OVA deployment which includes basic networking + OS password
Stage 2 - Applying the VCSA specific configurations (e.g. External Platform Services or Embedded VCSA)

One reason why this is so useful is that in previous releases of the VCSA, if you had fat fingered say the DNS entry or wanted to change the IP Address/Hostname before applying the actual application configurations, your only option was to re-deploy the VCSA, not a very good user experience. With this new deployment model, customers now have the ability to either go through both Stage 1 and Stage2 or they can stop just after Stage 1 which would allow them to make necessary edits before continuing to Stage 2. If you decide to stop after Stage 1, then to complete the deployment, you will need to open a browser and finish the configuration using the VCSA's Virtual Appliance Management Interface (VAMI) at https://[VCSA-HOSTNAME-OR-IP]:5480

Once on the VAMI UI, you will want to select the "Set up vCenter Server Appliance" which will then launch the configuration wizard. From here, you will have the option of changing some of the settings that you had provided in Stage 1 such as the IP Address or things like NTP or enabling SSH access as shown in the screenshot below. Once you have confirmed these settings, it will be saved and then you will move onto Stage 2 to complete the configuration of your VCSA deployment.