Aria Automation Day 2 action fails - Error "Network resource no longer exists in the deployment"
search cancel

Aria Automation Day 2 action fails - Error "Network resource no longer exists in the deployment"

book

Article ID: 409850

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

VMware Aria Automation deployments and associated Day 2 operations may fail with the error "Network resource no longer exists in the deployment." This typically occurs when the underlying network configuration of a deployed Virtual Machine (VM) is modified or removed outside of the Aria Automation interface, causing a discrepancy between Aria Automation's internal records and the actual infrastructure state.

Environment

Aria automation 8.18.x

Cause

This issue occurs when network configurations to which Aria Automation deployed VMs are modified or deleted directly in the underlying infrastructure (e.g., vCenter) without being updated through Aria Automation's interface.

Detailed Scenario (Example): A common scenario involves:

  1. VMs are moved from an original network (e.g., Subnet SN1) to a new network (e.g., Subnet SN2) directly within vCenter.
  2. The original network (Subnet SN1) is subsequently deleted.

Aria Automation's data collection process correctly removes the deleted network (SN1) from its inventory. However, the existing deployment records in Aria Automation's database for the affected VMs may retain references to Subnet SN1. This creates a broken link, as the deployment still expects the VM to be connected to a network resource that no longer exists in Aria Automation's active inventory.

Resolution

This database issue in Aria Automation can be fixed using a script provided by Broadcom Support. It reconnects broken links to the correct network

Additional Information

How to Run the Script

Important: Before running the script, take a backup of the provisioning-db and create a snapshot of all VRA nodes.

The script can be executed in three different modes, depending on the verification and resolution steps you want to perform:

1. Simulation Mode (Recommended First Step)

  • Run the script as-is, without making any changes.
  • In this mode, the script simulates the process and does not make any database updates.
  • It will list all database updates that would be required to fix the issue.
  • Always run this mode first to review and understand the changes before proceeding.

2. Single Record Update (Verification Step)

  • Open the script and locate the boolean variable named simulate, which is set to true.
  • Change it to false, and run the script again.
  • It will locate the first compute_network record that needs to be updated and update it, along with any associated network_interface_state records.
  • After running, use the output to identify the affected VM and verify that Day 2 operations are working as expected.
  • You can run the script multiple times to verify other records individually.

3. Bulk Update (Final Step)

  • If the verification step is successful, you can proceed to update all affected records.
  • Open the script again and find the integer variable named row_count, which is set to 1.
  • Change it to a larger value, such as 10000, and run the script.
  • This will update all the records that need fixing in one go.

If you experience similar issues or are unsure about executing the script, please open a support ticket with Broadcom Support. Our team will guide you through the process and help you safely resolve the issue.

Attachments

fixSubnets.sql get_app