Follow up on ESXCLI with PowerCLI

In a previous post here, Applying Patches to ESXi 5 with the help of PowerCLI, I showed how simple it was to call ESXCLI that is part of vCLI through a PowerCLI script, but did you know that ESXCLI is also part of PowerCLI?

ESXCLI is actually part of the VMware API for an ESXi host. Note: While the API for vSphere 4 also had ESXCLI included, it is much more robust with vSphere 5. Most if not all of the commands I show will only work against vSphere 5. PowerCLI has a cmdlet called Get-EsxCli that can be used when connected directly to an ESXi host.

First, connect to an ESXi host through PowerCLI.

Connect-VIServer

Next, lets run the Get-EsxCli cmdlet.

$esxcli = Get-EsxCli

Now we have our ESXCLI object. Now what can we do with it? Well basically anything that you would do with ESXCLI through vCLI or local to the ESXi host. So let’s say our host is running on a Cisco UCS system, and we wanted to verify the enic driver version loaded on the host. We could issue the following command to view the driver version.

$esxcli.system.module.get("enic").version

Now, to follow-up on the previous post, we could use the $esxcli object obtained through PowerCLI to issue the commands to view the vibs on the host and apply vibs to the host in the same manor that we were calling ESXCLI before. If we wanted to see all the VIBs installed on a host, we can issue the following command to give us the name, vendor, and version of all VIBs installed on the host in formatted table output.

$esxcli.software.vib.list() | ft Name,Vendor,Version

Let’s look at the example from the previous blog post. Here we set the patch name and location of the patch on the datastore that the host could access.

$patch = "PatchFile.zip" #patch file we want to apply
$datastore = "datastore1" #datastore where we want to store the patch
$remoteLocation = "/vmfs/volumes/" + $datastore + "/" + $patch #remote location of patch

Now once the patch is on the datastore, which I covered in the previous post, you could install it with the command

$esxcli.software.vib.install($remoteLocation)

Here is another tip as well for PowerShell and PowerCLI. If you are unsure of the arguments that a function takes, such as the command above, you can run

$esxcli.software.vib.install

and the command will output some useful data about the method. One particular useful output is Value. This tells you what the expected value type will be given the proper inputs. For the above command, you can see the output as follows:

Hopefully this proves useful to someone.

Advertisement

Interesting troubleshooting with Cisco Nexus 1000V

Today, I assisted a couple of coworkers with troubleshooting a VLAN issue. The VLAN had been added to all the appropriate devices, but the VM was still unable to ping the gateway. As our troubleshooting progressed from device to device, we noticed that although the uplink port profile on the Cisco Nexus 1000V was configured correctly, the VEM on the host was not updating with the changes. This could be seen by running

vemcmd show port vlans

on the host itself. As we dug through the running config of the Cisco Nexus 1000V, we noticed that besides the port channels inheriting the uplink port profile, a VLAN was manually added to all port channels. It turns out this is a simple fix (after many hours of troubleshooting). By issuing the command

default switchport trunk allowed vlan

to all the port channels, the port channels started inheriting the VLANs from the port profile again. We verified this by adding/removing a VLAN and the port profile updated as expected. We are not sure when this VLAN was added this way, but it did give us a bit of a headache.

So remember when working on the Cisco Nexus 1000V, add/remove VLANs via the port profiles, not from the port channels or ports themselves.