WilliamLam.com

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

Seperating Out the vCenter SSO, vSphere Web Client and vCenter Server Services Using the VCSA

12.17.2012 by William Lam // 12 Comments

The VCSA 5.1 (vCenter Server Appliance) is provided as single virtual appliance that is pre-installed with all the components needed to run a vCenter Server. These components include vCenter SSO (Single Sign-on), Lookup Service, Inventory Service, vSphere Web Client and the vCenter Server itself. In the Windows installer for vCenter Server 5.1, there is an option to install each individual component on a separate machine. How would you go about doing that for the VCSA as all the components are installed on a single machine?

The answer is actually quite simple, you just need to deploy additional VCSA systems and enable the specific component service on each of the VCSA's. I have already written articles covering some of these use cases such as deploying additional vCenter Servers leveraging a common vCenter SSO Server as well as deploying additional vSphere Web Client Servers. The one particular use case that I have not covered is running just the vCenter SSO Server on the VCSA and with this configuration, there is a minor tweak that is required to get things working correctly.Disclaimer: This may not be officially supported by VMware, please use at your own risk.

If you have attempted to configure the VCSA to run just the vCenter SSO service, then you may have seen the following error message "Could not connect to one or more vCenter Server systems" when logging into the vSphere Web Client.

The reason you are seeing this error is due to an invalid configuration found in the vCenter SSO Server and specifically with something called the Lookup Service. The Lookup Service is installed with the vCenter SSO service which can be thought of as a DNS lookup for vSphere components so they can securely find and communicate with each other. Since each VCSA component is registered with the Lookup Service as part of their initial installation and when you only enable the vCenter SSO service, the remainder services will become invalid as they are not running on the same VCSA system.

Un-Registering Services from Lookup Service:

To fix this problem, we just need to identify the services that should not be registered to the Lookup Service in the vCenter SSO Server and unregister them. To view the list of registered services to a particular Lookup Service endpoint, you can use the /usr/lib/vmware-sso/bin/vi_regtool utility with the listServices option found on the VCSA.
To use the utility, you will need to specify either the IP Address and/or Hostname of the vCenter SSO Server which runs the Lookup Service. Here is an example:

/usr/lib/vmware-sso/bin/vi_regtool listServices https://172.30.0.186:7444/lookupservice/sdk

If the command is successful, you should see a list of service endpoints such as the following:

Service 1
-----------
serviceId=local:7
serviceName=vsphere-client-localhost.localdom-eed72307-2dd2-4069-9650-e78a60b549c7
type=urn:com.vmware.vsphere.client
endpoints={[url=https://172.30.0.185:9443/vsphere-client,protocol=vmomi]}
version=5.1
description=vSphere Web Client at 172.30.0.185
ownerId=vsphere-client-localhost.localdom-eed72307-2dd2-4069-9650-e78a60b549c7@System-Domain
productId=
viSite=local

A default VCSA installation contains the following 6 services:

  • vSphere Web Client
  • Security Token Service
  • VMware Log Browser
  • SSO Group Check Service
  • vpxd (vCenter Server)
  • SSO Administration Service

We will need to identify the serviceId which starts with local:# and unregister the vSphere Web Client, VMware Log Browser and the vpxd service which is not running locally on our vCenter SSO Server. To unregister a service, you will need to create a temporarily file which contains the serviceId and use the unregisterService option with the vi_regtool.

Note: Please make sure you identify the correct serviceId before unregistering, else you may potentially run into issues with your VCSA.

Let's say we want to unregister the service that we showed earlier local:7, we would need to run the following two commands:

echo "local:7" > /tmp/serviceid
/usr/lib/vmware-sso/bin/vi_regtool unregisterService -d https://172.30.0.185:7444/lookupservice/sdk -u root -p vmware -si /tmp/serviceid

The first command will "echo" the serviceId into a temporarily file called /tmp/serviceid and the second command will perform the actual un-registration and you will need to specify the root credentials. You will need to repeat this for the other two services and once you have finished un-registering the three services, you can now log back into the vSphere Web Client and the error message should go away (a service restart is not necessary).

Now that you have some background on how to run a standalone vCenter SSO on the VCSA and the minor tweak that is required, how do we go about automating all of this during deployment? For those of you who know me, know that I would not leave my readers hanging without some scripts to assist with this manual work.

Automating Deployment of vCenter SSO, vSphere Web Client & vCenter Server Component:

The following section will describe how to completely automate the deployment of 3 separate VCSA running vCenter SSO + Lookup Service, vSphere Web Client and vCenter Server + Inventory Service as seen in the diagram above.

Step 1 - Deploy 3 VCSA 5.1 and configure basic network connectivity. In my example, I have the following setup:

Component Hostname IP Address
vCenter SSO + LS sso.primp-industries.com 172.30.0.185
vSphere Web Client webclient.primp-industries.com 172.30.0.186
vCenter Server + IS vcenter.primp-industries.com 172.30.0.187

Step 2 - Configure the vCenter SSO by creating the following shell script called configureVCSASSOStandalone.sh

#!/bin/bash

# User configurations

SSO_IP_ADDRESS=172.30.0.186

## DO NOT EDIT BEYOND HERE ##

echo "Configuring SSO..."
/usr/sbin/vpxd_servicecfg sso write embedded

echo "Starting SSO ..."
/etc/init.d/vmware-sso start

echo "Retrieving services registered with Lookupservice and storing in /tmp/ls-services ..."
/usr/lib/vmware-sso/bin/vi_regtool listServices https://${SSO_IP_ADDRESS}:7444/lookupservice/sdk > /tmp/ls-services

VC_SERVICE_ID=$(cat /tmp/ls-services | grep -B3 "type=urn:vc" | awk -F 'serviceId=' '{print $2}' | sed '/^$/d')
WEBCLIENT_SERVICE_ID=$(cat /tmp/ls-services | grep -B3 "type=urn:logbrowser:logbrowser" | awk -F 'serviceId=' '{print $2}' | sed '/^$/d')
LOGBROWSER_SERVICE_ID=$(cat /tmp/ls-services | grep -B3 "type=urn:com.vmware.vsphere.client" | awk -F 'serviceId=' '{print $2}' | sed '/^$/d')

echo "Extracting vCenter Server serviceId: ${VC_SERVICE_ID} ..."
echo "Extracting vSphere Web Client seviceId: ${WEBCLIENT_SERVICE_ID} ..."
echo "Extracting vSphere Log Browser serviceId: ${LOGBROWSER_SERVICE_ID} ..."

echo "Unregistering the local \"vCenter Server\" service from the Lookupservice ..."
echo "${VC_SERVICE_ID}" > /tmp/serviceId
/usr/lib/vmware-sso/bin/vi_regtool unregisterService -d https://${SSO_IP_ADDRESS}:7444/lookupservice/sdk -u root -p vmware -si /tmp/serviceId

echo "Unregistering the local \"vSphere Web Client\" service from the Lookupservice ..."
echo "${WEBCLIENT_SERVICE_ID}" > /tmp/serviceId
/usr/lib/vmware-sso/bin/vi_regtool unregisterService -d https://${SSO_IP_ADDRESS}:7444/lookupservice/sdk -u root -p vmware -si /tmp/serviceId

echo "Unregistering the local \"vSphere Log Browser\" service from the Lookupservice ..."
echo "${LOGBROWSER_SERVICE_ID}" > /tmp/serviceId
/usr/lib/vmware-sso/bin/vi_regtool unregisterService -d https://${SSO_IP_ADDRESS}:7444/lookupservice/sdk -u root -p vmware -si /tmp/serviceId

The only user configuration that is required is to update the SSO_IP_ADDRESS variable in the script to the IP Address of the vCenter SSO Server. You can execute the script via SSH without having to copy the script to the VCSA system, here is an example execution:

We can see from the screenshot above, we automatically look for the 3 services mentioned earlier and unregister it from the vCenter SSO Server running the Lookup Service. You can easily confirm this by re-running the listServices operation with the vi_regtool.

Step 3 - Configure the vSphere Web Client Server and you can use the configureVCSAvSphereWebClientStandalone.sh script noted in this article. The only user configuration that is required is to update the VCENTER_SSO_IPADDRESS variable in the script to point to the IP Address of your vCenter SSO Server. Here is an example execution:

Step 4 - Finally, the last step is to configure the vCenter Server and you can use the configureVCSAExtra.sh script noted in this article. The only user configuration that is required is to update the PRIMARY_VC variable in the script to point to the IP Address of your vCenter SSO Server. Here is an example execution:

Once the vCenter Server has successfully started, then you are now done with seperating out the three components of the vCenter Server using the VCSA. You can confirm additionally by logging back into the vCenter SSO Server and run the listServices and you should now see the IP Address or Hostname of your vSphere Web Client Server and vCenter Server being registered to the Lookup Service from the separate VCSA's. You can now login to the vSphere Web Client server and make sure you specify the full URL which should be https://[hostname-or-ipaddress]:9443/vsphere-client and you should be able to see your vCenter Server.

Note: Steps 3 and 4 can be interchange as the order does not matter, as long as vCenter SSO system is setup first.

Categories // Uncategorized Tags // inventory service, sso, VCSA, vcva, vsphere web client

Getting Rid of the Inventory Tree in the New vSphere Web Client

11.26.2012 by William Lam // 2 Comments

I don't know about you, but I really like using the new inventory list compared to the old inventory tree when I need to find something in new vSphere Web Client. The inventory list does not rely on the static and limited hierarchical tree view to display your vSphere objects. Instead, it groups common vSphere objects together (works across multiple vCenter Servers) along with links to other related objects. This allows you to quickly navigate to a particular vSphere object and with just a click away to other related objects for further inspection. Finally, you will no longer have to worry about the "white screen of death" which was a common problem when trying to display huge inventories and sometimes even smaller ones while using the tree view.

To be honest, I was not a fan of the inventory list at first, but after spending some time with it, I quickly realized the benefits of moving away from the old hierarchical tree view. I actually like the new inventory list so much, that I personally wanted like to get rid of the inventory tree view as it is an extra mouse movement to get to the inventory list. I sometimes even accidentally click on the inventory tree when browsing too quickly through the vSphere Web Client.

I thought it might be a long shot to see if it was possible to remove the inventory tree since I assumed it might be part of the compiled code. Surprisingly, I found out from one of the developers, there was actually a pretty simple way (aka "hack") of removing the inventory tree.

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

In the example below, I am using the VCSA (vCenter Server Appliance) which has the vSphere Web Client installed by default but this should also work for a Windows vCenter Server that has the vSphere Web Client Server installed.

Step 1 - We need to make a backup of the following file /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war which contains the file that we need to edit. The command below will just make a backup copy called inventory-viewer-war-5.1.0.war.BAK

cp /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war.BAK

Step 2 - Next, we will go ahead and extract the contents of the WAR file which is basically a zip archive in our home directory so that we can edit a file. Run the following command which will extract the contents into a directory called TEMP under /root.

unzip /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war -d ~/TEMP

Step 3 - Change into the ~/TEMP directory and you should see a file called plugin.xml which we will be editing. Use an editor such as vi and locate the following section and comment it all out using the notation as shown below
Step 4 - Once you have finished editing the plugin.xml file, go ahead and save the file. Now we will need to re-create the inventory-viewer-war-5.1.0.war file and to do so, inside the TEMP directory, run the following command:

zip -r inventory-viewer-war-5.1.0.war *

Step 5 - We now need to copy the modified inventory-viewer-war-5.1.0.war back into the vSphere Client Plugins directory. Run the following command to copy the WAR file into plugins directory:

cp inventory-viewer-war-5.1.0.war /usr/lib/vmware-vsphere-client/plugin-packages/vsphere-client/plugins/inventory-viewer-war-5.1.0.war

Step 6- Finally, for the changes to go into effect, we just need to restart the vSphere Web Client service by running the following command:

/etc/init.d/vsphere-client restart

If everything was successful, then you should be able to login to the vSphere Web Client and when you click on the main vCenter home on the left, you should no longer see the inventory tree view, just the inventory lists.

Even though we removed the inventory tree from the object navigator, you can still access the four tree views using the shortcuts found on the home page:

If you really want to disable those as well, you can comment out the following four sections:
OR better yet, re-link them to the main vCenter home view by adjusting the targetViewUid to point to vsphere.core.viHome.domainView

Categories // Uncategorized Tags // inventory tree, plugin.xml, vSphere 5.1, vsphere web client, web client

Extracting Information from VIN (vSphere Infrastructure Navigator) Part 2

11.08.2012 by William Lam // 2 Comments

In my previous article Extracting Information from VIN (vSphere Infrastructure Navigator) Part 1, we took a look at the data VIN was collecting through an interface called Jolokia. Utilizing a tool called j4psh, we were able to easily view and explore the data in VIN remotely. In this article, we will take a look at how easily you can extract the data we explored in the previous article using a very simple script.

While going through the Jolokia website and walking through the tutorial, I found there were several programmatic clients that could be used to connect to the Jolokia service which includes Java, Javascript and Perl. Since I am most familiar with Perl, I wrote a very simple Perl script called getVINData.pl leveraging the information from my previous article.

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

Before using the script, you will need to run through the two per-requisites outlined in the previous blog article: VIN appliance setup and installation of Jmx4Perl. Once you have completed these two steps, you are now ready to execute the script (make sure the script has the executable permission set). The script is pretty straight forward it accepts two input parameter: VIN hostname/IP Address and the name of the virtual machine you wish to query.

In the example below, I am connecting to my VIN host which has an IP Address of 172.30.0.150 and I am querying a virtual machine with the name Analytics VM (one of the vC Ops VMs).

From the screenshot above we can see the following:

  • The vCenter Server that VIN is currently registered to
  • VM Summary information
  • Applications/Services currently running on the VM
  • VM Dependencies

If we take a look at the vSphere Web Client and the VIN data for this particular VM, we should see the same set information:

Though the script already contains quite a bit of information, it is just a sample of what can be done. With further exploration you can easily extend the script to extract other pieces of information and possibly even use other scripting/programming languages to connect to this interface. As I mentioned before, VIN is a very powerful tool for your vSphere infrastructure and now you can gain additional benefits by leveraging it's valuable data externally!

Categories // Uncategorized Tags // infrastructure navigator, jmx, jmx4perl, jolokia, notsupported, perl, vIN

  • « Previous Page
  • 1
  • …
  • 31
  • 32
  • 33
  • 34
  • 35
  • …
  • 74
  • 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

  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/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