WilliamLam.com

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.

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: