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

$esxcli = Get-EsxCli –VMHost (Get-VMHost “HostName”) –V2 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

esxcli network nics list 1 esxcli network nics list

And doing the same thing through PowerShell looks as follows

$esxcli.network.nics.list.invoke() 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…

$esxcli.storage.nmp.device.list.invoke() | Where-Object {$_.Device -eq "naa.690b11c03d2a8c00192501a904f58e42" } 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…

StarWind HyperConverged Appliance is a turnkey, entirely software-defined hyperconverged platform purpose-built for intensive virtualization workloads. Bringing the desired performance and reducing downtime, the solution can be deployed by organizations with limited budgets and IT team resources. Also, it requires only one onsite node to deliver HA for your applications that make the solution even more cost-efficient. Find out more about ➡ StarWind HyperConverged Appliance

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…

esxcli network firewall ruleset set –r sshClient –e true 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

$arguments = $esxcli.network.firewall.ruleset.set.CreateArgs() $arguments.enabled = $true $arguments.rulesetid = “sshClient” $esxcli.network.firewall.ruleset.set.invoke($arguments) 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!

Related materials:

Views All Time Views All Time 1 Views Today Views Today 7

Appreciate how useful this article was to you?

5 out of 5, based on 1 review 5 out of 5, based on 1 review

Loading... Loading...