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

Tag Archives: esxcli

Minimum vSphere Privileges To Query VIBs On An ESXi Host

Posted on by
2

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

Posted on by
3

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

Posted on by
6

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

Posted on by
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

Posted on by
5

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

Posted on by
2

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

Posted on by
9

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

Posted on by
1

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.

Enjoy!

vibauthor-how-to-v0.1

Identifying Non-Default Advanced & Kernel Settings Using ESXCLI 5.1

Posted on by
3

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

Configuring Multiple Syslog Servers for ESXi 5

Posted on by
1

By William Lam, Sr. Technical Marketing Engineer

There were some questions on twitter last night about the number of syslog servers that can be configured for an ESXi host and the answer depends on the version of ESXi you are running. With ESXi 4.x, you could only forward to a single syslog server, but with ESXi 5.0 you can now forward to multiple syslog servers which is great for providing redundancy when shipping your logs. In addition to supporting multiple syslog servers, with the release of ESXi 5.0, you can specify different transport protocols: UDP (default), TCP and SSL.

You can configure the syslog servers using the vSphere Client, but if you need to configure this across several hundred hosts you will probably want to automate this using one of the following methods:

Though it may not have been clear in our documentation that you can now specify multiple syslog servers in ESXi 5.0, here is a quick example on how to configure multiple syslog servers using the remote ESXCLI:

1. Enable ESXi Firewall

You will need to enable the syslog rule in the ESXi firewall (only in ESXi 5.0):

$ esxcli –server esxi1 –username root network firewall ruleset set –enabled yes –ruleset-id syslog

Note: The default syslog ruleset allows UDP/TCP 514 and TCP 1514, if you choose to use a different port you will need to update firewall ruleset.

2. Configure Syslog Servers

To specify more than one syslog server, you will need to separate them using a comma. By default, the host will use UDP protocol and port 514. However, you can specify tcp or ssl as the protocol to be used as well as the port number:

$ esxcli –server esxi1 –username root system syslog config set –loghost 10.20.182.46,tcp://10.20.182.50:514,ssl://10.20.182.52:1514

Note: You can also authenticate against vCenter Server by specifying the –vihost parameter

3. Reload Syslog Configuration

For the syslog configuration to take effect, you will need to reload the configuration:

$ esxcli –server esxi1 –username root system syslog reload

You can easily create shell script and using a “for” loop to execute the preceding 3 commands across multiple hosts. Here is a script called configSyslog.sh that accepts three parameters: username, file that includes list of all ESXi hosts seperated by a newline and syslog servers (same syntax as ESXCLI). You will need to edit the script and specify the password for your ESXi host before executing the script.

Disclaimer: This script is provided for informational/educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

Here is a sample execution:
Screen shot 2012-04-03 at 9.00.46 PM

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