Home > Blogs > VMware vSphere Blog > Tag Archives: esxcli

Tag Archives: esxcli

Are ESXi Patches Cumulative

Updated based on feedback.  Thanks for the comments!

I’d like to revisit the question “are ESXi patches cumulative”?  This time I hope to hammer home the point with an example.

In short, the answer is yes, the ESXi patch bundles are cumulative.  However, when applying patches from the command line using the ESXCLI command you do need to be careful to ensure you update the complete image profile and not just select VIBs.

There are two ways to update VIBs using the ESCLI command.  You can use either the “esxcli software vib update … command or the “esxcli software profile update …” command.  The “vib” namespace is typically used with the optional “-n <vib name>” parameter in order to update individual VIBs, where the “profile” namespace is typically used to update the host’s image profile, which may include multiple VIB updates.  The key is when applying patches use the “profile” namespace to update the complete image profile opposed to using the “vib” namespace to update selected VIBs.

Continue reading

Minimum vSphere Privileges To Query VIBs On An ESXi Host

This was a recent question that was asked internally about the minimum privileges required to query VIBs on an ESXi host. The request was for a custom script that was developed for compliance check and the customer was looking to create a custom vSphere role to minimize the privileges needed to perform the task. Since I did not know the answer, it was off to the lab for some testing. Through the process of elimination, it turns out the only privilege that is required for querying VIBs on an ESXi host is Global.Settings.

In the example above, I created a custom vCenter Server Role called VIBQuery and enabled the Global.Settings privilege and assigned the role to a user. The custom role can be created on both a vCenter Server as well as directly on an ESXi host. By using vCenter Server, one can benefit from centralize management of user access to all ESXi hosts in the environment.

To confirm that our user assigned to the new role can query VIBs on an ESXi host, we will  run the following ESXCLI command:

esxcli --server [VC-SERVER] --vihost [ESXi-SERVER] --username [USER] software vib list

We can also confirm that we can do the same directly on the ESXi host by running the following ESXCLI command:

esxcli --server [ESXi-SERVER] --username [USER] software vib list

When granting access to your vSphere infrastructure, you should always use good security practices by leveraging RBAC model (Role-Base Access Control) and restrict the amount permission a user has access to.

UPDATE: In addition to using ESXCLI, there are two additional options to query installed VIBs on an ESXi host as noted by the comment below by Mike.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

Cleanup vCloud Director Agent from Host with Running VMs

Typically, unpreparing a host in vCloud Director is fairly straightforward and works without issue. In the rare occasion it doesn’t work, there are posted workarounds for manually removing the vcloud-agent from the vSphere Host through the esxcli. Well, what about the even rarer chance you need to remove the vCloud Director agent from a vSphere Host while it still has workloads (VMs) running on it?

Continue reading

Useful VXLAN commands in ESXCLI 5.1

Recently I have been doing some work with VXLAN with my colleagues Venky Deshpande who is responsible for vCloud Networking and Ranga Maddipudi who is responsible for vCloud Security within our technical marketing team (I call them the vCloud Networking & Security Duo). While working in our lab, I came across several VXLAN commands in ESXCLI that I thought might come in handy when configuring or troubleshooting a VMware VXLAN environment. The new VXLAN namespace in ESXCLI 5.1 provides both VXLAN configuration details as well network statistics for an individual ESXi host.

Continue reading

Network Troubleshooting Using ESXCLI 5.1

When it comes to network troubleshooting in an ESXi host, there are various types of information that can be useful to a vSphere administrator such as basic information like a virtual machine’s IP Addresses, MAC Addresses, Uplink ports, Port ID, etc. to the network statistics view in the [r]esxtop command-line utility. However, all of this useful information today is spread across multiple tools and this can be challenging for a vSphere administrator when needing to quickly retrieve this data while troubleshooting an issue.

With the release of vSphere 5.1, the network namespace in ESXCLI has been enhanced to include a comprehensive set network statistics at various points in the virtual network. This enables a vSphere administrator to easily get an overall status of the vSphere network as well as provide the ability to drill down further for troubleshooting.

Continue reading

Tagging VMkernel Traffic Types Using ESXCLI 5.1

In earlier releases of ESXi, a VMkernel interface could transport three types of traffic: Management, vMotion and Fault Tolerance. To enable a particular traffic type, one would use either the vSphere Web/C# Client or the vSphere API. Some of you may have recalled using an undocumented command-line tool called vim-cmd in the ESXi Shell to enable vMotion and Fault Tolerance traffic. An issue with this tool is it does not support the Management traffic type. This made it a challenge to completely automate the provisioning of VMkernel interfaces from a scripted installation (kickstart) perspective and required the use of remote CLI/APIs to enable the Management traffic type.

Luckily in vSphere 5.1, we now have an easy way of tagging these various traffics types for a VMkernel interface using the new ESXCLI 5.1.

Continue reading

Network Core Dump Collector Check with ESXCLI 5.1

The ESXi Dump Collector service is an extremely useful feature to have enabled, this is especially important in a stateless environment where there may not be a local disk for storing core dumps generated during a host failure. By configuring ESXi hosts to send it’s core dumps to a remote vSphere Dump Collector, it still allows you to collect core dumps which will help VMware Support analyze and determine the root cause of the failure.

In addition, by leveraging the vSphere Dump Collector, it allows you centrally manage core dump collection in your vSphere environment in the rare occasion a host may generate a PSOD (Purple Screen of Death) without having to go out to the host and manually copying the core dump file. A potential challenge that may come up when configuring the ESXi Dump Collector service is how do you go about validating the configuration is correct and that everything will work if a host crashes?
Continue reading

Configuring SNMP v1/v2c/v3 Using ESXCLI 5.1

In previous releases of ESXi, only SNMP v1 and v2c was supported on the host. With the latest release of ESXi 5.1, we now have added support for SNMPv3 which provides additional security when collecting data from the ESXi host. You also have the ability to specify where to source hardware alerts using either IPMI sensors (as used by previous release of ESXi) or CIM indicators. You can also filter out specific traps you do not wish to send to your SNMP management server.

In addition to SNMPv3 support, we also now have an ESXCLI equivalent command to the old vicfg-snmp command. This means that you no longer have to use multiple commands to configure your ESXI hosts and can standardize on just using ESXCLI for all your host level configurations.

Continue reading

Introducing the VIB Author Fling

I’m very excited to announce the new vibauthor fling.  This fling is hot off the press and provides the capability to create custom vSphere Installation Bundles (VIBs).  Prior to this fling the VIB authoring tools were only available to VMware partners, this fling now extends this capability to everyone.

There are a couple of use cases for creating custom VIBs.  For example, if you are using Auto Deploy and you need to add a custom firewall rule to your host, or you need to make a configuration change that can’t be made using Host Profiles.

One word of caution however, the ability to create custom VIBs does come with some responsibility.  If you plan to create your own VIBs here are a few things to keep in mind:

  1. VIBs provided by VMware and trusted partners are digitally signed, these digital signatures ensure the integrity of the VIB.  Custom VIBs are not digitally signed.  Be careful when adding unsigned VIBs to you ESXi hosts as you have no way of vouching for the integrity of the software being installed.
  2. Before adding a custom VIB you will need to set your host’s acceptance level to “Community Supported”.   When running at the community supported acceptance level it’s important to understand that VMware support may ask you to remove any custom VIBs.   Here’s the formal disclaimer:

IMPORTANT If you add a Community Supported VIB to an ESXi host, you must first change the host’s acceptance level to Community Supported. If you encounter problems with an ESXi host that is at the CommunitySupported acceptance level, VMware Support might ask you to remove the custom VIB, as outlined in the support policies:”


If you are not familiar with VIBs I recommend you start with a quick review of this blog: http://blogs.vmware.com/esxi/2011/09/whats-in-a-vib.html

With that, I know several folks have been chomping at the bit to create their own custom VIBs so I’ve attached a short tutorial that shows how to use the vibauthor tool to create a  VIB to add a custom firewall rule.



Identifying Non-Default Advanced & Kernel Settings Using ESXCLI 5.1

I recently came across a very cool tidbit from one of our GSS Engineers Daniel de Sao Jose about a new option in ESXCLI 5.1 which allows you to list out all ESXi advanced and kernel settings that have non-default values configured. This can come in handy when you are troubleshooting and trying to find out what advanced settings were changed on a host or if you need to capture the list of changes for documentation purposes or for creating a script to apply to other hosts.

To list all ESXi Advanced Settings, you would run the following command (4.x & 5.x):

esxcli system settings list

To list only ESXi Advanced Settings that have changed from the system defaults, there is now a new option called [ --delta | -d ] in ESXCLI 5.1 which can be specified with the list operation (ESXi 5.1 only):

esxcli system settings advanced list -d

Path: /UserVars/SuppressShellWarning
Type: integer
Int Value: 1
Default Int Value: 0
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: Don’t show warning for enabled local and remote shell access

In the example above, we can see that the /UserVars/SuppressShellWarning setting has been changed from the system default of 0 (false) to 1 (true).

To list all ESXi Kernel Settings, you would run the following command (4.x & 5.x):

esxcli system settings advanced kernel list

To list only ESXi Kernel Settings that have changed from the system defaults, there is also a new option called [ --delta | -d ] in ESXCLI 5.1 which can be specified with the list operation (ESXi 5.1 only):

esxcli system settings advanced kernel list -d

Name                  Type   Description                 Configured  Runtime  Default
—————        —-    ————————-  ———-     ——-      ——-
smallFontForTTY  Bool  Use 50-line font for tty.  true           FALSE     FALSE

In the example above, we can see that the smallFontForTTY setting has been changed from the system default of false to true.

The next time you are stuck wondering what ESXi Advanced or Kernel settings you might have changed, you now have a very easy way of figuring out the specific settings and their configured value and defaults.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw