WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Configuring ESXi Power Management Policy Using the CLI

08.18.2012 by William Lam // 12 Comments

An interesting question on the VMTN forum caught my eye today, which was around configuring ESXi's Power Management Policy using the command-line via a kickstart script. I found this question to be interesting as I never had to tweak this configuration and was curious myself to see how you might be able to perform this via the command-line as I never recall seeing a command relating to the power management settings.

After a few minutes of digging, I found that the standard set of CLI's such as ESXCLI, vim-cmd, etc. do not provide a way to configure ESXi's power management settings but did find it was possible using my other favorite "not officially supported" CLI called vsish. Now, you can of course create a remote script using the vSphere API to configure this setting, but if you are looking to modify this within a kickstart script, this is route you will want to take.

UPDATE (01/12/15) - I just found out today from Engineering that it is possible to configure ESXi power management policy using ESXCLI. Though the parameters are currently set to hidden, you can use the following command to set the appropriate policy based on your enviornment.

esxcli system settings advanced set --option=/Power/CpuPolicy --string-value="High Performance"

UPDATE (11/04/14) - It turns out configuration changes made directly through vsish do not persist after a reboot, this might be problematic for most of you 😉 Luckily, Alan Castonguay who works in our GSS organization reached out and created a nice pyvmomi (vSphere SDK or Python) script that can be executed in the ESXi shell and of course it can easily be integrated into a Kickstart script. I have tested his sample script to verify its functionality and have also checked it into my Github repository so that others can benefit from. You can download the script which I have named configure_esxi_power_policy.py

If you run the script without any arguments, it will display the current power policy that has been enabled as seen in the screenshot below:

configure-esx-power-policy-0
To change the policy, you will need to specify the "shortName" power policy, in this example I want to change it from "static" to "low":

configure-esx-power-policy-1
To check whether your ESXi host supports power management, run the following command:

~ # vsish -e get /power/hardwareSupport
Hardware power management support {
CPU power management:Enhanced Intel SpeedStep(R)
Memory power management:Not available
}

To view the current power management setting, run the following command:

~ # vsish -e get /power/currentPolicy
Host power management policy {
ID: 2
Short name:dynamic
Long name:Balanced
Description:Reduce energy consumption with minimal performance compromise
}

Just like the vSphere Client, you have 4 options which maps to the "ID" property as seen above. You can get more details by querying each of the policy (1-4), here is an example:

~ # vsish -e get /power/policy/1
Host power management policy {
ID: 1
Short name:static
Long name:High Performance
Description:Do not use any power management features
}

Here's a quick table that maps the policy ID to power management policy which is the same order as shown in the vSphere Client:

Policy ID Power Management Policy
1 High Performance
2 Balanced
3 Lower Power
4 Custom

To change the power management policy, run the following command:

~ # vsish -e set /power/currentPolicy 1

So now you can integrate power management settings in your ESXi kickstart script for automated deployment and configurations!

Categories // Uncategorized Tags // cli, power management, power policy, vsish

New vSphere 4.1 CLI Utilities Marketing Did Not Tell You About Part 1

07.13.2010 by William Lam // Leave a Comment

With the new release of vSphere 4.1, there are new additions to the CLI utilities that administrators can leverage for configurations and troubleshooting. Although, not all were treated equally from an announcement and documentation standpoint. 


Here are some of the new and/or subtle changes with the CLI utilities:

1. vmkfstools undocumented "-D" option now outputs to console along with an entry in /var/log/vmkernel, whereas in the past, to locate the entry within the vmkernel logs for identifying locked files by a particular host as documented in this article. 

Here is an example of the old version of vmkfstools and -D option:

Here is an example of the new version of vmkfstools and -D option:

 2. storageRM is a debugging utility for Storage I/O Control at the host level.


[root@esx4-1 ~]# /usr/lib/vmware/bin/storageRM -h

Default Values:
SleepTime: 4000
Threshold: 35
Gamma: 0.25
Beta-per-host: 4.00
LowerBound: 4
UpperBound: 64
Storage I/O Control-- This tool does flow control at the host
in order to maintain disk I/O latency close to a
threshold and queue sizes converge at values
proportional to the beta parameter.

The following histogram related options are available:
-a, --print the list of all luns, their latency threshold,
queue depths and if Storage I/O Controlis set/unset
-b, --Beta per host value
-d - put debugging info in the given file
-f, --force the run without checking version or checksum
-g, --defGamma value for use in control equation
-h, --help will print the usage
-l, --lower bound on the length of lun queue, (default 4)
-n, --no anomaly detection is done
-r, --reset issue queue for all luns to default
-s, --sleep time in ms for periodic execution
-t, --threshold on the latency (in ms), for rate control
-u, --upper bound on the length of lun queue (default 64)
-v, --debug log level value
storageRM Usage:
storageRM [options]

3. net-lbt is a debugging utility for the new Load-Based Teaming feature.

[root@esx4-1 ~]# /usr/lib/vmware/bin/net-lbt -h

Usage: [-d] [-t time] [-v] [-s threshold]
-d run in daemon mode
-t daemon sleep period in seconds, minimum 10 seconds
-v run with verbose logging
-s saturate threshold [10, 100], i.e. 60 for 60% of line rate

4. net-dvs is a debugging utility for Distributed vSwitch. 

[root@esx4-1 ~]# /usr/lib/vmware/bin/net-dvs -h

Warning: This is an unsupported command. Use at your own risk.
net-dvs -a [ -P maxPorts] switch_name
net-dvs -d switch_name
net-dvs [ -A | -D ] -p port switch_name
net-dvs [ -s name=value | -u name ] -p port switch_name
net-dvs -l [ switch_name ]
net-dvs -i (init database)
net-dvs [-S | -R | -G ]
net-dvs -T
net-dvs -v "vlanID[;t|p[0-7][;min-max,min-max...]]
net-dvs -V "primaryVID,secondaryVID,i|c|p;primaryVID,secondaryVID,i|c|p..."
net-dvs -m "sid;dname;snaplen;

[oiveld];encapvlan;wildcardsIn,wildcardsOut;dstPort1,dstPort2,...;srcInPort1,srcInport2,...;srcOutPort1,srcOutPort2,...;:sid2;dname2..."
net-dvs dvswitch -k "respool1_id;respool2_id;..."
net-dvs dvswitch -p dvport -K "respool1_id:shares:limit;respool2_id:shares:limit;..."
net-dvs dvswitch -p dvport -z "respool_id"
net-dvs dvswitch -j [activate|deactivate]
net-dvs -L uplink_name1[,uplink_name2,...] -t team_policy_type -p port switch_name
net-dvs dvswitch -H "red|yellow|green:some message" switch_name
net-dvs -o "depth,param|classname;depth,param|classname;... -p port|globalPropList switch_name
net-dvs --mtu mtu_value [-p dvport] switch_name
net-dvs --x 0|1 -p dvport switch_name
net-dvs --vlan vlanID -p dvport switch_name
net-dvs --reset -p dvport switch_name
net-dvs --cap cap_value -p dvport switch_name
net-dvs --states -p dvport switch_name

5. remoteDeviceConnect is a new utility that allows you to mount various remote devices including floppy and USB. 

/usr/lib/vmware/bin/remoteDeviceConnect: option requires an argument -- h

VMware remote Device Connect
Usage: /usr/lib/vmware/bin/remoteDeviceConnect OPTIONS filename
Options:
-h : hostname (localhost)
-p : Port to connect to (63079, 902 for authd)
-t : (Req.) cd-raw, cd-iso, cd-normal, cd-raw-ex, floppy
-d : (Req.) Device node to connect to (floppy0, ideX:Y)
-n : the VM's floppy drive number
-f : fileType
-A : use Authd to connect
-U : username for authd (your username)
-V : the VM to use. (NULL)
-P : password.
Examples:
remoteDeviceConnect -t floppy -d floppy0 -f device /dev/fd0
remoteDeviceConnect -t floppy -d floppy0 -f file image.flp
remoteDeviceConnect -t usb "path:2/1 vid:0x0547 pid:0x2131"

6. sensorD looks to be a debugging utility that can connect to an ipmi device.

[root@esx4-1 bin]# /usr/lib/vmware/bin/sensord

sensord: failed to open ipmi device: No such file or dir
sensord: unsupported hardware

7. statedumper looks to be a debugging utility for output information about the system and its states.

[root@esx4-1 bin]# /usr/lib/vmware/bin/statedumper -h

statedumper [-f filename] [-s off] [-e off] [-b] [-o] [-r] [-x]

The following options are supported:
-e - end dump at offset
-f - use filename rather than the default state.log
-o - output entry offsets
-r - output all registers, output 64 bits with -r64
-s - start dumping at offset
-b - filter on branch count, use -s and -e for start/end
-x - dump extra debug data

8. vmkeventd looks to be a utility for capturing VMkernel events

[root@esx4-1 bin]# /usr/lib/vmware/bin/vmkeventd -h

/usr/lib/vmware/bin/vmkeventd: invalid option -- h
Usage: /usr/lib/vmware/bin/vmkeventd [-d]

9. analyze-esx-init-boot.py looks like a debugging utility to analyze the COS boot up logs

[root@esx4-1 ~]# /usr/sbin/analyze-esx-init-boot.py -s -S /vmfs/volumes/datastore1/esxconsole-4c27dd75-a38d-5044-5670-005056927558/logs/sysboot.log -V /var/log/messages
ERROR: Could not find 'cpu 0: early measured tsc speed' in the log
This is one of the very first log messages after boot
POST boot times will not be relevant
Unable to find vsish. Please ensure that you have debugging tools installed and your PATH is correctly setup.
VMKernel: 0.0000 secs
POST Tests: 0.0000 secs
Init Scripts: 0.0000 secs

ESX Boot Time: 0.0000 secs
Hardware/BIOS: 0.0000 secs

Total Boot Time: 0.0000 secs

Serial port output was on

Categories // Uncategorized Tags // cli, vimsh, vSphere 4.1

New vSphere 4.1 CLI Utilities Marketing Did Not Tell You About Part 3

07.13.2010 by William Lam // Leave a Comment

Following part1 and part2 of new vSphere 4.1 CLI Utilities, here are some new vimsh commands:

For ESX use /usr/bin/vmware-vim-cmd
For ESXi use /bin/vim-cmd

1. vmsvc/power.suspendResume is used for vMotion and sVMotion tasks before switching over to the new VM.

[root@esx4-1 ~]# vmware-vim-cmd vmsvc/power.suspendResume
Insufficient arguments.
Usage: power.suspendResume vmid

Suspend & resume the specified virtual machine.

2. vmsvc/queryftcompat allows you to query a given Virtual Machine to check for Fault Tolerance compatibility.

[root@esx4-1 ~]# vmware-vim-cmd vmsvc/queryftcompat
Insufficient arguments.
Usage: queryftcompat vmid

Query FT compatibility for a VM.

3. vimsvc/auth/lockdown_is_enabled allows you to query if the host has the lockdown feature enabled, this is only applicable to ESXi.

~ # vim-cmd vimsvc/auth/lockdown_is_enabled
false

4. vimsvc/auth/lockdown_is_possible allows you to check if you can put the host into lockdown mode.

~ # vim-cmd vimsvc/auth/lockdown_is_possible
true

5. vimsvc/auth/lockdown_mode_enter allows you to enter lockdown mode on an ESXi host.

~ # vim-cmd vimsvc/auth/lockdown_mode_enter

6. vimsvc/auth/lockdown_mode_exit allows you to exit lockdown mode on an ESXi host.

~ # vim-cmd vimsvc/auth/lockdown_mode_exit

The next two commands refer to the following services which can also be configured using the vSphere Client:

7. hostsvc/start_local_tsm allows you to enable Local Tech Support Mode on an ESXi host.

~ # vim-cmd hostsvc/start_local_tsm

8. hostsvc/start_remote_tsm  allows you to enable Remote Tech Support Mode (SSH access) on an ESXi host.

~ # vim-cmd hostsvc/start_remote_tsm

9. hostsvc/stop_local_tsm allows you to disable Local Tech Support Mode on an ESXi host.

~ # vim-cmd hostsvc/stop_local_tsm

10. hostsvc/stop_remote_tsm allows you to disable Remote Tech Support Mode (SSH access) on an ESXi host.

~ # vim-cmd hostsvc/stop_remote_tsm

Categories // Uncategorized Tags // cli, vimsh, vSphere 4.1

  • « Previous Page
  • 1
  • 2
  • 3
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.0 Installer workaround for ESXi hosts with different vendor 06/19/2025
  • NVMe Tiering with AMD Ryzen CPU workaround for VCF 9.0 06/19/2025
  • vSAN ESA Disk & HCL Workaround for VCF 9.0 06/19/2025
  • Disable 10GbE NIC Pre-Check in the VCF 9.0 Installer 06/19/2025
  • Minimal resources for deploying VCF 9.0 in a Lab 06/18/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...