HL Tools – Part 2 – Create a Nested Hypervisor

During last year’s VMworld #NotSupported sessions one of the hot topics was William Lam‘s vInception talk. “Nested ESXi” has since then become indispensable in the homelab of everyone tinkering with virtualisation !

As a follow-up to that session, William posted several blog posts on the subject. You can find them all in a handy overview.


But as much as I like his clear instructions on how to set up nested ESXi, I wanted to automate the process 🙂 In my homelab I create, and remove, ESXi VMs on a regular basis. So with the “If you do it more than once, automate it” in mind, I decided to create a function for the process.

The Script


Line 60-68: A rather simple implementation of the Object By Name concept for the VMHost parameter.

Line 71-74: A test to verify that the function is running against an ESXi 5.1. Note that the function doesn’t test on “5.1 or higher“, the reason is that the concept in a future ESXi build may change.

Line 77-80: The function verifies that the ESXi server passed in VMHost supports Virtual Hardware-Assisted Virtualization (VHV).

Line 83-95: When a VM with the same Name already exists, the function will return unless the Force parameter is used.

Line 98: Contrary to the procedure to be used with the Web Client, we can immediately select the ESXi guestId.

Line 102-111: The “splattedNew-VM parameters

Line 116-119: If the CD switch was set to $True, the function will set the VM to boot from the CD/DVD.

Line 121-126: In case the HyperV switch was set to $True, the function needs to add the “hypervisor.cpuid.vo = FALSE” entry to the VMX file.

Line 137-141: If the CD switch was set to $True and an ISOPath was given, the function will connect the CD/DVD drive to the ISO.

Sample Usage

With the function you can now automate the creation of a number of nested hypervisors on your homelab server.

In the following example I create 3 VMs that will run nested ESXi hypervisors.

In a bit more than 1 minute my 3 nested ESXi VMs have been created, and are ready to be installed. Hardly enough time to get me a decent Belgian beer from the fridge 🙂


And the same can of course be done for the creation of a nested Hyper-V hypervisor.

Enjoy !



    Hi Luc-

    I have been using your great script in my ESXi home training lab for quite a while. It has proved to be very useful and as made it so easy for me to deploy nested ESXi VM’s on demand saving a lot of time manually configuring the custom parameters not to mention clicking!

    I tried to customize it to modify the script to do the following :

    (a) thin provision the disk
    (b) provide a datastore path
    (c) add a Resource Pool name

    Due to my somewhat limited POSH scripting abilities, I seem to have hit a small road block and hope you can provide me with some help on how I could modify the script to do the above.

    Many thanks


    Hi Luc, came across your very interesting blog which has some really cool scripts. I have to say you are a pro when it comes to automating. Whereas me I am a total novice when it comes to creating scripts from scratch but generally get by taking examples and modifying here and there to get by.

    When I try to add the Force=true in order to check for existing machines, I get errors:

    “Start-VM : 12/5/2013 4:15:34 PM Start-VM The object has already been deleted or has not been completely created”

    I can see that the existing VMs if powered ON are powered OFF and deleted, what I notice is for a few seconds it displays as an orphaned vm and immediately a new VM with the same name is created and I think the above error is caused when it tries to power ON.

    I was not sure where to put the Force = true in the below section: Is this where it should go??


    $nestedParams = @{
    Force = $true
    Name = $null
    VMHost = $esx
    DiskGB = 8
    NumCpu = 2
    MemoryGB = 8
    Portgroup = $pg
    CD = $false
    ISOPath = “[datastore1] ISO/VMware-VMvisor-Installer-5.1.0-799733.x86_64.iso”
    ESXi = $true


    Howdy, Luc-

    Great function, thanks for sharing! One thing: the “VMHost” key/value seems to be missing from the $hvParams hashtable (starting at line 102). Without it, the subsequent New-VM call is sad (talks about, ‘Please specify at least one of the following parameters: “ResourcePool”, “VMHost” or “VApp” ‘).

    Anyway, thanks again — very useful.



      Thanks for noticing that Matt, I corrected the code.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.