virtuallyGhetto

vcsa

vCenter Server Simulator

by 46 Comments

I recently spent some time experimenting with a really cool tool found only in the VCSA (vCenter Server Appliance) called vcsim, short for vCenter Simulator. I initially noticed vcsim during some of my early beta testing of vSphere 5.1 and during this period it is not uncommon to find various utilities and debugging tools used by developers and QE for testing. At the time, I was more focused on usability issues and reporting bugs with the product and I did not think much of this vcsim. It was only until recently, after talking to Mr. Not Supported aka Randy Keener, did I look into vcsim again as it appears to have been included in the GA (generally available) build of the VCSA 5.1 which I had not expected.

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

vCenter Simulator is an internal tool developed by two VMware engineers: Zhelong Pan and Kinshuk Govil which allows you to quickly simulate thousands of virtual machines all running in memory while requiring only a minimal amount resources within the VCSA (2vcpu & 8GB memory - default configuration). Building such a tool is definitely not a trivia task, but it is also not the first time we have seen something like this. Awhile back there was project called simDK created by Andrew Kutz that did something similar but only supported reading information from vCenter Server, it did not support any actual operations. vcsim is much more advanced and the really cool thing about vcsim is that even though the inventory is simulated, it actually supports some basic vSphere inventory operations such as create/destroy and power operations. It also supports a hybrid configuration where you can mix both simulated and actual ESXi hosts and virtual machines since it is an actual vCenter Server.

Before we dive into using vcsim, I wanted to go through a few use cases where a tool such as this would be useful:

  • Exploring and learning about the vSphere API and the basic inventory hierarchy of vSphere objects
  • Environment to develop and create various inventory reporting scripts (vCLI, PowerCLI, etc)
  • Developing performance metric gathering tools
  • Developing vSphere Web Client plugins and being able visualize large inventory of objects

As you can see, once you start to think about the potential of a such tool, the possibilities can be endless. Having said all of this, no amount of simulation can ever replace actual testing of a real system and any development made using vcsim should be validated against an actual vSphere environment.

To enable vcsim, you will need to add some configuration entries into the vpxd.cfg (vCenter Server configuration file) an example template of the configuration is provided in:

/etc/vmware-vpx/vcsim/model/vcsim.cfg.template

To setup a basic vCenter Simulator, you should deploy a brand new VCSA (you can use an existing VCSA, but the VCDB could potentially get wiped) and go through the basic setup as you would normally. Next, you need to add the following lines at the end of /etc/vmware-vpx/vpxd.cfg between </vpxd> and </config>

Note: Notice the cleardb parameter is false in my example where as the template is set to true. This is very important because if you use the default of "true", you will not be able to view your vSphere inventory using the vSphere Web Client but only the vSphere C# Client as the Inventory Service DB is wiped.

Once you have added the configurations and saved the vpxd.cfg, you will need to restart the vCenter service by running the following command:

service vmware-vpxd restart

Note: A restart of the vmware-vpxd service ONLY works the very FIRST time you add in the vcsim configurations. For any additional changes to the vcsim configuration files, a different method is required to reload the changes, else the vCenter service will fail to start. This is shown in detail further in the article.

Once the vCenter service has restarted, you should now be able to login using either the vSphere Web Client or the vSphere C# Client and you should see a default vSphere inventory that contains a Datacenter, Cluster, several ESXi hosts with Resource Pools along with some powered on and off virtual machines.

Here is a screenshot of logging into the vSphere Web Client:

Here is a screenshot logging into the vSphere C# Client:

You might notice that your inventory may not be as large as mines ... oh about 10,000 VM large 🙂 Another cool thing about vcsim is that it has a configurable inventory that you can customize to fit whatever design you wish to have and this can be modified in /etc/vmware-vpx/vcsim/model/initInventory.cfg file. You can tweak the following in the configuration files:

  • Datacenter
  • Hosts per Datacenter
  • VM per Host
  • Powered On VM per Host
  • Cluster per Datacenter
  • Host Per Cluster
  • Resource Pool per Cluster
  • VM per Resource Pool
  • Powered On VM
  • vCPU for a VM
  • vMEM for a VM

Once you have saved your changes, to reload the new configurations into vcsim, you will need stop the vCenter service and run vpxd -b command to recreate the database and then start the vCenter service. To do so, run the following 3 commands (this is required each time for any changes):

service vmware-vpxd stop
vpxd -b
service vmware-vpxd start

When you log back into your vCenter Server, you now should see the new inventory based on your configurations. In addition to inventory configuration, the vcsim template also points to three other configuration files which I encourage to explore further:

  • vcsim/model/metricMetadata.cfg (simulated Performance Metrics, none by default)
  • vcsim/model/vcModules.cfg (simulated VC modules such as DRS)
  • vcsim/model/OperationDelay.cfg (operations latencies)

Note: You should only be modifying the *.cfg files and not the XML configuration files else you could potentially run into issues.

At this point, you are probably ready to start playing with vcsim and even though this is an internal tool, if you think this is something that is useful to have or have other use cases for, please leave a comment. You never know, this could be a VMware Fling one day if there is enough interest from the community.

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

by 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[email protected]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

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.

VCSA (vCenter Server Appliance) 5.1 VCDB & SSODB Password

by 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:

vGhetto Lab #NotSupported Slides Posted

by 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:

 

VCSA (vCenter Server Appliance) Resources

by 2 Comments

Here is a consolidated page on all the articles I have written about the VCSA (vCenter Server Appliance). Hopefully this will be useful when looking for anything related to VCSA.

VCSA 5.5

VCSA 5.1

VCSA 5.0

Additional Tips/Tricks