I finally found a bit of "extra" spare time to update my Nested ESXi Virtual Appliances to support some of the recent releases of ESXi, 6.0 Update 3 and 6.5d, which enables customers to easily and quickly deploy vSAN 6.6 in their environment for testing, development or learning purposes. If you have not used this appliance before, please have a look at this article which goes into greater detail on how to deploy and use the Nested ESXi VA.

As part of this update, I also spent some time looking at all the feedback that I had received from the community since releasing the VA and I took this opportunity to also add some nice enhancements that folks have been asking about 🙂 Jump towards the bottom to see what's new. To reduce the number of VA's that I need to manage and due to usage, the following VA's have recently been decommissioned. I only plan on supporting the latest versions which you can find in the links below.

Decommissioned VA's:

  • ESXi 5.5 Update 3 (Nested_ESXi5.x_Appliance_Template_v2.ova)
  • ESXi 6.0 Update 2 (Nested_ESXi6.x_Appliance_Template_v5.ova)
  • ESXi 6.5 GA (Nested_ESXi6.5_Appliance_Template_v1.ova)

New VA's:

What's New:

  • Support for DHCP 
    • I know this might sound pretty basic but before you were required to specify a static IP (even if you had DHCP). By default, you no longer need to fill out the networking section as highlighted in yellow below.
  • Support for default root password
    • You no longer need to provide root password, it will default to the famous VMware1! The issue in the past was that I had randomly generated a password which I discarded and when the customization failed, it was very difficult to troubleshoot since I do not actually have the password 😉 Hopefully we do not have any other bugs, but this will make debugging easier and also reduce the amount of input if you want to quickly spin up an ESXi instance.
  • Support for VLAN ID
    • Though not a huge number of requests, there were still of you who asked for 802.1q (trunk) support on Management VMkernel interface. This is an optional field and obviously this is only applicable if you provide a static IP Address.
  • Automatic removal of Customization VIB
    • As some of you may or may not know, the way in which these OVF properties are processed within the Nested ESXi instance is a special firstboot script which reads in these values and then applies the ESXi customization. If everything is successful, there really is no use for this to exists further and although you could set a certain advanced setting to force re-customization, it was quicker to just re-deploy. With that in mind, the customization VIB is now automatically removed once its done its job. I have included a special debug option that would allow it to not be deleted in scenarios where there are issues and we need to take a look at the state of the system. With this change, you really now have a "vanilla" ESXi instance 🙂
  • Fixed dvFilter param for eth1


Hope you enjoy some of these new updates and happy Nesting!

12 thoughts on “Updated Nested ESXi 6.0u3 & 6.5d Virtual Appliances

  1. >>very difficult to troubleshoot since I do actually have the password
    I think you meant “don’t” 🙂

    RE: customization VIB
    Probably best to remove this anyways. If it’s not signed and it’s installed then if you turn on Secure Boot for these VM’s it will crash with a PSOD.

    • haha, yea “don’t” 🙂

      There’s a bug w/OVF import, so I’m unable to install using Secure Boot (but even if I was, it wouldn’t be able to use it as I do require this customization to exists for this to work :))

      • I’m talking about enabling secure boot after you’re done with the customization VIB. If you remove your (unsigned I’m assuming) VIB then you should then be able to enable Secure Boot.

        In fact, you could automate it. Deploy the VM, do whatever it is you do, the VIB gets cleaned up and VM shuts down.

        Then your master build script that deployed/built the VM could enable Secure Boot with a little PowerCLI

        $SecureBootValue = (Get-AdvancedSetting -Entity $vmname -Name “uefi.secureBoot.Enabled” | `
        Set-AdvancedSetting -Value:$true)

        • Mike,

          It was you who mentioned to me that if you didn’t install ESXi w/Secure Boot on, then enabling it after the fact wouldn’t be considered valid or something of that nature as I recall having this convo with you pre-6.5 GA. Is that not the case?

          • I don’t recall saying that.. Maybe I did but it’s not correct. 🙂 You can enable Secure Boot at any time. If you have unsigned code then you get a PSOD. If you remove it and boot clean then you’re good.

            Obviously, that doesn’t help things like kickstarts and startup shell scripts and config files, but that’s a separate argument. We’re talking about just binaries and other files that are in VIBs. If you boot with Secure Boot then you’re “clean”.

          • Yea, I recall since I was going to do this OOTB, but then it was mentioned I had to have installed ESXi w/SB enabled first.

            Good to hear that’s not the case (which is what I figured but didn’t do exhaustive testing). In my scenario, it is a chicken/egg but with some additional external automation, yes you could enable it if you really want to 🙂

  2. Ty for this. This is extremely helpful to new comers like me. I am learning and hoping to pass the VCP6-DCV in the coming months.

    If you can do a walkthough on you tube for setting up the networking on a single physical host for nested virtualization that would be extremely helpful.

    I want to isolate all my Nested lab traffic and run it through a virtual pfsense firewall. This is to block/prevent the eternal network traffic for DHCP DNS etc from mixing with the lab network.

  3. Extremely useful, very timely! By the way, for DHCP anyway, it still seems to have “primp-industries.com” in there for FQDN, rather than the FQDN my local DHCP server is telling it to use, “lab.local”. Workaround is to:
    1) create reservation in DHCP server for that host, setting FQDN and shortname to desired hostname, like esxi1.lab.local/esxi1
    2) use DCUI to manually change DNS Configuration to “Obtain DNS server addresses and a hostname automatically”
    3) remove the “primp-industries.com” from “Custom DNS Suffixes”
    4) Restart Management Network
    Tada, all squared away, passes “Test Management Network.”

      • Hm, that shouldn’t be the case. I’ll have to double check as I actually do all the clean up of things like DNS (as that was the case for the original VA). Syslog shouldn’t be set, you sure you didn’t just deploy and accept the syslog entry which has a “default” which is merely an example from a UI standpoint?

  4. For the syslog comment, no worries at all, I was just saying it’s hard-coded (like your screenshot shows), unless the user deploying it changes it (preferred), or removes it (leads to warnings if there’s no datastore), that’s all. Examples are fine, of course. Have a good evening!

Thanks for the comment!