WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • 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 // vSphere Web Client Tags // inventory service, sso, VCSA, vcva, vsphere web client

VCSA (vCenter Server Appliance) 5.1 VCDB & SSODB Password

11.19.2012 by William Lam // 2 Comments

I recently helped answer a question internally about the default credentials to the VCSA 5.1 (vCenter Server Appliance) vCenter Server and SSO (Single-Sign On) Database for troubleshooting purposes. I thought I share the details in case this might help others.

With the release of the vSphere 5.1, the VCSA now runs VMware's vPostgres database for both the VCDB and SSODB. You should also know there is no default credentials for the database as the passwords are automatically generated during the initial application install and the database password will be unique on every VCSA.

However, you can still retrieve the password for both the VCDB as well as SSODB (this took a bit of digging in the appliance).

Disclaimer: You should not have any reason to go into the actual DB of either vCenter Server or SSO other than potential troubleshooting with VMware Support. Please use caution if you do choose to connect to the DB, as you can potentially impact your system.

VCDB Credentials:
You can view the credentials for the VCDB in the following file: /etc/vmware-vpx/vcdb.properties

Here is a screenshot of the file content as well as using psql client located on the VCSA (/opt/vmware/vpostgres/1.0/bin/psql) to connect to the VCDB:

SSODB Credentials:
You can view the credentials for the SSODB in the following file: /usr/lib/vmware-sso/webapps/lookupservice/WEB-INF/classes/config.properties

Here is a screenshot of the file content as well as using psql client located on the VCSA to connect to the SSODB:

Categories // Uncategorized Tags // postgres, psql, sso, ssodb, vcdb, VCSA, vcva, vpostgres, vSphere 5.1

vGhetto Lab #NotSupported Slides Posted

10.17.2012 by William Lam // Leave a Comment

As promised, here are slides to my #NotSupported session at VMworld Europe which I continued the theme of home labs with my vGhetto Lab #NotSupported presentation.

The idea behind the vGhetto Lab is to easily setup a vSphere home lab without too much effort and most importantly, leveraging as little resources as possible. This is all accomplished with the following:

  • Physical host running ESXi 5.x
  • ESXi 5.x offline depot image
  • VCSA 5.x (vCenter Server Appliance)

In addition to the above, you will also need to download the vGhetto Lab scripts which are shown in the video.
Here are some additional details on how to quickly get setup with your own vGhetto Lab.

Step 1 - After installing ESXi 5.x on your physical host, you will need to deploy the VCSA. Make sure you add a second network interface to VCSA as shown in the presentation. In my example, I created another vSwitch with no uplinks and portgroup for Auto Deploy network

Step 2 - Once the VCSA is powered on, go ahead and SCP the scripts to virtual machine. The first script that we will need to execute is the setupNetwork.sh and you will need to edit the following variables:

VCENTER_IP_ADDRESS_1=192.168.1.150
VCENTER_NETMASK_1=255.255.255.0
VCENTER_GATEWAY=192.168.1.1
VCENTER_IP_ADDRESS_2=172.30.0.1
VCENTER_NETMASK_2=255.255.255.0
VCENTER_HOSTNAME=vcenter.primp-industries.com
DOMAIN_LIST=primp-industries.com
DNS_LIST=192.168.1.1

Note: To ensure that you do not accidentally run the script without changing out the variables, there is another variable called ACTUALLY_READ_SCRIPT that needs to be changed from "no" to "yes" else the script will not execute.

Step 3 - Next we need to configure the vCenter Server, we will need to execute the configureVCSA51.sh which will configure the embedded SSO Database as well as the database of the vCenter Server. You do not need to edit any variables in this script

Step 4 - Finally, we need to configure our DHCP, TFTP, Auto Deploy services as well extracting the ESXi offline depot image and preparing it for use with Auto Deploy. You will need to edit the following variables before running the setupvGhettoLab.sh script.

DHCP_SUBNET=172.30.0.0
DHCP_NETMASK=255.255.255.0
DHCP_START_RANGE=172.30.0.100
DHCP_END_RANGE=172.30.0.200
DHCP_INTEFACE=eth1
TFTP_SERVER=172.30.0.1
VCSA_SERVER=192.168.1.150
ESXI_OFFLINE_DEPOT=/root/VMware-ESXi-5.1.0-799733-depot.zip
ESXI_REPO_PATH=/etc/vmware-vpx/docRoot
ESXI_REPO_DIR=ESXi-5.1.0

Note: For the Image Profile and Auto Deploy rule creation, if you wish for the script to execute them automatically versus echoing to the screen, remove the "echo" statement as well as the double quotes from the following so the last three lines look like this:

pxe-profile-cmd create $(cat /tmp/VIBS) ${ESXI_REPO_DIR}
rule-cmd create -i pxe:${ESXI_REPO_DIR} ${AUTO_DEPLOY_RULE} vendor=='VMware, Inc.'
rule-set-cmd set ${AUTO_DEPLOY_RULE}

Step 5 - You are now ready to create your nested ESXi virtual machines. You can use RVC as shown in the presentation (there is a slide at the very end which lists the commands) or you can connect to vSphere Web Client and create the ESXi virtual machines the traditional way via the GUI.

After updating the DHCP configurations with the new MAC Addresses from your nested ESXi virtual machines, you should then see Auto Deploy automatically provision your ESXi hosts and join them to the VCSA you deployed earlier.

Additional Links:

  • vInception #NotSupported Slides Posted

 

Categories // Uncategorized Tags // appliance, auto deploy, dhcp, ESXi, ESXi 5.1, notsupported, ruby vsphere console, rvc, tftp, VCSA, vcva, vmworld, vSphere, vSphere 5.1

  • « Previous Page
  • 1
  • …
  • 38
  • 39
  • 40
  • 41
  • 42
  • …
  • 44
  • 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

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/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