WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Major Enhancements in esxcli for vSphere 5

07.14.2011 by William Lam // 10 Comments

esxcli in vSphere 5 has undergone significant updates compared to version in vSphere 4.1 which only had 6 major namespaces and 43 commands.

Namespace Description
corestorage VMware core storage commands
network VMware networking commands
nmp VMware Native Multipath Plugin (NMP) This is the VMware default implementation of the Pluggable Storage Architecture
swiscsi VMware iSCSI commands
vaai Vaai Namespace containing vaai code
vms Limited Operations on Virtual Machines

With latest vSphere 5 release, esxcli now includes a total of 10 namespaces and 251 commands! You will notice some of the updated namespaces from vSphere 4.1, such as corestorage which is under the namespace storage and it also contains other sub-namespaces dealing with the storage stack.

Namespace Description
esxcli Commands that operate on the esxcli system itself allowing users to get additional information
fcoe VMware FCOE commands
hardware VMKernel hardware properties and commands for configuring hardware
iscsi VMware iSCSI commands
license Operations pertaining to the licensing of vmware and third party modules on the ESX host. These operations currently only include updating third party module licenses
network Operations that pertain to the maintenance of networking on an ESX host. This includes a wide variety of commands to manipulate virtual networking components (vswitch, portgroup, etc) as well as local host IP, DNS and general hsot networking settings
software Manage the ESXi software image and packages
storage VMware storage commands
system VMKernel system properties and commands for configuring properties of the kernel core system
vm A small number of operations that allow a user to Control Virtual Machine operations

To get a complete list of the available esxcli commands in vSphere 5, you can run the following:

esxcli esxcli command list

The goal of esxcli is to provide a centralize, consistent and easy way of accessing and managing your ESXi host from both locally within ESXi Shell or remotely using vCLI and/or vMA. With the release of 5.0, the majority of the legacy esxcfg-*/vicfg-* commands have been migrated over to esxcli. At some point, hopefully not in the distant future, esxcli will be parity complete and the esxcfg-*/vicfg-* commands will be completely deprecated and removed including the esxupdate/vihostupdate utilities.

There are still several types of operations that require tools in addition to esxcli such as configuring licenses for standalone host, enabling/disabling local and remote ESXi Shell, enabling/disabling Fault Tolerance & vMotion traffic types just to name a few. For more details on some of the common operations that you may need to perform using both esxcli and other utilities, take a look at my ESXi 5 kickstart tip and tricks post.

The new remote version of esxcli is compatible with both ESXi 5 and ESX(i) 4.1 hosts. Due to the nature of the framework, the capabilities are located on the host and when you initially connect, it will automatically down the available namespaces that can be supported. The new namespaces in ESXi 5 will not be available on 4.1 but the old 4.1 namespaces will be. In the latest release, there are still no vSphere APIs exposed for esxcli, they are all still hidden. To access esxcli, you will need to either use local esxcli, remote esxcli using vCLI and/or vMA or PowerCLI's esxcli cmdlets.

The syntax of esxcli is very simple to understand:

To get more details on a namespace, you just need to specify the --help option after the namespace selection. In this diagram, we are accessing "network" namespace and we can see there are 5 additional namespaces we can access.

Let's say we're interested in the "firewall" and would like to know more, we can again specify --help option again.

Now we have a set of commands, let's go ahead and run the "get" command

As you might have guessed, the "get" command will get the network firewall status. The actual commands are pretty intuitive and you will find that most esxcli namespaces will support get, set and list operations. The other nice thing about esxcli is that the output is consistent whether you are running this locally on ESXi Shell or remotely using vCLI and/or vMA, which makes scripting extremely simple.

Note: With remote esxcli, you will need to specify the ESX(i) host and credentials to login to as it is going through the APIs.

You also have the ability to control the type of output that is generated whether that is xml, csv or keyvalue. To do so, you can specify --formatter option and specify one of those options. The xml and keyvalue pair works across all namespaces and csv works on majority of the namespaces.

Let's go ahead and run the same command as above but output it in keyvalue pair

~ # esxcli --formatter=keyvalue network firewall get
Firewall.DefaultAction.string=DROP
Firewall.Enabled.boolean=false
Firewall.Loaded.boolean=true

In addition to type of format output, you can also display specific columns of information using --format-param, this is useful in-conjunction with csv output.

Here is an example of listing the standard vSwitches without any formatting:

~ # esxcli network vswitch standard list
vSwitch0
Name: vSwitch0
Class: etherswitch
Num Ports: 128
Used Ports: 6
Configured Ports: 128
MTU: 1500
CDP Status: listen
Beacon Enabled: false
Beacon Interval: 1
Beacon Threshold: 3
Beacon Required By:
Uplinks: vmnic1, vmnic0
Portgroups: ESXSecretAgentNetwork, VM Network, vmk2, vmk1, Management Network
vSwitch1
Name: vSwitch1
Class: etherswitch
Num Ports: 128
Used Ports: 3
Configured Ports: 128
MTU: 1500
CDP Status: listen
Beacon Enabled: false
Beacon Interval: 1
Beacon Threshold: 3
Beacon Required By:
Uplinks: vmnic2
Portgroups: VMkernel

Here is the same example, but now only displaying Name, Num of Ports, MTU, CDP and Portgroups using the formatter and format-param options:

~ # esxcli --formatter=csv --format-param=fields="Name,Num Ports,MTU,CDP,Portgroups" network vswitch standard list
Name,NumPorts,MTU,Portgroups,
vSwitch0,128,1500,"ESXSecretAgentNetwork,VM Network,vmk2,vmk1,Management Network,",
vSwitch1,128,1500,"VMkernel,",

If you like to learn more about esxcli, you can take a look at the What's New in vSphere 5 Platform whitepaper. I would also highly encourage you to play with the new esxcli and see what the new capabilities are. Also, when the vSphere 5 documentation is released, a must read document is the Command-Line Management in vSphere 5.0 for Service Console Users which goes into detail about the specific esxcli commands to use in replacement of the esxcfg-*/vicfg-* commands.

Note: Hopefully it was okay to borrow some of these esxcli slides from VMware, I made some slight modifications. The diagrams are a great way to explain how esxcli namespaces work.

Categories // Uncategorized Tags // esxcli, ESXi 5.0, vSphere 5.0

Automating ESXi 5 Kickstart Tips & Tricks

07.13.2011 by William Lam // 58 Comments

There are some minor changes with kickstarting ESXi 5.0 but the majority of your existing ESXi 4.1 kickstart configurations can be re-used with a few modifications. One of my goals during the vSphere 5.0 beta was to automate as much of the configurations of an ESXi host as possible within the kickstart process. I also converted as many of the legacy esxcfg-* commands as I could over to the enhanced esxcli namespaces as the esxcfg-* commands will eventually be deprecated in favor of esxcli. Hopefully the tips & tricks and the example kickstart configuration file will be useful in aiding the transition to ESXi 5.0.

As usual, before diving in and creating an ESXi 5.0 kickstart configuration, make sure you spend some time going over the documentation provided by VMware, specifically the ESXi Installable and vCenter Server Setup Guide. If you would like to get a sense for what a ESXi 5.0 kickstart could look like, please jump to the bottom of this post to get a complete working example displaying the various types of configurations.

[Read more...]

Categories // Uncategorized Tags // ESXi 5.0, kickstart, ks.cfg, vSphere 5.0

How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5

07.12.2011 by William Lam // 66 Comments

With the release of vSphere 5, one of the most sought out feature from VMware is the ability to run nested 64bit and Hyper-V guest virtual machines in a virtual ESXi instance. Previous to this, only 32bit virtual machines were supported as the VT-x/AMD-V Hardware Virtualization CPU instructions could not be virtualized and presented to the virtual ESX(i) guest. This feature is quite useful for home and lab setups in testing new features or studying for VMware certifications and running multiple vESX(i) instances.

You will still be required to have a 64bit capable system and CPU and you will need to be running ESXi 5.0, this will not work for ESX(i) 4.x or older.

 
The above diagram depicts the various levels of inception where pESXi is your physical ESXi 5.0 hosts. We then create a vESXi 5.0 host which will contain the necessary Hardware Virtualization CPU instructions to support a 64bit nested guest OS which I've created as another ESXi host called vvESXi.
Note: You will not be able to run a 4th level nested 64bit VM (I have tried by further passing the HV instructions in the nested guest) and it will just boot up and spin your CPUs for hours.
This feature by default is disabled in ESXi 5.0, to enable this virtualized HV (Hardware Virtualization) you will need to add the following string vhv.allow = "TRUE"  to /etc/vmware/config of your Physical ESXi 5.0 host
Once the configuration change has been made, the feature goes into effect right away. A reboot of the system is not necessary. To verify, you should now be able to power on a 64bit guest OS and see that the HV instructions bits are being passed into the guestOS which will then allow you to run a nested 64bit guestOS. You can also verify by looking in the vmware.log file of the virtual machine and grep for the string "monitorControl.vhv" and if you see the following message, then Virtualized HV is not enabled.
In the past to run a virtual ESX(i) instance, a few advanced .vmx configuration entries were needed as documented here. With ESXi 5.0, if you are using virtual hardware version 8, then you do not need to make any additional changes. If you are using hardware version 4 or 7, then you will need to add a few changes to the VM's configuration file.
Creating vESXi 5.0 Instance using Hardware Version 8:
1. To create a virtual ESXi 5.0 instance, start off by just creating a standard RHEL5/6 64bit VM using the vSphere Client
2. Once the VM has been created, edit the settings of the VM and change over to the "Options" and now have the ability to select a new guestOS type: VMware ESXi 5.x or VMware ESXi 4.x under the "Other" section.

Note: I'm not sure why these two additional guestOS type is not available from the default creation menu, but are available after the initial VM shell is created.

3. You are now ready to install ESXi 5.0 in this new vESXi host and then you can create and power on nested 64bit guestOS within that vESXi instance as denoted from the picture below

Creating vESXi 5.0 Instance using Hardware Version 4/7:
1. To create a virtual ESXi 5.0 instance, start off by just creating a standard RHEL5/6 64bit VM using the vSphere Client

2. Now you will need to add the following advanced .vmx parameter:  monitor.virtual_exec = "hardware" which can be done through the vSphere Client and/or editing the .vmx parameter manually.

3. Next you will need to add some cpuid bits, depending if you are running an Intel or AMD CPU, the respective entries are required:

Intel Hosts:

cpuid.1.ecx = "----:----:----:----:----:----:--h-:----"

AMD Hosts:

cpuid.80000001.ecx.amd = "----:----:----:----:----:----:----:-h--"
cpuid.8000000a.eax.amd = "hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh"
cpuid.8000000a.ebx.amd = "hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh"
cpuid.8000000a.edx.amd = "hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh"

4. You are now ready to install ESXi 5.0 in this new vESXi host and then you can create and power on nested 64bit guestOS within that vESXi instance

By using a VM that is hardware version 8, you can easily automate the creation of vESXi 5.0 instance by changing the guestOS string in the .vmx parameter to "vmkernel" and the above configurations other than "vhv" string needed for either an Intel or AMD system are automatically configured.

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.  

Creating a vHyper-V  Instance on physical ESXi 5.0:
1. To create a virtual Hyper-V instance, start off by creating a Windows 2008 Server R2 64bit VM using the vSphere Client

2. If you are using Hardware Version 7, you will need to follow the instructions in "Creating vESXi 5.0 Instance using Hardware Version 4/7" to add the additional parameters to the VM. If you are using Hardware Version 8, you just need to change the guestOS type to VMware ESXi 5.0

3. You need to add one additional .vmx parameter which tells the underlying guestOS (Hyper-V) that it is not running as a virtual guest which in fact it really is. The parameter is hypervisor.cpuid.v0 = FALSE

4. You are now ready to install Hyper-V in a virtual machine and you can also spin up nested 64bit guestOSes in this virtual Hyper-V instance.

As you can see, now you can even run Hyper-Crap, err I mean Hyper-V as a virtualized guest under ESXi 5.0. I did not get a chance to try out Xen, but I'm sure with the ability to virtualize the Hardware Virtualization instructions, you should be able to run other types of hypervisors for testing purposes.

This is a really awesome feature but note that this is not officially supported by VMware, use at your own risk.

Categories // ESXi, Home Lab, Nested Virtualization, Not Supported Tags // ESXi 5.0, hyper-v, nested, vesxi, vhv, vSphere 5.0

  • « Previous Page
  • 1
  • …
  • 575
  • 576
  • 577
  • 578
  • 579
  • …
  • 613
  • 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

  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/2026
  • VCF 9.1 - Auditing vCenter Server Connections using the Connection Utilization API 06/15/2026
  • Quick Tip: Resolving OVFTool "Failed to Send File" Errors on macOS 06/13/2026
  • VCF 9.1 - Are You Using the Correct ESXCLI Command to Enable NVMe Tiering? 06/12/2026
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 © 2026