Building a self-configuring nested ESXi host vApp

In my last post I presented a walk-through about how to create a nested ESXi host and make an OVF template of it. After deploying this template a manual step remained: Configuring a hostname and the IP address configuration. If you deploy a virtual appliance that was produced by VMware (e.g. the vCenter Log Insight appliance) then you are often presented with the choice to configure the networking of the VM in the OVF deployment wizard. How is this done, and can we use the same method to customize the nested ESXi vApp? Yes, we can - and here is how.

How to provision nested ESXi hosts on free ESXi

Nested ESXi hosts (that means ESXi running inside a VM) are a very cool method to test and evaluate even complex vSphere scenarios on a single physical box. There are a lot of guides already available for installing a nested ESXi host, but most of them assume that you have a paid ESXi license or even vCenter available to manage it.

The free ESXi license though has some limitations that makes the job harder:

• It is not manageable via vCenter, and thus ...
• ... only via the legacy vSphere client, not the Web Client, which in turn means ...
• ... you are limited to virtual hardware version 9 and must not use version 10.
• And - that's most annoying - you also cannot use PowerCLI to create or configure VMs (because the relevant APIs are restricted with the free license)!

You can overcome these limitations by using free and fully featured evaluation licenses, but these are time limited. So, I thought it's time to write a little Nested ESXi Guide for free license users (It also includes some nice tips for paid-license users though!) ...

Annoying IP dual stack issue with VMware ESXi

While testing direct host access to the new V-Front Online Depot (via esxcli) I stumbled over an annoying issue that I was finally able to resolve, but it was hard to find the root cause ... So I want to share my findings here in the hope to make life easier for all the others that will - very likely - stumble over the same issue.

After opening the  firewall for outgoing http(s) requests using
   esxcli network firewall ruleset set -e true -r httpClient

you can try to access the Online Depot in an ESXi shell with commands like
  esxcli software sources vib list -d http://vibsdepot.v-front.de
  esxcli software vib install -d http://vibsdepot.v-front.de -n package-name

If you experience the issue then these commands will work as expected, but they will take a very very long time (>10 minutes!) to execute and return. Of course there are other and more obvious root causes for slow network access: a slow or saturated up-link to the Internet, improper NIC speed negotiation settings etc.

But in my case it had something to do with IPv6 ...

A new version of ESXi-Customizer - and why it is the final one

I have just released an updated version of my well known ESXi-Customizer tool. Version 2.7.2 comes with the following fixes and changes:

• The included mkisofs tool (that is used to build the customized ISO file) was replaced by a newer version that does no longer produce ISO files with corrupt headers when used with the UEFI boot option. In earlier versions I made the UEFI boot optional (and disabled by default), because it would create invalid ISO files that can not be opened by ESXi-Customizer itself or other applications. This is now fixed, and UEFI boot is no longer an option, but always enabled.
• Added detection of Windows 8/8.1 and Server 2012 (R2) to the Windows version check. These are all supported for customizing ESXi 5.x, but not for ESXi 4.1.
• Added a check for the parentheses characters "(" and ")" in package file names (These would make the script fail in earlier versions).
• Moved the version update check script to my new site http://vibsdepot.v-front.de. This is also the new place to download ESXi-Customizer, because Google does no longer want us to provide downloads at Google Code. 

At the same time I officially declare the ESXi-Customizer tool deprecated. The new version 2.7.2 will be the final one (unless there is a really stupid bug in it that makes it useless)! So, why will I stop development on a tool that has been downloaded about 100.000 times as of today?!?