Request to destroy a machine fails in VMware vRealize Automation 7.0.x

Products

• VMware Aria Suite

Issue/Introduction

This article provides the steps to work around the failure to destroy a machine in vRealize Automation 7.0.x.

Symptoms:

• Cannot destroy a machine in VMware vRealize Automation 7.0.x.
• Request to destroy a machine shows status as Failed.
• Status details show an error similar to: Internal error processing completion of blueprint [DESTORY] request [<GUID>] Status so far: [SUCCEEDED]

Environment

VMware vRealize Automation 7.0.x

Cause

This issue occurs when a blueprint has been modified since provisioning time and one or more components like XaaS (Anything as a Service) blueprints were removed or later destroyed in VMware vRealize Automation 7.0.x.

Resolution

This is a known issue with VMware vRealize Automation 7.0.x

A resolution for this issue is being evaluated for inclusion in a future release. Currently, there is no resolution.

To work around this issue:

1. Snapshot or back up your vRealize Automation postgres environment.
   
   
2. Gather a log bundle from vRealize Automation. For more information on collecting logs, see Log locations for VMware vRealize Automation 7.x (2141175).
   
   Note: A full log bundle containing all VMware vRealize Automation 7.0(vRA 7.0) logs (with the exception of Guest Agent and Application Services logs) can be obtained from the VMware vRealize Automation Appliance Management website under the Cluster tab.
   
   
3. Review the vRealize Automation logs for this string:
   
   Component [SetDeploymentIdentifier_1] in blueprint [JBossAppTier] refers to component type [<GUID from error message>] that is non-existing.
   
   
4. From the above error, look for the UUID from this failing component.
   
   
5. The UUID from the log entry identifies the component that has been marked as deleted since the blueprint was deployed. To proceed with the Destroy workflow the vRealize Automation vPostgress database has to be changed. Log into the vRealize Automation postgres database as the vcac user.
   
   
6. Run the below command using UUID received from step 4;
   
   update comp_componenttype set deleted=false where id='<UUID>' ;
   
   
7. Once the database update is done, the Destroy workflow may be restarted. If it fails again it means that were additional components deleted since the deployment. Follow the steps above to mark those components as un-deleted as well.
   
   
8. Once the Destroy workflow process is successful, in order to restore the data integrity, run the below command using UUID received from step 4:
   
   update comp_componenttype set deleted=true where id='<UUID>' ;
   
   
9. If you had multiple components to un-delete repeat the above step for each UUID you have marked as un-deleted.

Additional Information

To be alerted when this document is updated, click the Subscribe to Article link in the Actions box..