Day 2 action deletes a virtual machine instead of add disk

Products

• VMware Aria Suite

Issue/Introduction

• The Update action is a built-in Day 2 operation. It is applicable to deployments that have an vCT association and inputs.
  • Through this Day 2 operation, users can update the input of a deployment.

Note: vRA does not update the vCT directly.

• There are two options to provide an update to an existing deployment: update flow via vCT or the Deployment Day 2 action.
  • When this Day 2 action is triggered, vRA applies the vCT against all resources in the Deployment and attempts to correct the difference between the original vCT and the new version of the vCT.
  • Similar behavior is also available in Terraform.

Symptoms:

• A deployment may drift away from the original vCloud template (vCT) of which it was deployed from.

Example: Additional disks may be attached to the machine via a Day 2 action. Through this flow, the deployment is updated with the new disk while the original vCT remains the same.

• If a user performs an Update operation in this scenario, the newly added resource will be deleted, in this case the attached disk.

Environment

VMware vRealize Automation 8.x
VMware vRealize Automation 8.6.x

Resolution

See the Workaround section below for additional information.

Workaround:
Several short-term solutions have been identified. They are listed in order of recommendation and are intended to serve as guidance for a provisional solution until support for scale operations is introduced in the product.

Custom Scale Out resource action for virtual machine resources

Creating a custom scale out resource action that performs VM provisioning that matches the definition of the targeted VM for scale out operation uses public vRA IaaS API to effectively achieve the same capability as updating the count property of a compute resource. The functional sequence of the scale out operation is as follows:

1. The user requests a custom Scale Out resource action on a VM part of the deployment
2. The user enters the desired VM count
3. A vRO workflow resolves the effective VM definition of the target VM on which the scale out action is requested using the vRA's deployment API.
4. The workflow uses the create VM API (POST /iaas/api/machines) to deploy the requested number of VMs that have the same definition as the VM used as a scale out target. The VMs get deployed within the same deployment as the scaled out VM.

The Scale In operation can be performed by using the supported Delete operation on the VM resources within the deployment.

Pros

• The solution will work for any virtual machine regardless of the fact whether there are additional resources attached to it.
• The additional resources will not be removed.
• The VM lifecycle is preserved so any existing extensibility subscriptions will follow the defined VM lifecycle sequence - compute allocation, compute reservation, compute pre-provisioning, compute post-provisioning, etc.

Cons

• Highly dynamic custom properties on the compute resources might not be properly evaluated as the solution will copy the definition of the source VM in order to derive the parameters for the deployment request.

Limitations

• The create VM API requires a flavor mapping to be used for the request so free-form VM size should resolve to an existing flavor mapping defined in the vRA's infrastructure configuration.

Use persistent disks for Add Disk resource action

When adding additional disks to a VM, the user can check the Persistent option to provision a disk that will persist after the vRA's attempt to remove the disk on deployment update for scale out.
Updating the deployment by changing the input controlling the machine count will result in vRA removing the disk resource, however the persistent option prevents vRA from deleting the disk. It will remain available and attached to the machine, albeit it not being present in the VM's deployment.

Pros

• The solution uses the native Update deployment action to scale out the deployment.
• The disk remains attached to the VM and the operation completes successfully.

Cons

• The disk resource is removed from vRA management.

Limitations

• As the disk resource becomes unmanaged by vRA, the possibility for day 2 operations on that disk is lost. In order to overcome this limitation, an API to re-onboard the extra disk is needed so that it can be consumed by vRA extensibility - a workflow attached to the deployment.action.post event. The workflow can then bring back the persistent disk under vRA management.
• The VM resource definition in the cloud template must not have attachedDisks property that defines the disk attachments. If the attachedDisks property is set to be an empty array or an array of references to additional disk resources, during the deployment update sequence, the persistent disk is not only removed from vRA management, but it is also detached form the VM as it deviates from the description of the vCT. In this case, an additional extensibility operation is required to attach the disk back to the VM. The disk, being configured as persistent, is not removed from the datastore.

Update cloud template to perform deployment update

The solution is based on the concept of updating the vCT from which the deployment originates to express the new desired state of the deployment to perform actions such as creating additional disks and then using the same mechanism to scale out the VMs in the deployment. The consumption flow of adding additional disk and a scale out operation on VMs would consist of the following steps:

1. Adding additional disk
2. Update the cloud template to contain additional disk resource, either attached to a specific VM or detached from ant VM cluster
3. Update the deployment created from the original cloud template by not changing the inputs - this will create the additional disk
4. Optionally, use a custom resource action on the disk resource to attach it to a specific VM (input being the attached VM from the deployment)
5. Scale out
6. Update the deployment by changing the input controlling the VM count - since the disk is already described in the cloud template, vRA will not try to remove it and will properly scale out the VM instances.
7. Revert the blueprint to its original version

Pros

• The solution uses the native Update deployment action in order to reconcile the described desired state of the deployment with the actual state by taking into account the updates on the resources performed as day 2 operations.

Cons

• The vCT needs to be updated every time a Day 2 operation of deployment update is required in order to inform vRA of the intended state of the deployment taking into account any previous day 2 operations that resulted in managed resource changes.
• Additional Day 2 resource action is needed to attach the newly provisioned disk to a target VM.