Manually unregister an onboarded machine from a deployment in case of an unregister action failure
search cancel

Manually unregister an onboarded machine from a deployment in case of an unregister action failure

book

Article ID: 346013

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

Machines fail to unregister and cannot be onboarded again. This article provides information on how to put these machines back to Discovered state.

Symptoms

After performing the unregister action on an onboarded machine, the machine remains in "onboarded" state in the resource view and cannot be added to a new onboarding plan.

Environment

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

Cause

Temporary issues can interfere with the unregistering process. Also, if onboarding isn't completed properly, the machine might not have the required information for unregister to work.

Resolution

VMware is aware of this issue. Currently there is no resolution.

Workaround:

Manually remove the stale entries using the REST API or execute the attached workflow.

NOTE:

  • This workaround deletes database entries.
  • This workaround has only been tested on single tenant environments. Do not use in multi-tenant configurations.

Prerequisites

  • You have backups of the VMware Aria Automation 8.x appliance(s)
    • You must back up all VMware Aria Automation appliances at the same time - simultaneously for all nodes.
    • If you are making the snapshots manually, you must start the snapshots of the second and the third node not more than 40 seconds after you start the snapshots for the first node.
    • When you back up the VMware Aria Automation appliance, disable in-memory snapshots and enable quiescing (quiescing is a requirement only for version 8.9 and newer).
  • Acquire an Authentication Token
    For more information, see the "Getting Your Authentication Token" section in the VMware Aria Automation Programming guide.

Procedure: Remove the stale entries using the Orchestrator workflow

  1. Download the code.vmware.kb.346013.unregister.vm.minimal.package package file.
    Attached to this Knowledge Base article.
  2. Import the package into Orchestrator.
  3. Run the workflow and fill in the required information.
  4. Validate that the duplicate VM is removed from deployments and retry the onboarding process.

Procedure: Remove the stale entries using the REST API

  1. Get the affected compute ID.
    GET https://AriaAutoFQDN/deployment/api/resources?search=VM-Name001
    • Replace AriaAutoFQDN with the FQDN of your Aria Automation environment.
    • Replace VM-Name001 with the affected VM name.
    • From the output, copy the ID (e.g., 20f7eb1b-0cfc-3af0-b364-963face2eb4c). This will be used as the compute id in the next step.
  2. Get the affected compute details.
    GET https://AriaAutoFQDN/provisioning/uerp/resources/compute/<compute id>
    Take note of the compute descriptionLink from the output.
    Example:
    {
        "descriptionLink": "/resources/compute-descriptions/c51a5472-72e8-4ded-afe6-6e41f1caa3b4",
        ...
    }
  3. Delete the compute description from the output in the previous step.
    DELETE https://AriaAutoFQDN/provisioning/uerp/<ComputeDescriptionLink>
  4. For each disk, delete the disk description and update the disk state.
    • For each entry in the diskLinks field from the GET compute response in Step 2:
      GET https://AriaAutoFQDN/provisioning/uerp/<diskLink>
    • Find the descriptionLink field in the response and send a DELETE command.
      Note: Boot disks and external devices (e.g., CD/DVD Drive) do not contain a descriptionLink and can be skipped.
      DELETE https://AriaAutoFQDN/provisioning/uerp/<descriptionLink>
    • For each disk entry that contained a descriptionLink, take its response body from the GET command and edit it as follows:
      • From the tenantLinks field, remove entries that start with /owner/provisioning/auth/csp/users and /provisioning/resources/projects.
      • Remove the descriptionLink, ownerAuthLink, and projectAuthLink fields entirely.
      • From the customProperties map, remove the key-value pairs for '__blueprint_resource_type', '__deployment_id', and '__composition_context_id'.
  5. Send the edited disk entry back as the request body with a PUT command.
    PUT https://AriaAutoFQDN/provisioning/uerp/<diskLink>
  6. Update the compute tenant links and remove specified properties.
    Take the compute response body received in Step 2 and edit it as follows:
    • Remove the descriptionLink, ownerAuthLink, and projectAuthLink fields.
    • From the tenantLinks field, remove entries that start with /owner/provisioning/auth/csp/users and /provisioning/resources/projects.
    • From the customProperties map, remove the key-value pairs for '__composition_context_id' and '__deployment_id'.
  7. Send the edited compute entry back as the request body.
    PUT https://AriaAutoFQDN/provisioning/uerp/<computeSelfLink>
  8. Get each network interface from the compute response in Step 2 and update its state.
    1. For each entry in the networkInterfaceLinks field:
      GET https://AriaAutoFQDN/provisioning/uerp/<networkInterfaceLink>
    2. For each network interface, take the response body and remove entries from the tenantLinks field that start with /owner/provisioning/auth/csp/users and /provisioning/resources/projects.
    3. Send the edited network interface entry back as the request body with a PUT command:
      PUT https://AriaAutoFQDN/provisioning/uerp/<networkInterfaceLink>

Additional Information

Impact/Risks:
Note: This procedure modifies the database. Ensure to back up your appliances. For more information, see Backing Up the vRealize Automation 8.x Appliance.

Attachments

code.vmware.kb.346013.unregister.vm.minimal.package get_app