vcva – Page 5

How to remotely run appliancesh & other shell commands on VCSA w/o requiring SSH?

02.25.2016 by William Lam // 13 Comments

In vSphere 6.0 Update 1, the vCenter Server Appliance (VCSA) has received a significant enhancement to its Virtual Machine Management Interface also known as VAMI for short. As the name suggests, this interface provides basic configuration, monitoring and management capabilities for the Virtual Appliance which can be consumed through either a UI using a web browser or from the appliancesh CLI running within the VCSA Shell.

When talking to customers, they love the fact that the VCSA is harden out of the box and things like SSH are disabled by default. However, one challenge today is that if you need to access the appliancesh interface, SSH still must be enabled or direct console access would be required which is not ideal from an automation as well as from a security standpoint. Although things like SNMP can be configured on the VCSA to help alleviate some of these challenges, it does not solve the problem of having programmatic and remote management access.

VMware Engineering is aware of this request and is working on exposing the VAMI capabilities as an API in a future release of vSphere. In the mean time, not all hope is lost and there is still a solution which does not require you to give up security to be able to operate and manage your VCSA. We can do so by leveraging one of my all time favorite features of the vSphere Platform which is the Guest Operations API which allows you perform guest operations (running commands, transferring files, etc) directly within the guestOS as if you were logged in. Valid guest credentials are still required and once authenticated, the operations are then proxied through VMware Tools. Networking is not even required which makes this a really handy feature for troubleshooting and can even extend into application level provisioning using a single API. I can not stress enough on how cool and underutilized this feature is and it still comes as a surprise when I tell customers that this is actually possible.

Customers can consume the Guest Operations API by consuming it through one of our many supported vSphere SDKs as I have shown here or you can also consume it through PowerCLI using the Invoke-VMSCript cmdlet. To demonstrate the power of the Guest Operations API with the VCSA, I will completely disable all remote access to the VCSA which includes Local Login, Bash Shell and SSH as shown in the screenshot below.

Here is an example of running a simple "echo" command using the vSphere SDK for Perl:

Note: You will notice that there is no output and that is because the standard output must be re-directed to a file and then downloaded back to your client. The PowerCLI's Invoke-VMScript does handle this for you and will return any standand output to the console. For more complex commands, I would recommend creating a script that contains the command and just running the script itself which you can then log locally or into a file.

Here is an example of running the "appliancesh" command using the Invoke-VMScript cmdlet:

Invoke-VMScript -ScriptText "echo 'VMware1!' | appliancesh help pi list
" -vm VCSA-No-SSH -GuestUser root -GuestPassword VMware1!

Here is an example of running the "cmsso-util" command using the Invoke-VMScript cmdlet:

Invoke-VMScript -ScriptText "export VMWARE_VAPI_HOME=/usr/lib/vmware-vapi
export VMWARE_RUN_FIRSTBOOTS=/bin/run-firstboot-scripts
export VMWARE_DATA_DIR=/storage
export VMWARE_INSTALL_PARAMETER=/bin/install-parameter
export VMWARE_LOG_DIR=/var/log
export VMWARE_OPENSSL_BIN=/usr/bin/openssl
export VMWARE_TOMCAT=/opt/vmware/vfabric-tc-server-standard/tomcat-7.0.55.A.RELEASE
export VMWARE_RUNTIME_DATA_DIR=/var
export VMWARE_PYTHON_PATH=/usr/lib/vmware/site-packages
export VMWARE_TMP_DIR=/var/tmp/vmware
export VMWARE_PERFCHARTS_COMPONENT=perfcharts
export VMWARE_PYTHON_MODULES_HOME=/usr/lib/vmware/site-packages/cis
export VMWARE_JAVA_WRAPPER=/bin/heapsize_wrapper.sh
export VMWARE_COMMON_JARS=/usr/lib/vmware/common-jars
export VMWARE_TCROOT=/opt/vmware/vfabric-tc-server-standard
export VMWARE_PYTHON_BIN=/opt/vmware/bin/python
export VMWARE_CLOUDVM_RAM_SIZE=/usr/sbin/cloudvm-ram-size
export VMWARE_VAPI_CFG_DIR=/etc/vmware/vmware-vapi
export VMWARE_CFG_DIR=/etc/vmware
cmsso-util --help
" -vm VCSA-No-SSH -GuestUser root -GuestPassword VMware1!

Note: The reason the additional "export" commands are required is that certain commands may rely on certain environmental variables to be setup. In the case of the cmsso-util command, there are several VMware environmental variables it uses. I decided to just export them all but you can selectively figure out which ones are truly needed.

As you can see from the examples above, I was able to successfully run both shell commands as well as the appliancesh without requiring SSH and even local login! This methods works whether you are connected to vCenter Server or ESXi host from vSphere API perspective.

UPDATE (06/06/19) - Example joining the VCSA to Active Directory using domainjoin-cli

Invoke-VMScript -ScriptText "echo 'VMware1!' | /opt/likewise/bin/domainjoin-cli join vmware.corp administrator
" -vm VCSA -GuestUser root -GuestPassword VMware1!

Caveats when multi-homing the vCenter Server Appliance 6.x w/multiple vNICs

02.01.2016 by William Lam // 10 Comments

The topic of multi-homing the vCenter Server Appliance (VCSA) in which additional virtual network cards (vNICs) are added has been some what of an active topic of discussion lately, at least internally. By no means is this a new topic, in fact if you do a search online, you will find several articles on how to configure additional vNICs for older releases of the VCSA. Some of the common use cases for requiring this capability for the VCSA or any other infrastructure VM for that matter range from having a dedicated backup network, 3rd party monitoring and accessing the management stack through a bastion jump host which resides on the public side of a DMZ environment.

UPDATE (04/20/20) - In vSphere 7, multi-homing of the VCSA is now officially supported. You can have up to 7 additional network adapters attached to the VCSA which will be preserved upon upgrades and backup. The networks MUST be different from the default management network on the VCSA. Lastly, if you intend to use vCenter High Availability (VCHA), you should NOT use eth1 as that is the default interface that will be selected when you enable VCHA.

Disclaimer: Although it is possible to add additional vNICs to the VCSA, as far as I have been told, this is currently not officially supported by VMware. Please use at your own risk.

If you are considering multi-homing your VCSA 6.x (applies to vCenter Server 6.x for Windows), there are a few things to be aware of from earlier versions of vSphere. Before jumping into the details, lets take a look at an example deployment of the VCSA which has 2 vNICs and that is connected to two different networks. The first network is 192.168.1.0/24 which is connected to the first interface (eth0) of the VCSA. The VCSA's primary network identifier (PNID) is using the FQDN of the VCSA which is vcenter.primp-industries.net. We also have a DNS server and an internal Windows desktop client residing on this network which we will refer to as Network A. We then have a second network 172.30.0.0/24 which we will refer to as Network B which is connected to the second interface (eth1) of the VCSA. There is also a Windows desktop client residing on Network B.

Accessing the vSphere Web Client:

For the internal desktop client, I can point my browser to either the FQDN (vcenter.primp-industries.net) or the IP Address (192.168.1.200) and I can connect to the vSphere Web Client without any issues. The issue which some of you may have found in vSphere 6.x is that if you try to connect to the second IP Address (172.30.0.200) of the VCSA from the external desktop client, you will notice that a redirect occurs when the vSphere Web Client loads and you are taken to the SSO endpoint which fails to resolve as seen in the screenshot below.

In my example, I have an Embedded VCSA, but if you had an External Platform Services Controller (PSC), you would see that the SSO URL would be that of your PSC. This happens because the PSC binds to the PNID which can either be an FQDN or IP Address. To workaround this limitation, you will need to either manually add a hosts entry on the external desktop client mapping the second IP Address to the FQDN of the VCSA or configure your DNS server to also map the IP Address to the FQDN. In my lab, I decided to just update the hosts entry on my Windows client like the following:

172.30.0.200 vcenter.primp-industries.net

Once the change have been made, you simply just need to refresh the browser and as you can see from the screenshot below, I am now logged into the vSphere Web Client using the secondary IP Address of the VCSA. This is also another reason to always use an FQDN vs. IP Address which I discuss in more detail in the next section.

Note: If you just want to access the vCenter Server using API or vSphere C# Client, you will not have to perform the tweak as neither of those interfaces require going through SSO. If you plan to use the vCloud Suite SDKs which do require SSO, then the tweaks mentioned above will be required.

FQDN vs a IP Address for PNID:

As you can see from the previous issue, if we had selected an IP Address instead of using the FQDN for the PNID, we would not have been able to access the vSphere Web Client even with our tweaks. The reason for this is that the PNID is now tied to the IP Address and you would not be able to resolve that address from the external desktop client. In addition to this issue, if you chose IP Address instead of FQDN, you will run into another problem with the default self-signed SSL Certificates which are bounded by either the FQDN or IP Address. If you do not plan to use your own certificates which you could add additional entries, then make sure to always use an FQDN.

Same network for both vNICs:

Make sure that you are using two completely different networks (e.g. different VLANs & different gateways) else you will run into problems with Linux IP reverse path filtering. If you really need to use the same network on both vNICs, then you will need to disable ip reverse path filtering. This is not a new issue and applies to all modern OSes as you can only have a single default gateway. If you do need to specify a second gateway for the additional vNIC, you have the option of either using a static route or creating a secondary routing table.

Configuring vNIC using new HTML5 VAMI:

Starting with VCSA 6.0 Update 1, there is now a new HTML5 based VAMI interface for managing and configuring the VCSA appliance. You can add a new vNIC to the VCSA while it is running using either the vSphere Web/C# Client which manages the VCSA. Once that operation has completed, you can login to the VAMI UI by opening a browser to https://[VCSA-HOSTNAME]:5480 and select the "Networking" tab on the left hand corner. You should see both vNICs, with the newly added vNIC in an un-configured state as shown in the screenshot below.

To configure the new vNIC, just click on the "Edit" button and specify either an IPv4 or IPv6 address. Make sure you do not add a gateway UNLESS you plan on changing the system default gateway. You can potentially negatively impact the VCSA's networking if you did not mean to change the default gateway of the system.

In addition to the VAMI UI, you can also configure additional vNICs from the command-line using the default appliancesh interface by running the following command:

networking.ipv4.set --interface nic1 --mode static --address 172.30.0.200 --prefix 24

or if you have defaulted to the bash shell, then you can run the following VAMI command:

/opt/vmware/share/vami/vami_set_network STATICV4 172.30.0.200 255.255.255.0 default

For those interested, I had used VMware Photon and the following Docker Container to quickly stand up a DNS Server. This might come in handy for anyone looking to try this out in their lab or just for general testing.

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.

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.

« Previous Page
1
…
3
4
5
6
7
…
33
Next Page »