Trying to debug guest customization timeout but VM is deleted even with debug deployment property

[darrenoid]

Has anyone used the _debug_deployment property in vRA to troubleshoot deployment failures? I have tried to set this property for a blueprint, but the VM still gets deleted. The deployment is marked as partially successful, but the VM is still deleted. According to https://docs.vmware.com/en/vRealize-Automation/7.6/vrealize-automation-76-custom-properties.pdf :

"by setting _debug_deployment to true, you can more easily debug customization and first-boot (for example, agent) issues because the setting ensures that machines are not destroyed after a provisioning failure."

I am trying to find out why guest customization is timing out and for that I need the logs inside the VM. The issue is intermittent and usually late at night (automation) so I can never catch it in the act.

Has anyone else used this property and had the VM not get destroyed? Is this a bug? Is there any other way to stop vRA from destroying machines in a failed deployment?

I tried setting doDeletes to false in VRMAgent.exe.config, but I found out that applies to all deletions not just ones on failures. This has caused the vm storage to fill up, so I will have to revert that change.

[daphnissov · Accepted solution]

This is a common misconception. The custom property _debug_deployment ONLY works when these two conditions are true.

1. Software components are in use.
2. The failure occurred while executing the software component work item.

On the second point, the failure has to occur in the software component's script and not any time before that.

As far as the doDeletes, yes, that applies to the entire endpoint. So what you'll need to do is enable that for troubleshooting purposes to determine root cause, fix it, and then disable that.

-----------------------------------------

Was it helpful? Let us know by completing this short survey here.

[darrenoid]

Thanks for the clarification daphnissov, we are not using software components at all and the failure I am troubleshooting happens before software components would run.

Unfortunately setting doDeletes to false is not something that will work in my scenario. The issue I am troubleshooting only happens maybe once a week. We have heavy deploy and destroys going on all the time, so this would fill up our storage systems in short order. One example, we have automation that deploys and destroys a VM multiple times a day, but is on local storage only big enough for one VM at a time. With doDeletes set to false, the first deployment is kept on disk and all subsequent deployments fail until the VM is manually removed from disk in vcenter.

I was hoping there was a more selective way (by blueprint) of keeping the VM around after failure, but it looks like I will have to be more creative in finding a way to get at those VM logs.

Regards,

Darren

[daphnissov]

If you're getting failures in the customization phase, it's something in either your template, group policy (if Windows), or something environmental. At that point, vRA is hands off of the process and is only commanding vCenter to perform the activity. Once possibility might be to install the Log Insight agent inside the guest and have it ship off those logs (or a lower tech way to do something similar). Even if/when the VM gets destroyed, you'll have those things stick around.