You can use Resume on failed deployments to restart the provisioning process from the point of failure and under specific circumstances. When enabled, the Resume action is available for failed provisioning requests or applicable actions.

To use resume on provisioning requests, you must add the _debug_deployment = true custom property to the blueprint. By default, failed deployments are rolled back and cleaned up so that the resources are reclaimed. The _debug_deployment = true property retains the deployment at the point of failure and, where supported and based on how it works, allows for a Resume action. If you are only using resume on the supported actions, you do not need to enable the _debug_deployment property .

For more about _debug_deployment, see Custom Properties Underscore (_).

To use resume on a provisioning request or on the available actions, you entitle users to the Resume action. See Entitle Users to Services, Catalog Items, and Actions.

You can entitle users to the Resume action for these provisioning activities.

  • Provisioning requests

  • Resume action

  • Scale In action

  • Scale Out action

  • Destroy action

Resume Action Constraints

When deciding if you can use Resume rather than requesting a new instance of a blueprint, consider the constraints.

  • The blueprint is unmodifiable from the time of the request.

    At request time, an unmodifiable version of the blueprint is associated with the catalog request. This static version contains all the specifications, including attributes, custom properties, settings, and so on, as it was when provisioning started. If you have a failure-producing error in your blueprint, fixing the error and then using Resume does not work because it is referring to the version associated with the request. In this scenario, you must provision a new instance.


    • Blueprint A requests 5 GB of RAM, but the request fails because you only have reservations for 3 GB. If you update the blueprint to need only 3 GB, and then run Resume, the Resume action fails. When Resume runs, it checks the original request and is still looking for 5 GB. However, if you increase the system reservation for the business group to 5 GB and run Resume, the Resume action succeeds.

    • When you request Blueprint B, which includes a Guest Custom Specification, it fails. Investigation reveals that the Guest Custom Specification was renamed on your vCenter Server instance. If you update the blueprint with the new name and run Resume, it fails. You updated the blueprint, but the original version is used for the Resume action. If the new name is the one you want to use going forward, deploy a new instance of the blueprint rather than using Resume. Otherwise, you must change the name of the Guest Custom Specification on the vCenter Server instance back to the one expected by the original version and run Resume. If you don't want the next provisioning request to fail, don't forget to update the blueprint with the correct Guest Custom Specification.

    Resume works if you can update the target deployment environment to support the blueprint specifications as they existed at request time.

  • Retry is only from the point of failure.

    The Resume action retries the component tasks from the point of failure. It does not resubmit the entire provisioning request.


    • Blueprint C creates an application virtual machine and a database virtual machine. The database VM is successfully deployed, but the provisioning fails on the application VM. If you run the Resume action, only the application VM provisioning is retried.

      If a component is marked as Failed, it is treated as if it never ran. If the installation fails during the configuration phase on the database VM, for example, due to a scripting error, but the database is intact, the database still exists when the script runs during a resume action. The installation script, which includes the configuration script, does not run again. Your resume does not succeed. You must fix the script and provision a new instance.

    • Another variation to consider is where the allocation of step succeeded, but the provision failed. In this example, when you resume, which retries from the point of the failed provisioning, the resume request is processing stale allocation information and the resume fails.