WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Having Difficulties Enabling Nested ESXi in vSphere 5.1?

09.29.2012 by William Lam // 21 Comments

I noticed there were a few folks having some difficulties enabling Nested ESXi (VHV Virtual Hardware Virtualization) in the latest release of ESXi 5.1 and I thought I share some additional info and tips on troubleshooting your setup in case you are running into similar problems.

*** DISCLAIMER **** This is not officially supported by VMware, do not bother asking if it is supported or calling into VMware support for details or help.

If you wish to run nested ESXi or other hypervisors on ESXi 5.1 and run 32-bit nested virtual machines, you must meet the following hardware requirement:

  • CPU supporting Intel VT-x or AMD-V

If you wish to run nested 64-bit virtual machines in your nested ESXi or other hypervisors, in addition to the requirement above, you must also meet the following hardware requirement:

  • CPU supporting Intel EPT or AMD RVI

If you only meet the first criteria, you CAN still install nested ESXi or other hypervisors on ESXi 5.1, BUT you will only be able to run 32-bit nested virtual machines. When you create your virtual machine shell using the new vSphere Web Client, in the expanded CPU view, the "Hardware Virtualization" box will be grayed out. This is expected as you do not have full support for VHV, but you can still continue with your installation of ESXi or other hypervisors.

In ESXi 5.0, you may have been able to run 64-bit nested virtual machines without EPT/RVI support but performance was extremely poor. With ESXi 5.1, VHV now requires EPT/RVI.

Note: During the installation of ESXi, you may see the following message "No Hardware Virtualization Support", you can just ignore it.

If you are using sites such as Intel's ark.intel.com to check your CPU requirements, be aware that it is COMMON even for the hardware vendors to publish incorrect information about their websites. However, there is a quick way you can validate on your ESXi host whether you have full VHV support.

In vSphere 5.1, there is a new capability property called nestedHVSupported which specifies whether your physical ESXi 5.1 host has full VHV support. This property will only be true IF your CPU has both Intel-VT+EPT or AMD-V+RVI. A quick and easy way to validate this is using the vSphere MOB to retrieve the value.

To check nestedHVSupported property, please enter the following into a web browser (substitute the IP Address/hostname of your ESXi host):

https://himalaya.primp-industries.com/mob/?moid=ha-host&doPath=capability

After you login, search for the nestedHVSupported property on the page and you should see a value of either true or false. As mentioned earlier, if it is false, you might still be able to install nested ESXi or other hypervisors but you will not be able to run nested 64-bit virtual machines. I would also recommend taking a look at your system BIOS to ensure things like Intel-VT/EPT and AMD-V/RVI are enabled and sometimes it might just be as simple as a BIOS upgrade (you can always confirm by contacting the hardware vendor if you have further questions).

For proper networking connectivity, also ensure that either your standard vSwitch or Distributed Virtual Switch has both promiscuous mode and forged transmit enabled either globally on the portgroup or distributed portgroup your nested ESXi hosts are connected to.

Additional Resources: 

  • How to Enable Nested ESXi & Other Hypervisors in vSphere 5.1
  • How to Enable Nested ESXi & Other Hypervisors in vCloud Director 5.1

Categories // Uncategorized Tags // ESXi 5.1, hyper-v, nested, vcd, vcloud director 5.1, vesxi, vhv, vsel, vSphere 5.1

Creating Custom VIBs For ESXi 5.0 & 5.1 with VIB Author Fling

09.28.2012 by William Lam // 41 Comments

VMware Labs just released a really cool new Fling called VIB Author which is a tool that allows you to easily create custom VIBs for your ESXi 5.x hosts. If you have tried to create custom ESXi firewall rules or add custom scripts to your ESXi host, you may have noticed they are not persisted after a system reboot and you had to play all sorts of games to get the files to persist. The VIB Author tool now solves that problem and you can even take your custom VIB and integrate them into an Auto Deploy Image Profile using Image Builder. Before you jump right in, be sure to read over the important note in the documentation before getting started.

So how does the VIB Author tool work?

You will need to provide two pieces of input: payload which is set of files you wish to include in your VIB and the descriptor.xml which contains the metadata for your files. From that, VIB Author can produce either a VIB and/or an offline bundle (can be used with Image Builder).

VIB Author is distributed only as an RPM and you will need to install the VIB Author tool on a 32-bit Linux system (sorry, no 64-bit support). In my home setup, I went with CentOS 6.2 i386 as it was free to download & easy to setup or you may choose go with SUSE Linux Enterprise 11 SP2 which is the recommended platform per the documentation.

UPDATE (07/25/23) - To create custom VIBs for ESXi 8.x or later, please see the update process HERE.

To install the RPM, run the following command:

rpm -ivh vmware-esx-vib-author-5.0.0-0.0.844296.i386.rpm

In the example below, I will show you how to create a custom VIB that contains several different configurations:

  • Custom Firewall Rule
  • Custom Startup script (adds a static route)
  • Custom Files (ghettoVCB)

Disclaimer: The example below is not officially supported by VMware, please thoroughly test this in a development environment before using in production.

Here is the directory structure for the example that we will be going through:

Step 1 - Create your stage directory structure which we will then populate with your payload files as well as the descriptor.xml file.

mkdir -p stage/payloads/payload1

Step 2 - Create your descriptor.xml file which should be placed in the stage directory. For more details on the parameters within the descriptor.xml, please take a look at the documentation.

Here is an example of my descriptor.xml file:

<vib version="5.0">
  <type>bootbank</type>
  <name>virtuallyghetto</name>
  <version>5.0.0-0.0.1</version>
  <vendor>virtuallyGhetto</vendor>
  <summary>Custom VIB from virtuallyGhetto</summary>
  <description>Adds custom firewall rule, ghettoVCB script and static routes to ESXi host</description>
  <relationships>
    <depends>
    </depends>
    <conflicts/>
    <replaces/>
    <provides/>
    <compatibleWith/>
  </relationships>
  <software-tags>
  </software-tags>
  <system-requires>
    <maintenance-mode>false</maintenance-mode>
  </system-requires>
  <file-list>
  </file-list>
  <acceptance-level>community</acceptance-level>
  <live-install-allowed>true</live-install-allowed>
  <live-remove-allowed>true</live-remove-allowed>
  <cimom-restart>false</cimom-restart>
  <stateless-ready>true</stateless-ready>
  <overlay>false</overlay>
  <payloads>
    <payload name="payload1" type="vgz"></payload>
  </payloads>
</vib>

Step 3 - Create the directory structure and store the files you wish to include under payload1. Ensure the the directory structure matches the absolute path of how you want the files to appear on the ESXi host. For example, if you wish to create a file call foo in /etc/vmware/foo then your directory structure should look like stage/payloads/payload1/etc/vmware/foo

Note: In the documentation, there is a list of default supported paths, if you venture off of this supported list, then you will need to issue the -f flag when creating your VIB as well as installing your VIB on your ESXi host

So for our examples we have the following files:

stage/payloads/payload1/etc/vmware/firewall/virtuallyghetto.xml
This one should be pretty straight forward, we are just creating a custom ESXi firewall rule and you will need to place your configuration file under /etc/vmware/firewall, please take a look at this article for more details on creating your own firewall rules.

stage/payloads/payload1/etc/rc.local.d/999.addStaticRoute.sh
This is a custom shell script that adds a static route to an ESXi host upon bootup under /etc/rc.local.d. There maybe other startup scripts that could be executed and you do not want to conflict with any system defaults. I recommend you label yours with a high number such as 999 to ensure it is one of the last scripts to execute.

stage/payloads/payload1/opt/ghettoVCB/{ghettoVCB.conf,ghettoCB-restore.sh,ghettoVCB.sh}
This is a custom set of files that I would like to store in ESXi under /opt directory and the files are my free ghettoVCB backup script.

Here is a copy of my directory structure (stage.zip) which can be used as a reference.

Step 4 - Now we ready to create our VIB and/or offline bundle by specifying our stage directory as input. In this example, we will generate both a VIB as well as an offline bundle containing the same contents. Run the following command:

vibauthor -C -t stage -v virtuallyghetto.vib -O virtuallyghetto-offline-bundle.zip -f

Note: Since we added some files outside of the default supported paths, we also need to specify the -f flag to force the creation.

We can also extract information about our VIB by using the -i option in VIB Author, to do so, run the following command:

vibauthor -i -v virtuallyghetto.vib

Finally, we are now ready to copy the VIB over to our ESXi host and install our custom VIB.

To install VIB run the following command:

esxcli software vib install -v /vmfs/volumes/[datastore-name]/virtuallyghetto.vib -f

To install the offline bundle run the following command:

esxcli software vib install -d /vmfs/volumes/[datastore-name]/virtuallyghetto-offline-bundle.zip -f

Note: You need to specify the -f flag to force the installation since we created files in an unsupported path. I have been able to test the VIB and offline bundle installation on both ESXi 5.0 as well as ESXi 5.1

To confirm we have succesfully installed our custom VIB, we can query it by running the following command:

esxcli software vib list | grep virtuallyghetto

So there you have it, in just a few steps, you can create your own custom VIBs!

Categories // ESXi, Not Supported Tags // auto deploy, ESXi, ESXi 5.0, fling, image builder, image profile, tgz, vgz, vib

Lossless OVF Export in vSphere 5.1 & vCloud Director 5.1

09.27.2012 by William Lam // 5 Comments

Did you know in vSphere 5.1, the new vSphere Web Client now provides a lossless OVF export feature for virtual machines? Previous to this, when you exported a virtual machine only the basic configurations were captured to ensure the virtual machine could be re-imported into another environment that supports OVF. The virtual machine's "virtual hardware personality" such as the BIOS UUID, MAC addresses, VMware specific advanced settings (Extra Configurations), boot order, PCI slot numbers, etc. were not captured as part of the export.

One of the main reasons for doing this is to ensure greater portability of the virtual machine across different environments. By having some of these specific properties tied to the virtual machine, it could limit where a virtual machine could be imported to. However, if you wish to preserve some of these settings during an export, you now have a new advanced option in vSphere 5.1 to specify additional configurations to capture for an OVF export.

When you select the "Enable advanced options" box, you will be provided with a list of configurations that you can preserve and export with the virtual machine.

Note: As the warning message states, only enable the configurations that you absolutely need, else you should stick to the defaults to ensure you have the best portability for your virtual machine export.

There is also a similar feature in vCloud Director 5.1 for vAppTemplates. When you initiate a download of a vAppTemplate, you now have an additional check box to "Preserve identity information" of the vAppTemplate prior to export. This is just a single check box for vCloud Director, you can not specify which configurations you want to preserve.

All these new OVF features can also be accessed with the latest ovftool 3.0.1 release which includes several new enhancements as well as support for both vSphere 5.1 and vCloud Director 5.1. You can find more details in the ovftool 3.0.1 user guide, but here is a summary of what's new in this release.

What Is New in OVF Tool 3.0.1

  • Support for vSphere 5.1 and 5.0.  
  • Support for vCloud Director 5.1, 1.5, and partial support for vCloud Director 1.0
  •    The following new ovftool options: --annotation, --exportFlags, --shaAlgorithm, --sourcePEM, --targetPEM, --vCloudTemplate, --sourceSSLThumbprint, --targetSSLThumbprint, --fencedMode, --noSSLVerify, --vService.

Feature Highlights

  • Full support for vCloud Director 1.5 and 5.1
  • Includes full OVF 1.0, and 1.1 support and backward-compatible mode for importing existing OVF 0.9 packages
  • Supports both import and generation of OVA packages (OVA is part of the OVF standard, and contains all the files of a virtual machine or vApp in a single file.)
  • Directly converts between any vSphere, vCloud Director, VMX, or OVF source format to any vSphere, vCloud Director, VMX, or OVF target format
  • Accesses OVF sources using HTTP, HTTPS, or FTP, or from a local file 
  • Deploys and exports vApp configurations on vSphere 4.0 targets and later and on vCloud Director 1.5 targets and later
  • Provides options to power on a VM or vApp after deployment, and to power off a virtual machine or vApp before exporting (caution advised)
  • Show information about the content of any source in probe mode
  • Provides context sensitive error messages for vSphere and vCloud Director sources andtargets, showing possible completions for common errors, such as an incomplete vCenter inventory path or missing datastore and network mappings
  • Provides an optional output format to support scripting when another program calls OVFTool
  • Uses new optimized upload and download API (optimized for vSphere 4.0 and later)
  • Signs OVF packages and validates OVF package signatures
  • Validates XML Schema of OVF 1.0 and OVF 1.1 descriptors
  • Import and export of OVF packages into a vApprun1.0 workspace. For more information about vApprun, see http://labs.vmware.com/flings/vapprun.

Categories // Automation, OVFTool Tags // export, lossless, ova, ovf, ovftool, vSphere 5.1, vsphere web client

  • « Previous Page
  • 1
  • …
  • 473
  • 474
  • 475
  • 476
  • 477
  • …
  • 560
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025