WilliamLam.com

New vCenter Server Simulator 2.0 enhancements in VCSA 5.5

by // 47 Comments

Last year I wrote about a very interesting tool called vCenter Server Simulator (VCSIM) which allows a user to quickly simulate a VMware environment that can be comprised of thousands of ESXi hosts and virtual machines. VCSIM can benefit a variety of use cases such as learning about the vSphere API, creating reports for vSphere or vCloud Director to building vSphere Web Client plugins to help visualize large inventories. There was an overwhelming interest in VCSIM from last year and I received some great feedback and feature requests which I fed back to the VMware engineers who developed this internal tool.

With the upcoming version of vSphere 5.5 to be released very soon, I was wondering if there were going to be any new features for VCSIM in VCSA 5.5? I reached out to one of the engineers, Haiping Yang, who works in the Performance Engineering team who is currently taking over some of the development of VCSIM. Some of you might be familiar with some of her work such as the recent visualEsxtop, esxtop and resxtop to just name a few. In talking to Haiping, I found that she has been quite busy adding cool new features to VCSIM and this is on top of her regular day job!

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

Here is a quick summary of the new features of VCSIM 2.0:

Distributed Virtual Switch (VDS) Support:

  • Add / Remove ESXi hosts from VDS
  • Create / Delete Distributed Virtual Portgroup
  • Reconfigure Distributed Virtual Portgroup
    • Add / Remove VM from Distributed Portgroup

vCloud Networking & Security (vCNS) Support:

  • Create / Delete vCNS Gateway
  • Create / Delete Isolated/Routed Org Networks
  • Create / Delete vApp Networks
  • Deploy / Undeploy vApp with DHCP service enabled

Persistent Inventory Configuration upon restart:

  • Folder, Cluster, Resource Pool, Host, Datastore, Virtual Machine, Network and VDS

Custom Configuration Support:

  • ESXi version template
  • ESXi configuration template
  • Datastore configuration
  • Virtual Machine datastore

Easy startup commands:

  • vmware-vcsim-start
  • vmware-vcsim-stop [true|false] - Determines whether the inventory is cleared after stopping VCSIM

Note: Before you can use VCSIM, you will need to configure the VCSA as you normally would by going through the VAMI interface or running through the SSH commands noted in this article.

I will not go over every single feature mentioned above, but I did want to take a look at a few noteworthy features such as the new VCSIM start/stop command, datastore configuration and ESXi host configuration templates.

VCSIM Start/Stop Commands:

With the previous version of VCSIM, you had to manually edit the vCenter Server configuration file (vpxd.conf) and append the necessary VCSIM configurations. In this release, we now have an easy to use command-line utility to start and stop VCSIM. The vmware-vcsim-start command supports several startup options.

To view the list of supported options, just run the following command:

vmware-vcsim-start help

Option 1 - You can specify a VCSIM configuration file and you can find several examples located in /etc/vmware-vpx/vcsim/model

Option 2 - You can specify either the keyword "empty" for a blank vSphere inventory or "default" which will automatically use /etc/vmware-vpx/vcsim/model/vcsim-default.cfg inventory configuration

Option 3 - You can just specify the inventory layout on the command-line. An example would be "custom:dc=1,cluster=1,rp=1,host=1,vm=1,vm_on=1,latency=true"

To get a list of all the available VCSIM configurations, take a look at /etc/vmware-vpx/vcsim/model/vcsim.cfg.template

Here is an example of starting VCSIM using the "default" mode:

vmware-vcsim-start default

 

Datastore Configuration:

Custom datastore configuration was something that was much sought after with VCSIM 1.0 and unfortunately, there was only a single global datastore that was automatically "connected" to all simulated ESXi host. The new version of VCSIM now supports custom datastore configurations that can be defined globally, at the cluster level, local storage as well as string prefix which can help you separate out different VCSIM instances.

Here is an example of the configuration that would need to be added to the VCSIM configuration file:

<datastore>
   <global>1</global>
   <cluster>4</cluster>
   <local>5</local>
   <prefix>vghetto</prefix>
</datastore>

Here is what one of the simulated ESXi hosts would show for its datastores:

 

ESXi Configuration Template:

Another useful feature that I personally have asked for is the ability to customize an individual simulated ESXi host. Though this is still currently a work in progress, what you can do with VCSIM 2.0 is to customize the ESXi host version as well as the datastores on a per host basis. If you take a look vcsim.cfg.template, you will find a configuration line that looks like:

vcsim/model/hostConfig

This specifies a directory that would contain custom simulated ESXi host templates and their configurations. A sample host template is provided at /etc/vmware-vpx/vcsim/model/hostConfig.xml.template and currently, you need to specify the default simulated hostname (e.g. DC0_C0_H0.xml).

Here is an example of what that host template can look like:

<hostConfig>
  <datastores>
     <ds id="virtuallyGhetto-datastore-1"/>
     <ds id="virtuallyGhetto-datastore-2"/>
     <ds id="virtuallyGhetto-datastore-3"/>
  </datastores>
</hostConfig>

Now if we go back to our DC0_C0_H0 ESXi host, you will see that the host template will override the global configuration:

For the two examples above, here is what I used in my custom VCSIM configuration file that I called vcsim-virtuallyghetto.cfg if you are interested in what I used:

<simulator>
  <enabled>true</enabled>
  <initInventory>vcsim/model/initInventory-default.cfg</initInventory>
  <hostConfigLocation>vcsim/model/hostConfig</hostConfigLocation>
  <datastore>
     <global>1</global>
     <cluster>4</cluster>
     <local>5</local>
     <prefix>vghetto</prefix>
  </datastore>
</simulator>

I have already asked for the ability to fully customize the simulated ESXi host display name and have already been told that this is something they would consider for a future release. VCSIM 2.0 has also been improved to better operate with vCloud Networking & Security and vCloud Director. I was able to quickly test VCSIM 2.0 with the latest version of vCloud Director 5.5 and everything seems to be working fine. You can follow the existing instructions here for vCloud Director setup with VCSIM.

As you can see VCSIM 2.0 contains many new features and I highly encourage you to give it a spin when vSphere 5.5 is made generally available. There are definitely some additional fit and finish features that Haiping just could not get into this release. Hopefully we will get those updates in a future release of VCSIM and include additional ESXi template versions. If you have any feedback, comments or feature requests feel free to leave a comment and I will make sure it reaches Haiping and the development team. I do not want to spoil the surprise, but I just want to say one of the features coming in VCSIM 3.0 will be quite AWESOME! 😀 (sorry for the tease)

Quick Tip - Minimum amount of memory to run the vCenter Server Appliance

by // 18 Comments

I thought this might have been common knowledge, but after chatting with a VMware colleague who recently rebuilt his home lab, I realized it may not be the case. The vCenter Server Appliance (VCSA) is distributed as a virtual appliance and by default it is configured for 8GB of memory. However, this is definitely NOT the "minimum" amount of memory required to have a fully functional vCenter Server.

It looks like some people are just downloading the vCenter Server appliance and just sticking with the defaults of 8GB of memory which for a home lab is quite a large footprint, especially given you will probably want to install other virtual machines. The actual minimum for vCenter Server (Windows or Linux) is just 4GB and technically speaking, you can even get away with just 3GB for the vCenter Server Appliance (anything less, the system is extremely slow and unusable).

Here is a quick screenshot showing vCenter Server Appliance running with only 3GB of memory:

VMware also has a KB article detailing the minimum requirements for the vCenter Server Appliance based on the number of virtual machines and hosts you plan on running. For my home lab, I normally stick with the 4GB of memory and I have not had any issues. Hopefully this tip will help you save some memory for either your lab or even production environment for other workloads.

Automating VCSA Network Configurations For Greenfield Deployments

by // 6 Comments

If you deploy the VCSA (vCenter Server Appliance) or other virtual appliances directly onto an ESXi host,
you will notice the network configuration wizard for the virtual appliance is not available as you would expect when deploying to a vCenter Server.

The reason for this is that ESXi does not support some of the advanced OVF/OVA properties such as the Networking section and you will need to deploy the OVF/OVA to a vCenter Server to be able to configure these advanced options. This poses a problem if you need to deploy the VCSA in a greenfield environment where you will not have an existing vCenter Server running and you will be deploying directly to the ESXi host. Unless you have a DHCP enabled network, you will most likely need to manually go into the vSphere C# Client to change the network configuration as it was unable to obtain an IP Address.

Though this is a one time configuration, it is still not ideal and would require the use of a Windows system to access the vSphere C# Client. You can actually get around this by leveraging the GuestOperations API (previously known as VIX API) which allows you to perform operations within the guestOS that is running VMware Tools. The other nice thing about the GuestOperations API is that it does not require any network connectivity from the virtual machine.

Note: The GuestOperations API can be accessed in variety of ways and in this article I am demonstrating just two methods and does not require a Windows system. You can also access the GuestOperations API using PowerCLI if you are more comfortable with Windows and do not wish to use the vSphere C# Client to manually configure the network settings for the VCSA. I would also like to stress that though this article is about the VCSA, you can easily apply this to any VMware based virtual appliance or virtual appliance running VMware Tools.

The most important thing to identity before using the GuestOperations API is the specific command or program you wish to invoke and the argument it accepts. To configure the network configuration for the VCSA or any other VMware based virtual appliance, you would use /opt/vmware/share/vami/vami_set_network If you just run this command by itself, there are variety of options from IPv4 to IPv6, static or dhcp configuration. In our example, we will be configuring a Static IPv4 address for our VCSA and the command we would run is the following:

/opt/vmware/share/vami/vami_set_network "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Method 1 - Using RVC (Ruby vSphere Console)

 

RVC is a nice open-source tool for interactively managing and configuring your vSphere infrastructure. RVC can be installed on any platform, in this example, I am running RVC on my Apple OS X laptop.

Step 1 - We first need to deploy the VCSA OVA and we can do so by using the ovftool via the command-line which can also be installed on Mac OS X system.

Step 2 - We then login to our ESXi host using RVC.

Step 3 - Next we will need to "change directory" to the location of our VM, in this example my VCSA is called VCSA-5.1. We can then run the "info ." command to view the summary of our VM. We can see that our VM is powered on from our initial deployment and we are ready to apply our network configurations in the next step.

Step 4 - To be able to run the above command, we will need to first authenticate into the guestOS. To do so, we will run the "vm_guest.authenticate ." and we will be prompted for the VCSA password. By default, the command assumes the username is root but that can also be specified on the command-line. If you are successful, you should not see any errors and then we can run the "vm_guest.start_program" command. Run the following to set a IPv4 static IP Address:

vm_guest.start_program . --program-path /opt/vmware/share/vami/vami_set_network --arguments "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Note: All commands in RVC can be tabbed out with auto-completion.

If the command was successful, you can quit RVC and you should be able to ping the IP Address that you have just configured.

Method 2 - Using vSphere SDK for Perl Script

 

Awhile back I wrote a script called guestOperations.pl which is a vSphere SDK for Perl script that implements the new GuestOperations API. This is a generic script which can be used to remotely connect to either a vCenter Server or ESXi host and perform operations within a guestOS as long as VMware Tools is installed and running. In this example, I also have the vSphere SDK for Perl installed on my Mac OS X laptop, but you can also install this SDK on any platform as well.

Step 1 - We will first use the "validate" operation to ensure our credentials to the guestOS is correct, but more importantly ensure that VMware Tools is up and running.

If the operation was successful, we should see our guest credentials validated. If not, you may need to wait a minute or two while VMware Tools is still loading up.

Step 2 - To invoke the command to configure the network configuration, we will use the "startprog" operation and run the following:

./guestOpsManagement.pl --server mini --username root --guestusername root --vm VCSA-5.1 --operation startprog --program_path /opt/vmware/share/vami/vami_set_network --program_args "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1" --working_dir /

If the command was successful, then you should now be able to ping the IP Address that you have just configured.

As you can see, with the use of the GuestOperations API, you can do more than just setup the network configuration for a VM, you can run pretty much any command within the guestOS as you normally would if you were to RDP or SSH in. This is a very powerful interface that you can leverage to help you automate your virtual machine deployment and configurations!