Home > vSphere API > A Powerless Feature in VMware vSphere

A Powerless Feature in VMware vSphere

Distributed Power Management (DPM) is a powerful (powerless, really) feature can reduce host power consumption in a DRS cluster. It works in either manual mode or automatic mode only when DRS is enabled. DPM can place idle hosts into standby mode, or awaken them from standby when more resources are needed.

Like most of the features in vSphere, you can manage them with the APIs. A recent question at the open source vSphere Java API forum asks how to get hold of the DpmBehavior data object. This seems easy but may take a while to figure out because of the complicated structure and a little history there. Although this article is mainly about DPM, the related tips apply to DRS as well.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

Reading DPM Behaviors

Let’s first show how to get hold of this:

  1. Get hold of the hostFolder property of a Datacenter managed object.
  2. Dig down the folder’s childEntity property for a managed entity typed ClusterComputeResource. Note: here comes the first confusion. The element in the childEntity array can be ComputeResource or its subtype ClusterComputeResource. You have to check the element type and then cast the type only for these ClusterComputeResource elements. Remember, DPM is a cluster feature and tied with ClusterComputeResource.
  3. From a ClusterComputeResource object, dig down to its configurationEx property, which is literally typed as ComputeResourceConfigInfo. But if it’s a ClusterComputeResource, it’s really the subtype of ComputeResourceConfigInfo: ClusterConfigInfoEx. So you have to cast it before you can see the properties defined in ClusterConfigInfoEx. This is the second confusion you may get into.
  4. Inside the ClusterConfigInfoEx, check the dpmConfigInfo which includes defaultDpmBehavior property typed DpmBehavior which is an enumeration type with two possible values: automated, or manual.

In the step 3, you may have a third confusion. The ClusterComputeResource once defined a property called configuration, but immediately deprecated in 2.5. You may expect configuration is the one that holds cluster related information because it’s an additional property from the super type ComputeResource. In this case, you need to read API reference and explore by yourself a little.

That is not the end of the story yet. An individual host may opt in or out the DPM. In this case, you want to read dpmHostConfig property of the ClusterConfigInfoEx (See step 4). The dpmHostConfig property is an array of ClusterDpmHostConfigInfo, from which you can tell whether a host has a special setting with DPM. If yes, this setting overrides the default; otherwise use the default.

Change DPM Behavior

After getting the existing DPM setting, you may want to change it. The related API is

reconfigureComputeResource_Task(ComputeResourceConfigSpec spec, boolean modify); 

The second parameter is a boolean which applies incremental changes to the configuration when true; or overwrites everything otherwise. Normally you should use true unless you want to repeat everything or accept default settings for all unspecified settings.

The first parameter is a little tricky here. The ComputeResourceConfigSpec is very simple with only one property vmSwapPlacement. You may wonder how to use this for cluster related settings. It turns out ComputeResourceConfigSpec has a subtype called ClusterConfigSpecEx which has extra properties for you to specify cluster related settings including DPM. As you read earlier, DPM setting has both default for whole cluster and individual hosts. They can be configured with dpmConfig (ClusterDpmConfigInfo) and dpmHostConfigSpec (ClusterDpmHostConfigSpec) respectively. You can figure out what to provide after reading the API reference.

Once this trick is understood, the rest of API should be straightforward.

  1. No comments yet.
  1. No trackbacks yet.