Picture this – you are working away developing a PowerCLI script that is performing multiple actions – you have it just about complete when you come to a roadblock. After frantically googling around you find out that this one task you are trying to perform simply cannot be done through PowerShell, yet you know it exists within the local ESXi esxcli command namespace! This has happened multiple times to me and thankfully, there is a way to access ESXi’s esxcli command namespace without having to leave the comforts of the PowerShell Console.
Chances are that if you have been working at all with ESXi you are familiar with the esxcli command – but for those that aren’t let’s take a quick look at what exactly it does.
Esxcli is VMware’s answer to doing almost anything locally within the ESXi shell. Whether you are looking to install software, configuring vSwitches, setting up firewalls or multipathing storage esxcli can do it. esxcli works much like a command line interface might on a network switch, where you start by entering an element and then continue to break down that element into different sub-elements or functions. All esxcli commands will begin with esxcli <namespace> ….. Before we move into how we get access to the local command let’s first take a look at what namespaces are available to us through esxcli within ESXi 6.5.
- device – commands related to device management (IE querying drivers and view aliases)
- elxnet – commands related to managing the elxnet nic.
- esxcli – used to gain information and metadata around all of the esxcli commands and namespaces
- fcoe – commands to manage and setup Fibre Channel over Ethernet
- graphics – commands related to the graphics capabilities of our devices, hosts, and VMs.
- hardware – commands related to the hardware installed on our host.
- iscsi – commands used to setup, configure, and troubleshoot iSCSI adapters and targets.
- network – commands used to create, configure everything there is about vSphere networking
- nvme – commands related to the NVMe driver extensions
- rdma – Commands pertaining to Remote Direct Memory Access on the host.
- sched – commands related to scheduling related components within the vmkernel.
- software – commands used to install and remove software components on our hosts.
- storage – commands used to create, configure, and manage our storage.
- system – commands for configuring the core system.
- vm – commands used to control select virtual machine operations
- vsan – commands related to setup and configure VSAN.
So, as you can see esxcli covers off just about function we can think of that we might need to perform on our ESXi hosts – but how do we gain access to this local command via PowerShell or PowerCLI.
Get-EsxCli
As you may have guessed by the above heading the cmdlet we use to interact with the hosts esxcli command is Get-EsxCli. VMware has released a couple versions of this cmdlet, however, have left the syntax the same for the original as to not break any preexisting scripts which may utilize it so to get the newest functionality we can see, as shown below, we need to pass the –V2 parameter to the cmdlet
|
1 |
$esxcli = Get-EsxCli –VMHost (Get-VMHost “HostName”) –V2 |
Once we have established a connection to our host we can then simply access the esxcli namespaces as if they were properties of the $esxcli object. Below, just by outputting $esxcli we can see the exact same namespaces as we discussed above.
Running esxcli through the local commands on the host and through PowerShell is somewhat similar although there are some differences. Take for instance the command to list the NICs installed within a host. To do so running esxcli locally we would run the following command
|
1 |
esxcli network nics list |
And doing the same thing through PowerShell looks as follows
|
1 |
$esxcli.network.nics.list.invoke() |
And at any time if you need help figuring out the syntax for the PowerShell version, we can simply just hit <enter> between elements. Below we can see what appears after we execute just the “.list” command that in order to fully execute the command we need to add the “invoke()” function.
It should be noted that by accessing esxcli through PowerShell we get all of the goodness of piped commands and chaining other PowerShell cmdlets as well, for instance, we can filter out our results of our storage device listing as follows…
|
1 |
$esxcli.storage.nmp.device.list.invoke() | Where-Object {$_.Device -eq "naa.690b11c03d2a8c00192501a904f58e42" } |
As you can see, accessing esxcli from PowerCLI is starting to become a very valuable tool…
But what about parameters?
Simply listing out information is simple within both esxcli and PowerCLI, but when we want to start actually changing things then parameters and arguments come into play pretty quick. In esxcli, these are the traditional “-“ items that we pass to our command. In PowerShell, things are a little bit different. Sometimes it’s easier just to see how it’s accomplished so let’s look at the task of enabling a rule set in esxcli and in PowerShell so we can see the differences…
To do this within esxcli we would…
|
1 |
esxcli network firewall ruleset set –r sshClient –e true |
Within PowerShell it’s a little bit different – we must first build our argument set and then pass it to the invoke method as shown below
|
1 2 3 4 5 6 7 |
$arguments = $esxcli.network.firewall.ruleset.set.CreateArgs() $arguments.enabled = $true $arguments.rulesetid = “sshClient” $esxcli.network.firewall.ruleset.set.invoke($arguments) |
And below we can see by simply writing out our $arguments variable we are able to see just what arguments are available and what their associated types are…
With PowerCLI supporting esxcli commands we now have the ability to script just about every possible scenario we can think of involving our ESXi hosts. No more spawning putty sessions or having to write expect scripts to get into the host to run local commands. Also, combining the information we can output from esxcli with the Export-CSV functionality of PowerShell we have a pretty solid start to pulling and displaying any type of reporting information we need to. If you want to learn more about the Get-EsxCli commandlet VMware has some fairly in-depth documentation around everything it can do here! Happy scripting and thanks for reading!
