Day-2 Delete operations fail with negative capacity placement errors in VMware Aria Automation

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

You are unable to perform Day-1 provisioning or Day-2 Delete actions on virtual machines within a specific Project or Cloud Zone.

When attempting these actions, Aria Automation halts the request and displays one of the following capacity errors in the UI or deployment history:

• "The request for '[X]' MBs of memory per instance exceeds the project capacity limit for the associated cloud zones."
• "Requested memory is more than the available memory placement: -[X] MB"

Note the severely negative capacity value.

Environment

• VMware Aria Automation 8.x
• VMware vRealize Automation 8.x

Cause

This issue is caused by a combination of environmental resource changes and a known software issue.

1. Environmental Overallocation: If a large number of VMs are moved into a Cloud Zone outside of Aria Automation (such as a cross-vCenter or cross-datacenter vMotion directly in vSphere), Aria Automation's background data collection updates the group resource placement references. This sudden influx of external VMs causes the destination Project to silently breach its configured resource limits, resulting in an over-allocated state (represented by negative available capacity).
2. Software Issue: While preventing new Day-1 provisioning in an over-allocated state is expected behavior, Aria Automation incorrectly blocks Day-2 Delete operations when a Project's limits are exceeded. This issue prevents you from deleting unwanted deployments to free up space and get back under your defined limits.

Additionally, in versions prior to 8.18.1 Patch 4, external vMotion recalculations were delayed, causing overallocations to go unnoticed until you actively attempted a deployment or deletion.

Resolution

This is a known issue. The issue preventing Day-2 Deletions in an over-allocated state is resolved in VMware Aria Automation 8.18.1 Patch 5 (U5) and later. In this release, the Delete operation bypasses Project limit enforcement, allowing you to successfully delete VMs even if the Project is over-allocated.

Additionally, it is recommended to be on 8.18.1 Patch 4 (U4) or later, which introduces a visibility fix that recalculates Project limits within 1-2 data collection cycles following out-of-band vMotions, alerting you to overallocation much faster.

Workaround

If you are unable to upgrade immediately, you can bypass the database capacity checks to forcefully delete the deployments using the following workaround:

1. Log in to the Aria Automation Assembler (Cloud Assembly) UI.
2. Navigate to Infrastructure > Administration > Projects.
3. Open the affected Project and navigate to the Cloud Zones (or Provisioning) tab.
4. Document the current hard limit set in the Memory limit (MB) field.
5. Temporarily change the Memory limit to 0 (Unlimited) and save the Project.
6. Perform the required Day-2 Delete actions (or use a Change Project action to move the deployments to a different project with sufficient capacity).
7. Once the resource footprint has been reduced, manually revert the Project's memory limit back to the original value documented in Step 4.

Additional Information

If a Project's resource allocation counters remain wildly inaccurate or negative even after limits have been verified and resources have been cleared, the internal Postgres database counters may need to be forcefully synchronized. While KB 326134 (Provisioning in vRealize Automation fails with "Request memory is more than the available memory placement") provides a vRO workflow to recalculate these limits, it will not succeed if the Project is genuinely over-allocated due to the vMotion issue described in this article. Ensure the workaround above is performed prior to running any database recalculation workflows.