Step-by-Step Explanation of Ballooning, Compression & Swapping in VMware

 Onboarding of new VM to an existing deployment will be “Pending”

https://knowledge.broadcom.com/external/article?articleNumber=312268

Products

VMware Aria Suite

Issue/Introduction

Symptoms:

• Onboarding of a new VM to an existing deployment will remain in “Pending” status if the deployment has another onboarded VM with the same name
• Relocation service logs contain errors similar to the below

  2022-08-24T07:53:53.747Z ERROR relocation [host='relocation-service-app-5f4bcfc579-vwjh8' thread='reactor-http-epoll-1' user='' org='' trace=''] c.v.r.w.e.DeploymentExecutionTask - [8980/relocation/api/wo/execute-deployment/<UUID_1>] java.util.concurrent.CompletionException: java.lang.IllegalStateException: RuntimeException: Internal Server Error [Error Reference ID: 24fcxxxx-xxxx-xxxx-xxxx-xxxxxxxx3058]

• Blueprint service logs contain errors similar to the below

  2022-08-24T07:53:53.685Z ERROR tango-blueprint [host='tango-blueprint-service-app-58b4d77f6-7rwcm' thread='tasks-2' user='relocation-xxxxxxx(xxxx)' org='<UUID_2>' project='<UUID_3>' deployment='<UUID_4>' tile='<UUID_5>' trace='<UUID_6>'] com.xxxxxxxxxx.tango.blueprint.api.controller.BlueprintDeploymentController - Failed to publish resource
  com.xxxxxxxxxx.xxxxxxxxxx.csp.auth.service.SwitchUserOperationException: Failed while performing SwitchedUserOperation
         at com.xxxxxxxxxx.xxxxxxxxxx.csp.auth.service.DefaultSwitchUserService.withAuthentication(DefaultSwitchUserService.java:68) ~[spring-csp-webmvc-2.5.4.35.3.jar:2.5.4.35.3]
         at com.xxxxxxxxxx.tango.blueprint.api.controller.BlueprintDeploymentController.lambda$importResourceState$2(BlueprintDeploymentController.java:120) ~[app.jar:?]..
       Caused by: org.springframework.web.client.HttpClientErrorException$BadRequest: 400 Bad Request: [{"message":"Resource name was not unique","statusCode":400,"errorCode":0}]

Environment

VMware vRealize Automation 8.7 - 8.9.x
VMware Aria Automation 8.x

Resolution

VMware is aware of this issue. See the Workaround section for additional information.

Workaround:

1. Let's say the first VM (name - test01) is onboarded and onboarding of the second VM (name -test01) has failed.
2. Unregister the first VM.
3. Go to Virtual Machines page. Search for the VMs with the name in question (e.g., test01). This should list two VMs, one in Discovered state and other in Deployed state. Open the Web Developer tools in the browser. This is needed to capture the details of the VM that's in the Deployed state. Click on the VM which is Deployed state. This should log a call like the following in the network activity tab

   GET https://<vra>/provisioning/uerp/provisioning/mgmt/compute?expand=&$filter=(documentSelfLink eq '/resources/compute/<uuid>')&$orderby=nameasc&additionalExpand=project,placement

4. Capture the documentSelfLink value from the URL.
5. Remove the machine that's stuck from the onboarding plan.
6. Execute the following API from Postman. This will unregister the machines that's stuck in the Deployed state. Please use the Bearer token of the logged in user to vRA for running this API. Copy the documentSelfLink value captured from previous steps in the payload's resource link field.

   POST {{url}}/relocation/api/wo/unregister-machine
   {
       "resourceLink": "/resources/compute/<uuid>"
   }

7. Once the API run is successful, it should be possible to add the second VM machine and onboard the same to a new deployment.

Note: Origin(Resource origin) field in the Virtual Machines page for an onboarded machine is Onboarded from version vRA 8.7. Before vRA 8.7, the Origin field in the Virtual Machines page for an onboarded machine is Deployed.