WilliamLam.com

vCloud Director Simulator

by // 8 Comments

I have received several questions from folks asking if there are other VMware solutions that could work with the vCenter Server Simulator (vcsim) which I recently wrote an article about back in 2012. Well, the answer is I do not know, as other solutions have not really been tested out with vcsim. The goal of vcsim was primarily focused at the vSphere layer and I suspect that other VMware solutions can probably leverage what vcsim has done but probably will not work (today) as some solutions require a fair amount of communication between itself and the vCenter Server. Now having said all that, you might be wondering about the title of this article?

The one solution that I am aware of today that works with vcsim is vCloud Director and this is merely a proof of concept than anything else, so I would like to set the proper (low) expectations. The available functionality from vCloud Director is quite limited when using it with vcsim and I have also ran into several issues which I will go into more detail later. For vCloud Director to be able to consume the simulated inventory from vcsim, a few tweaks are required in both vcsim and the vCloud Director database.

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

Requirements:

  • VCSA 5.1 (vCenter Server Appliance)
  • VCNS 5.1 (vCloud Networking and Security)
  • VCD 5.1 Appliance
  • configureVCSimulator.sh script

I highly recommend you take a look at my vCenter Server Simulator article before getting started as it gives you some background that is required later on but you will not be required to configure the VCSA in advanced as there are some additional configurations that are needed. I will also be using the vCloud Director appliance which I recommend for quick ease of deployment and setup.

Configurations: 

Step 1 - Deploy VCSA and configure it as you would normally (do not touch the vcsim configurations, as that is handled in the next step using a script that is provided)

Step 2 - Download the configureVCSimulator.sh script and upload it to the VCSA. By default, vcsim's XML configuration files is set to ESXi 4.0 and we will need to adjust the version numbers to reflect either 5.0 or 5.1 as well as modify the hypervisor type from embeddedEsx to esx which is required by the simulator code. Go ahead and run the script on the VCSA which will setup the vcsim as well as modify the necessary files. Once the script has completed, if you wish to change the default inventory, go ahead and modify /etc/vmware-vpx/vcsim/model/initInventory.cfg and then restart the vCenter Server service by running service vmware-vpxd restart

Here is a screenshot of the script running:

Note: If you are interested in the files that are being modified, you can take a look at the shell script for more details. 

Step 3 - Deploy and configure VCNS appliance as you would normally. Make sure you also register the vCenter Server in the VCNS UI that you just deployed as this is needed before moving forward to the next step.

Step 4 - Deploy the VCD appliance using the embedded database and power on the system. Once the system is ready, go ahead and SSH to the host, we will need to execute a few SQL queries which will allow vCloud Director to support simulated hosts as well as the particular ESXi versions. First we need to switch over to the Oracle user, run the following command:

su - oracle

Next we will login to the VCD database using sqlplus and the default credentials which should be vcloud/VCloud, run the following command:

sqlplus vcloud/VCloud

The first SQL statement will allow VCD to support simulated ESXi hosts, type in the following SQL statement:

update config set value='1' where name='vzSim50Supported';

The next two SQL statements will define the version of ESXi that VCD will support, type in the following SQL statements that are applicable to you:

insert into os values (seq_config.NextVal, 'vmnix-x86', 'VMware ESX', '5.1.0', 0, 1);
insert into os values (seq_config.NextVal, 'vmnix-x86', 'VMware ESX', '5.0.0', 0, 1);

Finally, we just need to type "quit" to exit from sqplus and then type "exit" to logoff as the oracle user and this will bring us back to root context. The last thing we need to do is restart the vCloud Director service for the changes to go into effect by running the following command

service vmware-vcd restart

Here is a screenshot of running through the VCD database changes:

Step 5 - Once the vCloud Director service has been successfully restarted, we are now ready to setup our vCloud Director Simulator environment. Start off by adding both your VCSA and VCNS to the vCloud Director under Resources tab as you would normally.

Next, click on Provider VDCs to create your Pvdc and when you arrive at the ESXi host preparation step, you can type in anything for the username/password (since these are simulated ESXi host).

After you click next or finish, you then click into the Hosts tab to watch the ESXi host preparation. This is where you will notice the first issue, the preparation should finish almost immediately as thgey are simulated hosts, so no VCD agent is installed or services needing to be enabled, but from what I have seen this process can take up to 30minutes if not longer. You will need to be patient when you get to this point and do not try to cancel the process and just let it sit and finish. To ensure your environment is setup correctly, make sure the following three columns show green check marks: Enable, Ready and Available during the preparation.

This is probably a good time to get some coffee or tea and check out other cool articles on virtuallyghetto.com 😉

Once the ESXi hosts have completed preparation, you should see a green check box under the Status column which means you are now ready to create an Organization which is a pre-requisite before creating an Organization VDC. I will assume you know how to proceed from here and depending if you setup an ESXi 5.0 or ESXi 5.1 environment in vcsim, you will need to choose the appropriate virtual machine compatibility (virtual hardware) to support in your OrgVDC.

Note: If you setup an ESXi 5.0 environment, you may see an error with too many connected datastores, to resolve this, you need to either decrease the number of hosts in your simulated environment or use ESXi 5.1

You can probably guess the last step is to start provisioning VMs/vApps in our vCloud Director instance, but sadly this is where you will face another issue. What I have found is that when you deploy a new vApp, an exception is thrown regarding a NULL pointer and VCD will fail on the deployment.

However, if we take a look at our vcsim environment, you will see that the VM actually does get created but this still poses a problem for us in VCD, as the task is still not considered successful.

I have not been able to figure out why and I know from running through several tests, there was a case where I was able to successfully provision a VM in the VCD simulator. This might be related to the version of virtual hardware selected, I had more luck using either 7 or 8 but not so much with 9. Unfortunately, without provisioning capabilities, this may not be as useful as one would like but I encourage you to still give this a try if you are interested.

The vCloud API can also be access in the simulated environment, but remember that the operations will be limited to what has been shown and will probably work for most of the inventory based API calls, but again, YMMV.

Though vCloud Director Simulator is somewhat limited today and with a few known issues, it is a proof of concept that other VMware solutions can leverage what vcsim has provided as a base foundation. 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.

vCenter Server Simulator

by // 47 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>

 <simulator>
    <enabled>true</enabled>
    <cleardb>false</cleardb>
    <initinventory>vcsim/model/initInventory.cfg</initInventory>
 </simulator>

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-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.