CPU and Memory Limit enforcement for vCloud Director

CPU and Memory Limit enforcement for vCloud Director


vCenter Orchestrator provides a large library of workflows and actions out of the box. This library grows with each new plugin that gets installed. As a result, it becomes easier to build very powerful workflows with little to no knowledge of an API. This document will focus on a package of custom workflows built using plug-ins, library items, and additional scripting.

This package allows a vCloud Director system administrator to limit the maximum CPU and Memory of Virtual Machines deployed in vCloudDirector. The solution utilizes the Deploy vApp blocking task to prevent any VM from powering on if it exceeds the admin-specified limits.

The solution's configuration options include the ability to:

  • Specify the maximum CPU count for any VM to be powered on
  • Specify the maximum Memory (GB) for any VM to be powered on
  • Specify whether or not to automatically reconfigure the VM's CPU and Memory to the specified limit if the user-specified value exceeds the limit
  • Specify a failure message to be shown in vCloud Director if auto reconfigure is not enabled

Disclaimer: These sample workflows are provided AS IS and are not production quality. Use at your own risk. Feel free to Duplicate and Modify and expand and share your contribution.


These are the instructions to have the sample workflows working


  • vCenter Orchestrator 5.1 installed and configured
  • AMQP plug-in installed
  • vCloud Director 5.1 plug-in for vCenter Orchestrator installed and configured using the SYSTEM org
  • AMQP server
  • A working vCloud Director 5.1 environment configured to use an AMQP server for notficiations

vCloud Director

The blocking task you enable in this section will allow vCenter Orchestrator to subscribe to notifications sent by the task and automatically resume, abort, or fail the operation as needed.

  • Configure blocking tasks settings with AMQP server info and Test the AMQP Connection
  • Check the box to enable the "Start vApp (Deploy from API)" blocking task

vCenter Orchestrator

  • Import package in vCenter Orchestrator       
    • Start vCenter Orchestrator Client and login as an administrator
    • Import the package com.vmware.coe.vcd51.limits.package
  • Configure the solution settings
    • Run the workflow "Limits Customization Config"
  • Create AMQP Subscription
    • Start the "Create a vCloud Director notification subscription" workflow               
      • Provide an appropriate Queue name (ie: Limit Deploy vApp or VM)
      • Choose the vCloud Director Host
      • Specify the AMQP password used by the vCloud Director server to communicate to the AMQP server
      • Specify whether or not to create a broker
      • Click Next until you get to step “2d” Blocking Task Operation Type
      • Select “Yes”, then choose the “Vapp Deploy” blocking task
      • Click Next
      • For “Event Type”: select “Yes”, then choose the option for “Create”
      • Leave “Entity type” as “No”
      • For “Workflow”: Choose the “Limit Deploy vApp” workflow
      • Click “Submit”
  • Start the listener workflow or policy: In earlier versions of the AMQP plug-in, there was an issue where the policy would not kick off a workflow. As a work-around, the Subscription Listener workflow was developed       
    • If using Listener workflow: Run the “Start a subscription listener workflow”, choose the Subscription that was just created and click Submit
    • If using Policy: Run the “Create a vCloud Director notification policy” workflow, choose the Subscription that was just created, click Yes for “Start right away” and Yes for “Auto start when vCO server is restarted”, then click Submit


  • Go to vCD and attempt to Start a VM or vApp that contains VMs that exceed the CPU and/or Memory limits specified
  • Confirm that the VM(s) that were just started are at or below the limits specified
  • Check the “Limit Deploy vApp” workflow execution log

Thanks Burke... I keep meaning to use the blocking tasks in our environment but just haven't quite gotten around to implementing any yet.  This looks like a useful one!

Hi Burke,

I'm trying this setup against vCloud 5.5

It looks like the AMQP object does not exists since i get validation error at "Create a vCloud Director notification subscription" wf.

Also my concern is that if I follow that after this change all the new vApp provision will rely upon VCO which would become a critical point of failure, am I right?

Re-Check the Pre-requisits above - you must have the AMQP Plug-in installed. The errors you have shared in that screenshot indicate that either: you have not installed the plug-in and restarted vCO Server service OR you installed the plug-in, but have not yet restarted the vCO Server Service so that the new types are recognized.

As for vCO being a point of failure, this can be avoided by setting up vCO as a cluster behind a load balancer Smiley Wink Additionally, you could optionally set a timeout on your blocking task with a default action that would permit the action to take place rather than waiting indefinitely or failing due to an AMQP message not being processed by vCO. Also, even if vCO were to become unavailable, a Cloud Administrator could release the blocked task via the vCD UI.

Thanks, do you know it this wf library is working on vcloud 5.5 as well?

I have not personally tested this package against 5.5 since nearly none of my work these days deals with vCD. As long as you are using the most current AMQP plug-in, have Admin access to vCD for blocking tasks, and current vCO, I don't see any reason why it wouldn't work. I know that the Infoblox folks were successful with vCD 5.5 and the AMQP plug-in for some of their work so this should work as well.

Version history
Revision #:
1 of 1
Last update:
‎02-08-2013 05:06 AM
Updated by: