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)

Running ESXi 5.5/5.5u1 on Apple Mac Mini + Thunderbolt Ethernet Adapter Caveat

by // 160 Comments

I just upgraded my Apple Mac Mini 5,3 this morning from ESXi 5.1 Update 1 to the latest ESXi 5.5 release and I am very happy to report the upgrade worked flawlessly! When ESXi 5.5 is generally available, you will be able to just download the ISO and install or upgrade your existing Mac Mini without requiring additional drivers for the on-board network adapter to function correctly. If you have a Mac Mini 6,2 the old SMC issue has been resolved, but the PSOD issue is still occurring. As promised to some folks on Twitter, here is a custom ESXi 5.5 ISO for Mini 6,2 that you can just download and install without any manual intervention:

The only issue that I found is if you are using the Apple Thunderbolt Ethernet Adapter, you will find that after the install/upgrade, the network adapter no longer shows up. Looking into this issue, it looks like with the release of ESXi 5.5 and the introduction of the new Native Driver architecture, it had a slight impact to the Thunderbolt Ethernet Adapter. Having said that, the Apple Thunderbolt Ethernet Adapter and Mac Mini was never officially supported, so we were actually lucky that it had worked in the first place.

The reason the Thunderbolt Ethernet Adapter is not being recognized is that its device ID (14e4:1682) is not in tg3 (Broadcom) map file /etc/vmware/driver.map.d/tg3.map. If the device was officially supported, then it would have been automatically claimed by the vmkdevmgr which handles both vmklinux and Native Driver devices. The fix is actually quite simple and I have created a custom VIB called vghetto-apple-thunderbolder-ethernet.vib which will add the appriorpiate device ID to a new custom map file called /etc/vmware/driver.map.d/apple.map which will not collide with the existing tg3.map file. The reason for needing a custom VIB versus appending the device ID to something like /etc/rc.local.d/local.sh is that when the script runs it is too late from a networking stack point of view.

To install the custom VIB, you will need to upload it to your ESXi datastore and run the following command:

esxcli software vib install -v /vmfs/volumes/[DATASTORE]/vghetto-apple-thunderbolder-ethernet.vib -f

Now you can either use the vSphere Web/C# Client to verify the Thunderbolt Ethernet Adapter is showing up or you can run esxcli network nic list.

Flexible OVF deployments using Deployment Options (e.g. small, medium, large)

by // 28 Comments

It is pretty common these days to see a vendor distribute their applications as a virtual appliance which pre-bundles both an operating system and their application instead of a stand alone installer and provides that as an OVF/OVA download. This makes it extremely easy for customers to deploy a vendors application with very minimal effort.

One potential challenge with providing a virtual appliance is that the virtual hardware configuration such as CPU and Memory is pre-configured during deployment and usually optimized for the lowest common denominator such as a small environment or even home lab for that matter. Of course, it is trivial to increase these resources after deployment but would it not be nice if the vendor could provide a "sizing recommendation" option during the deployment of their virtual appliance?

It turns out the OVF format actually supports such a functionality called Deployment Options and this is probably something that is not very well known. I personally have only seen this feature get used in one of VMware's virtual appliances which is vCenter Operations. When going through the deployment wizard of vCenter Operations appliance, you will notice one of the steps is to select your deployment configuration which in this case is based on the number of virtual machines you have in your vCenter Server environment.

The deployment option in this example translates to the number of vCPU and vMemory that the virtual appliances will be deployed with. Of course this information can also be used within the guestOS as part of the initial boot to configure the application based on the resources allocated to the virtual appliance. If you are interested in learning more about Deployment Options and its capabilities, you can find more details on the DMFT website for the OVF standards document starting on page 35.

I recently became interested in this as there was an internal thread asking how to leverage this feature and I initially thought this would be a capability provided by VMware Studio which is a product that helps you build virtual appliances. After deploying VMware Studio, I was unable to find a way to enable this feature as part of the build. Currently it looks like you would need to manually edit the OVF file which is XML based (not ideal) to add in this extra capability. You can also take an existing virtual machine and export using the vSphere Web/C# Client to an OVF/OVA and then add in the Deployment Option as a quick and dirty way of leveraging this feature within your organization.

I took a look at vCenter Operations OVA file to see how Deployment Options work and it actually looks pretty straight forward and requires the following three sections:

  1. Deployment Option Definitions
  2. Virtual Hardware Configurations
  3. Deployment Option Text

I have also provided a sample OVF called MyApp.ovf that you can download to see how these options work.

Deployment Option Definitions

The first section describes your Deployment Options, in the example below we use the words small, medium and large. You can change this text to be anything such as bronze, silver and gold. The only thing to note is the id and msgid which will need to be maped to section #2 and #3

<DeploymentOptionSection>   
 <Info>The list of deployment options</Info>   
  <Configuration ovf:id="small">     
      <Label ovf:msgid="config.small.label"/>     
      <Description ovf:msgid="config.small.description"/>   
  </Configuration>   
  <Configuration ovf:id="medium">     
      <Label ovf:msgid="config.medium.label"/>     
      <Description ovf:msgid="config.medium.description"/>   
  </Configuration>   
  <Configuration ovf:id="large">     
      <Label ovf:msgid="config.large.label"/>     
      <Description ovf:msgid="config.large.description"/>   
  </Configuration>  
</DeploymentOptionSection>

Virtual Hardware Configurations

The second section describes the virtual hardware configuration and uses a configuration parameter id that maps back to the original definition. In the example here, we are looking at the number of vCPU's the virtual appliance can be assigned with. For the initial default, you do not need to specify an entry, but for the others you will need to. Here I have a definition for medium and large and their respective vCPU configuration.

<Item>
  <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
  <rasd:Description>Number of Virtual CPUs</rasd:Description>
  <rasd:ElementName>1 virtual CPU(s)</rasd:ElementName>
  <rasd:InstanceID>1</rasd:InstanceID>
  <rasd:ResourceType>3</rasd:ResourceType>
  <rasd:VirtualQuantity>1</rasd:VirtualQuantity>
</Item>
<Item ovf:configuration="medium">
  <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
  <rasd:Description>Number of Virtual CPUs</rasd:Description>
  <rasd:ElementName>2 virtual CPU(s)</rasd:ElementName>
  <rasd:InstanceID>1</rasd:InstanceID>
  <rasd:ResourceType>3</rasd:ResourceType>
  <rasd:VirtualQuantity>2</rasd:VirtualQuantity>
</Item>
<Item ovf:configuration="large">
  <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
  <rasd:Description>Number of Virtual CPUs</rasd:Description>
  <rasd:ElementName>4 virtual CPU(s)</rasd:ElementName>
  <rasd:InstanceID>1</rasd:InstanceID>
  <rasd:ResourceType>3</rasd:ResourceType>
  <rasd:VirtualQuantity>4</rasd:VirtualQuantity>
</Item>

Deployment Option Text

The final section contains the actual text you wish to display for each of your Deployment Configurations. You will see the msgid maps back to your definitions, so if you choose to change the wording, make sure these match up.

<Strings>
 <Msg ovf:msgid="config.small.label">Small</Msg>  
 <Msg ovf:msgid="config.small.description">Use this configuration for small deployments. This deployment will need 1 vCPUs and 1024 Memory for the vApp.</Msg>  
 <Msg ovf:msgid="config.medium.label">Medium</Msg>  
 <Msg ovf:msgid="config.medium.description">Use this configuration for small deployments. This deployment will need 2 vCPUs and 2048 Memory for the vApp.</Msg>  
 <Msg ovf:msgid="config.large.label">Large</Msg>
 <Msg ovf:msgid="config.large.description">Use this configuration for small deployments. This deployment will need 4 vCPUs and 4096 Memory for the vApp.</Msg>
</Strings>

Though I have experienced Deployment Options while deploying vCenter Operations in the past, thinking about it more now, it is definitely something that can be useful for folks building virtual appliances. The really nice thing about this feature is it works when deploying to both a vCenter Server as well as a standalone ESXi host.  Hopefully we will see more virtual appliances leveraging this neat feature of the OVF standard.