vRealize AutomationDuring the vRealize Automation life cycle of an item it passes various states. The life cycle of a virtual machine in vRealize Automation is made up of the so called Master Workflow.

The Master Workflow is a collection of the following six top level workflow states:

  1. Request State;
  2. Approval State;
  3. Provision State;
  4. Manage State;
  5. Expired State;
  6. Decommissioned State.

These vRealize Automation life cycle states each contain a wide variety of substates.

During a recent Proof of Concept I tried to demo how a virtual machine travels through the different life cycle states. The purpose was to show what happens to a virtual machine when the lease expires and:

  • an archive period is configured;
  • no archive period is configured.

To do this, I configured two identical blueprints, in this case blueprints containing Windows Server 2012 R2. One blueprint has an archive period of 7 days, the other has no archive period.

After deployment I configured a lease expiration for both items each deployed with one of the different blueprints, and waited for the state to change. When the end of the lease was reached, both items were shutdown as expected. But the first thing I noticed was that I could still perform all action I could perform before the lease expired. So I could power the virtual machine on again if I wanted to. After a long wait the states changed from ‘Off’ to ‘Expired‘.

Now I expected one item to be archived, so stay “Expired‘ until it reached the configured 7 day archive period. The other item without an achieve period should be deleted/destroyed. Strangely enough both items show the same behaviour, their state is set to ‘Expired‘ and both items are kept in the vRealize Automation Items tab and on the underlying vSphere platform. Even after a long wait nothing changed. Why?

keep-calm-and-investigateBut when I returned the following day, the item without an archive period configured was destroyed. The process works but it takes a very long time. Let’s investigate.

The process responsible for the state changes is the ‘IaaS Manager Service‘. This process run on all vRealize Automation IaaS Servers in the environment. You can change the frequency of several callback procedures, including the frequency that the vRealize Automation callback procedure is run for changed machine leases.

vRealize Automation uses a configured time interval to run different callback procedures on the Model Manager service, such as ProcessLeaseWorkflowTimerCallbackIntervalMiliSeconds which searches for machines whose leases have changed. The default value is 3600000 milliseconds = 60 minutes = 1 hour. You can change these time intervals to check more or less frequently.

service

How to change the interval

Log in as an administrator on the server(s) hosting the IaaS Manager Service. For distributed installations, this is the server on which the Manager Service was installed.

  1. Open the ManagerService.exe.config file in an editor. The file is located in the vRealize Automation server install directory, typically %SystemDrive%\Program Files x86\VMware\vCAC\Server.
  2. Update the ‘ProcessLeaseWorkflowTimerCallbackIntervalMiliSeconds’ value.
    For demo purposes I changed this value to 60000, to trigger an update every minute;
  3. Save and close the file;
  4. Select Start > Administrative Tools > Services;
  5. Stop and then restart the vCloud Automation Center service.

If vRealize Automation is running in High Availability mode, any changes made to the ManagerService.exe.config file after installation must be made on both the primary and failover servers.

NOTE: Changing this value can put extra load on the IaaS Server. I changed this for demo purposes, handle with care when using this in production environments.