Understanding Retirement with Automation & Control Policies

We are in the process of upgrading to CloudForms v3 and have some questions about retirements of VMs.

We are tagging our VMs to ensure we meet a variety of BU requirements

  1. lifecycle tag to define if a VM is a full retirement (immediate) or is a soft retirement (powered down for X days)
  2. prov_scope tag to ensure we know which business workflow created the VM
  3. ipam_path tag to ensure we get the correct IPAM DB to release the IP/hostname

We use a single VMRetirement State Machine and we have created instances based on the user/workflow AD group.
We created an operations button of “Retire VM” which calls the VMRetirement State Machine and this works great.

But here are my issues, challenges and questions.

  1. If we are looking at the VM and select the default “Lifecycle=>Retire this VM”, we are not seeing the expected behavior of it hitting the Retirement State Machine. The automation.log files do not record anything related to a retirement. It appears the core code flips the :retired bit to true and sets the retirement day as today. How can I force the “Retire this VM” button to kick off the retirement automation workflow?

  2. On a similar note, if I am selecting at multiple VMs and click the “Lifecycle=>Retire these items”, how do I force each of these to the Retirement State Machine?

  3. For the retirement policy in Control, how do we force it to use the VMRetirement SM in the Automation module? I see retirement messages in policy.log but it doesn’t seem to be using our customized automation retirement code.


VM retirement by default only powers off the VM and marks it as retired which is what you are seeing.

To have VM retirement invoke your automate workflow you need to:

  1. Create a VM Retired policy that will “Raise Automation Event”
  2. Add a new policy profile, VM Retirement, and included the VM Retired policy.
  3. Apply the policy to the Providers you want to be effected by this policy.

You should now see the vm_retired event being raised in the automation.log.

Thank you for your reply. We did ultimately figure out what was missing and it was same as step #3 of your reply. We now see everything we expect in the automation log.