VMware Cloud Community
Czernobog
Expert
Expert

vRA 8.4 - editing a Cloud.NSX.Network post-provisioning? Resource action on network or vm resource?

What would be the best way to edit the network assignemt of a provisioned network resource? This would be applicable to a Cloud.vSphere.Network as well.

I have provisioned a virtual machine with multiple adapters. Clients sometimes want to change the network assignment of the vm/adapter.

My first idea would be to create a resource action on the vm, where the current configuration, which would be pulled via REST from the vCenter API, is displayed, the user would make the desired changes via drop-downs or such, and the new configuration would be pushed to the vCenter. Here I have found the first hindrance - there is no query that would allow this. In fact there does not seem to be a query at all which would allow you to just POST a new configration on a vm resource.

There is a similar issue with the vRA API - you can list network adapters of a vm with /iaas/api/machines/{id}/network-interfaces/{id1}, but there is no method that would allow you the edit it.

Another alternative to the above would be to use a vRO action, which seems pretty straighforward, I have a question here - assuming I can update the VM, would the change be reflected on the vSphere VM resource in vRA (after an inventory collection) and on the Cloud.NSX.Network as well? When I change the port group assignment on the network adapter directly in the vSphere client, the change was not reflected in the vRA deployment...

The method that is of most interest to me is to change the network resource "directly" in vRA, that is, to use a resource action on Cloud.NSX.Network, to change its properties. I currently do not have an idea on how to construct the attached workflow in vRO. I can receive and parse the payload, but how do I edit the resource? In vRO there is no equivalent to the Cloud.NSX.Network resource.

Any tips on how this can be done are welcome.

 

Tags (1)
Reply
0 Kudos
7 Replies
DexG83
Enthusiast
Enthusiast

In vRO 8.4.1 did you try to use Get Operation Workflow on /deployment/api/resources/{resourceId}/actions?

That will return the complete list of available actions that can be performed on a given resource.

after that you can check: /deployment/api/resources/{resourceId}/actions/{actionId} to know how to build your request.

Finally you can use Post Operation Workflow to perform /deployment/api/resources/{resourceId}/requests 

That will update your resource.

You can find the complete list of REST Operations on deployments 

https://{vra-appliance-name}/deployment/api/swagger/

Czernobog
Expert
Expert

I have tried to use those API calls this week. During this, I found new, annoying problem.

When you run a resource action on the vRA resource, the deployment gets locked, preventing any other REST API calls from modifying it, before the resource action is finished. So when you select a workflow for your resource action and run this action on the resource, the deployment gets locked and you cannot use any API calls to change the resource during this time. For example, when the workflow contains an action or script with a REST call to change the network configuration of a vSphere VM, it will fail with error 409 and the message: Another request is already in progress.

This implementation makes no real sense, the only workaround I could find is to embed an async worflow run in the vRO workflow launched by the resource action. This async workflow would wait for the main, parent workflow to finish (= resource action is finished) and run the API call that does the job.

The process looks as follows:

- attach the main workflow to the resource action in vRA

- put a nested, async workflow in the main workflow. There you can place you script task or action that does two things:

  - check if the main workflow completed without errors; you could also check if the request (resource action) is finished using the vRA API

  - run your main API call that modifies the resource, after the above is finished; otherwise the deployment is locked and the API call will fail

So overall this produces much overhead and is not really an optimal solution. But maybe someone can provide a better solution?

 

Reply
0 Kudos
DexG83
Enthusiast
Enthusiast

I had exactly the same challenge here

You already found a handy solution with an async workflow run.

Here is what I used to implement that: https://fluffyclouds.blog/2021/05/04/custom-add-disk-day-2-in-vra-cloud-8-x/

Reply
0 Kudos
Czernobog
Expert
Expert

This is neat!

How do you know how to format your inputs for the disk add POST request? That is, in your example, where do you get the schema for constructing the input (content) playload? From the "POST /iaas/api/machines/{id}/disks" operation, or the DiskAttachmentSpecification model?

Reply
0 Kudos
DexG83
Enthusiast
Enthusiast

I my example I needed to update the Deployment to create a new VM.

I used the following URI:

/deployment/api/deployments/{deploymentId}/requests

The payload example looks like:

{
"actionId": "string",
"inputs": {},
"reason": "string"
}

As Input just used the Deployment Request inputs:

{

"actionId": "Deployment.Update",

"inputs": {

"computeResources":{

"numCpus":1,

"memoryGb":4096

}

},

"reason": "New VM"

}

 

Regards,

Dex

Reply
0 Kudos
Czernobog
Expert
Expert

I have to admit, I have problems wrapping my head aorund it.

Lets assume the resoruce I want to edit using a reosurce action does not have and edit action per default. For example, to edit an attached network resources name I have created following content:

{
  "actionId": "Cloud.NSX.Network",
  "reason": "edting network config change",
  "inputs": {
    "name": "NIC0_renamed"
  }
}

I then POST this using deployment/api/deployments/{depId}/requests/{requestId}

After executing the request I receive a "Request response failed with status code: 404" (no value present) though.

Is there any documentatin that would help me getting the schema right?

Reply
0 Kudos
DexG83
Enthusiast
Enthusiast

As far as I can see there are no resource actions for Cloud.NSX.Network resources.

But as you described you want to change VM port group you can try to use vRO Workflow [Connect virtual machine NIC number to distributed virtual port group] to achieve that.

Reply
0 Kudos