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 (11/4) - 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

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:

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":

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 Low Power
3 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!

8 thoughts on “Configuring ESXi Power Management Policy Using the CLI

    • @Nitro,

      Thanks, but the key was “kickstart” script, meaning no remote commands. I definitely could have written a simple script leveraging the API :)

    • Hi William,
      The command works fine in scripts(KS) but after rebooting the server the currentPolicy is reversed to “Balanced”.

      Regards Denis

  1. Hi William,
    It does not help!
    It’s work only when you make the change trough the “vSphere client”.
    Do we have a another way to set it in our scripts?

    Best Regards

  2. Hi
    Thanks for this ticket!
    In general, people are talking about setting a specific power management policy. Please, is it possible to retrieve the current processor frequency at runtime in VMware?With other hypervisors, they generally offer a “command”/ way to do it!
    Thanks for your reply!!

  3. Hi William

    Thanks for this. As mentioned by a previous commenter the setting does not survive a host reboot when configured this way, even when running the autobackup script afterwards. Has anything changed with 5.1 Update 1? Seems like a prime candidate for a fire-and-forget line in a kix build script if it could be made to persist!


Thanks for the comment!