A colleague of mine ran into an issue where vRA was unable to deploy a VM in one of the customers’ vCenter. The customer had an automated way of deploying roles and permissions. So, if vRA was able to deploy a VM in the other vCenters, then that particular vCenter should be fine. But yet it still did.

The error shown in vRA was:

vCenter responded with “Permission to perform this operation was denied.”

It’s obvious that there is a permission issue. But that can’t be the case because of the automated way roles and permissions are set by the customer. So I was asked if I could have a look at vRLI to see if I could find out what was the issue.

After much searching, I found a string on which I could filter to get the correct information out of vRLI. And that string is

privilegeId

It pointed to multiple objects that didn’t have the correct permissions. Apparently, there was a glitch between what the GUI was showing and what the actual permissions were. A reboot of the vCenter fixed that glitch. After reapplying the roles and permissions, the problem was solved.

So, whenever you encounter permissions issues between vRA and vCenter, look in vRLI for “privilegeId” to locate the object(s). And if the permissions seem to be correct in the GUI, reboot the vCenter.