VMware ESXi Command Line Cheat Sheet

Quick reference

Command help

esxcli --help

Help for a namespace

esxcli network ip --help

Host version and build

esxcli system version get

Legacy management shell

vim-cmd

Live performance

esxtop

Support bundle

vm-support

Two command families: esxcli is the structured, namespaced interface and is what you should reach for first. vim-cmd talks to hostd and still covers a few things esxcli does not, notably per-VM power operations and registering a VM. Both are on every ESXi host.

SSH is off by default: Enable it from the DCUI, from vCenter under Host > Configure > Services, or with vim-cmd hostsvc/enable_ssh followed by vim-cmd hostsvc/start_ssh if you already have a session. Turn it off again when you are done.

Host and hardware

Task	Command
ESXi version, build and update level	`esxcli system version get`
Hardware model and serial	`esxcli hardware platform get`
CPU summary	`esxcli hardware cpu global get`
Physical memory	`esxcli hardware memory get`
PCI devices	`esxcli hardware pci list`
Hardware clock	`esxcli hardware clock get`
Hostname	`esxcli system hostname get`
Host UUID	`esxcli system uuid get`
Running services	`esxcli system services list`
Local accounts	`esxcli system account list`
An advanced setting	`esxcli system settings advanced list -o /Net/TcpipHeapSize`
Change an advanced setting	`esxcli system settings advanced set -o /Net/TcpipHeapSize -i 32`

Maintenance mode, reboot and services

Task	Command
Is the host in maintenance mode	`esxcli system maintenanceMode get`
Enter maintenance mode	`esxcli system maintenanceMode set --enable true`
Leave maintenance mode	`esxcli system maintenanceMode set --enable false`
Enter maintenance mode (hostd)	`vim-cmd /hostsvc/maintenance_mode_enter`
Leave maintenance mode (hostd)	`vim-cmd /hostsvc/maintenance_mode_exit`
Reboot with a reason	`esxcli system shutdown reboot -d 10 -r "monthly patching"`
Power off with a reason	`esxcli system shutdown poweroff -d 10 -r "datacentre power work"`
Restart the management agent	`/etc/init.d/hostd restart`
Restart the vCenter agent	`/etc/init.d/vpxa restart`
Restart all management agents	`services.sh restart`
Syslog target	`esxcli system syslog config get`
Set a syslog target	`esxcli system syslog config set --loghost=udp://10.0.0.50:514` then `esxcli system syslog reload`

The reboot needs maintenance mode: esxcli system shutdown reboot refuses to run unless the host is already in maintenance mode. That is a safety feature, not an error to work around. The -d value is a delay in seconds and -r is a reason string that lands in the logs, so future you knows why the host went down.

Networking

Task	Command
Physical NICs, speed and link state	`esxcli network nic list`
Details for one NIC	`esxcli network nic get -n vmnic0`
VMkernel interfaces	`esxcli network ip interface list`
VMkernel IP addresses	`esxcli network ip interface ipv4 get`
Routing table	`esxcli network ip route ipv4 list`
DNS servers	`esxcli network ip dns server list`
ARP table	`esxcli network ip neighbor list`
Active connections	`esxcli network ip connection list`
Standard switches	`esxcli network vswitch standard list`
Standard port groups	`esxcli network vswitch standard portgroup list`
Distributed switches	`esxcli network vswitch dvs vmware list`
Firewall state	`esxcli network firewall get`
Firewall rulesets	`esxcli network firewall ruleset list`
Enable a ruleset	`esxcli network firewall ruleset set -r sshServer -e true`
Ping from the host	`esxcli network diag ping -H 10.0.0.1`
Ping from a specific VMkernel port	`vmkping -I vmk1 10.0.0.1`
Test a 9000 MTU path	`vmkping -d -s 8972 -I vmk1 10.0.0.1`

Why 8972: The payload has to leave room for a 28-byte IP and ICMP header inside a 9000-byte frame. -d sets do-not-fragment, so if this succeeds and a larger size fails, jumbo frames are configured end to end. This one command settles most vSAN and iSCSI MTU arguments.

Storage

Task	Command
Storage adapters	`esxcli storage core adapter list`
Rescan every adapter	`esxcli storage core adapter rescan --all`
Devices and LUNs	`esxcli storage core device list`
One device	`esxcli storage core device list -d naa.xxxx`
Paths to devices	`esxcli storage core path list`
Multipathing policy per device	`esxcli storage nmp device list`
SATP rules	`esxcli storage nmp satp list`
Set round robin on a device	`esxcli storage nmp device set -d naa.xxxx -P VMW_PSP_RR`
Mounted filesystems and free space	`esxcli storage filesystem list`
VMFS extents	`esxcli storage vmfs extent list`
Unresolved VMFS snapshots	`esxcli storage vmfs snapshot list`
iSCSI adapters	`esxcli iscsi adapter list`
Free space, human readable	`df -h`

After a LUN change: Presenting or resizing a LUN on the array does nothing until the host looks again. esxcli storage core adapter rescan --all is the host-side half of that operation, and it is the step most often missed when a new datastore does not appear.

Virtual machines from the host

Task	Command
List VMs with their IDs	`vim-cmd vmsvc/getallvms`
Power state of one VM	`vim-cmd vmsvc/power.getstate <vmid>`
Power on	`vim-cmd vmsvc/power.on <vmid>`
Guest shutdown	`vim-cmd vmsvc/power.shutdown <vmid>`
Hard power off	`vim-cmd vmsvc/power.off <vmid>`
VM summary	`vim-cmd vmsvc/get.summary <vmid>`
Snapshots of a VM	`vim-cmd vmsvc/snapshot.get <vmid>`
Reload a VM configuration	`vim-cmd vmsvc/reload <vmid>`
Register a VM from a vmx file	`vim-cmd solo/registervm /vmfs/volumes/ds01/web01/web01.vmx`
Unregister a VM	`vim-cmd vmsvc/unregistervm <vmid>`
Running VM worlds	`esxcli vm process list`
Kill a stuck VM, politely first	`esxcli vm process kill -t soft -w <WorldID>`
Then harder	`esxcli vm process kill -t hard -w <WorldID>`
Last resort	`esxcli vm process kill -t force -w <WorldID>`

Kill in that order: Always try soft first: it sends the equivalent of a clean power-off request. hard stops the world immediately, and force is only for a world that ignores both. Skipping straight to force on a database VM is how a consistent shutdown turns into a restore.

Patching, VIBs and drivers

Task	Command
Installed VIBs	`esxcli software vib list`
Find one VIB	`esxcli software vib list \| grep -i nvme`
Current image profile	`esxcli software profile get`
Profiles inside an offline bundle	`esxcli software sources profile list -d /vmfs/volumes/ds01/patches/bundle.zip`
Apply an update	`esxcli software profile update -p <profile-name> -d /vmfs/volumes/ds01/patches/bundle.zip`
Install a single driver VIB	`esxcli software vib install -v /vmfs/volumes/ds01/drivers/driver.vib`
Remove a VIB	`esxcli software vib remove -n <vib-name>`
Acceptance level	`esxcli software acceptance get`
Reboot after patching	`esxcli system shutdown reboot -r "apply patch"`

ESXi 8.0 Update 2 and later: Upgrading a host with esxcli software vib update or esxcli software vib install is no longer supported. Use esxcli software profile update with an offline bundle instead. On ESXi 7.0 both still work, which is why so many runbooks written for 7.0 fail on 8.0 U2.

update, not install: profile update applies newer content and leaves anything already newer alone. profile install overwrites the whole image profile and removes VIBs that are not in the bundle, including vendor drivers. Use update unless you deliberately want a clean image.

Logs and troubleshooting

What	Where
VMkernel, the first log to read	`/var/log/vmkernel.log`
Host management agent	`/var/log/hostd.log`
vCenter agent	`/var/log/vpxa.log`
VMkernel observations and alarms	`/var/log/vobd.log`
VMkernel warnings only	`/var/log/vmkwarning.log`
General syslog	`/var/log/syslog.log`
Per-VM log	`/vmfs/volumes/<datastore>/<vm>/vmware.log`
Follow a log live	`tail -f /var/log/vmkernel.log`
Search across logs	`grep -i "scsi" /var/log/vmkernel.log`
Live resource usage	`esxtop`
Collect a support bundle	`vm-support`

esxtop keys: Once esxtop is running, press c for CPU, m for memory, n for network, d for disk adapter, u for disk device and v for disk by VM. f chooses columns and q quits.

FAQ

esxcli or vim-cmd?

Reach for esxcli first. It is the supported, namespaced interface and its output is predictable. vim-cmd talks directly to hostd and remains the practical way to power a VM on or off from the host, to register a VM from its vmx file, and to enter maintenance mode when esxcli is unhappy.

Why does esxcli system shutdown reboot refuse to run?

The host is not in maintenance mode. Run esxcli system maintenanceMode set --enable true first, or use vCenter. This is deliberate: it stops a reboot from taking running VMs with it.

My patch command worked on ESXi 7 and fails on ESXi 8

From ESXi 8.0 Update 2, upgrading with esxcli software vib update or esxcli software vib install is no longer supported. Switch the runbook to esxcli software profile update -p <profile> -d <bundle.zip>. Single driver VIBs can still be installed with the vib commands.

A VM will not power off from vCenter

Find its world ID with esxcli vm process list, then esxcli vm process kill -t soft -w <WorldID>. Escalate to hard and only then to force. Check vmware.log in the VM folder afterwards, because a VM that needs killing usually leaves a reason there.

A new LUN does not show up

Rescan the host with esxcli storage core adapter rescan --all, then check esxcli storage core device list. If the device appears but the datastore does not, look at esxcli storage vmfs snapshot list — a LUN copy with an existing VMFS signature will not mount until it is resignatured.

Should I run these on a host managed by vCenter?

Read-only commands are fine at any time. For anything that changes state, prefer vCenter or PowerCLI so the change is recorded and DRS and HA stay aware of it. Direct host commands are for when vCenter cannot reach the host, or for the handful of operations that only exist there.