You can scale provisioned deployments to adjust to changing workload demands. You use the scale in or scale out actions for horizontal scale, and the machine reconfigure action for vertical scale. You govern scale and reconfigure actions by using entitlements, approval policies, or by designing constraints directly into blueprints.

Scale In or Scale Out

After you provision a deployment, you can adjust to changing workload demands by increasing or decreasing the number of instances of virtual or cloud machines in your deployment. For example, you deployed a three-tiered banking application with a clustered application server node, a database node, and a load balancer node. Demand increases, and you find that the two instances of your application server node cannot handle all the traffic. Because your blueprint supports up to ten instances of the application server, and you are entitled to scale actions, you can scale out your application. You navigate to your provisioned application item in vRealize Automation and select the scale out action to add another instance of your application server node to the deployment. vRealize Automation provisions a new machine, installs the application software component, and updates your load balancer so your application can handle the increased demands.

If demand decreases, you can scale the deployment in. The newest machines and software components are destroyed first, and your networking and security components are updated so that your deployed application isn't using any unnecessary resources.

Table 1. Support for Scalable Components

Component Type



Machine components


Scale out provisions additional instances of your machines, and scale in destroys machines in last in, first out order.

Software components


Software components are provisioned or destroyed along with machines that are scaled, and the update life cycle scripts are run for any software components that depend on the scaled machine components.

Networking and security components


Networking and security components, including NSX load balancers, security groups and security tags, are updated for the new deployment configuration.

Scaling impacts the network and security, including load balancer, settings for the deployment. When you scale in or scale out a deployment that contains one or more nodes, the associated NSX networking components are updated. For example, if there is an on-demand NAT networking component associated with the deployment, the NAT rules are updated in accordance with the scaling request.

When you scale in or scale out a deployment that contains an associated load balancer, the load balancer is automatically configured to include newly added machines or to stop load balancing machines that are targeted for tear down.

When you scale out a deployment that contains a load balancer, secondary IP addresses are added to the load balancer. Depending on whether you scale in or scale out, virtual machines are added or removed from the load balancer and saved or removed in the IaaS database.

XaaS components


XaaS components are not scalable and are not updated during a scale operation. If you are using XaaS components in your blueprint, you could create a resource action for users to run after a scale operation, which could either scale or update your XaaS components as required. Alternatively, you could disable scale by configuring exactly the number of instances you want to allow for each machine component.

Nested blueprints


Supported components in nested blueprints might only update if you create explicit dependencies to scaled machine components. You create explicit dependencies by drawing dependency lines on the design canvas.

When you scale out a deployment, vRealize Automation allocates the requested resources on the current reservation before proceeding. If the scale is partially successful, and fails to provision one or more items against those allocated resources, the resources are not deallocated and do not become available for new requests. Resources that are allocated but unused because of a scale failure are known as dangling resources. You can try to repair partially successful scale operations by attempting to scale the deployment again. However, you cannot scale a deployment to its current size, and fixing a partially successful scale this way does not deallocate the dangling resources. You can view the request execution details screen and find out which tasks failed on which nodes to help you decide whether to fix the partially successful scale with another scale operation. Failed and partially successful scale operations do not impact the functionality of your original deployment, and you can continue to use your catalog items while you troubleshoot any failures.

For a clustered deployment, in which the deployment created from a blueprint contains more than one VM, scaling fails if the blueprint uses a hostname custom property but does not contain a machine prefix value. To avoid this issue, you can use the machine prefix option in the blueprint definition. Otherwise, the scaling function attempts to use the same hostname setting for each VM in the cluster.

Scale Up or Scale Down By Using Reconfigure

After you provision a vSphere, vCloud Air, or vCloud Director virtual or cloud machine you can adjust to changing workload demands by requesting a machine reconfigure to increase (scale up) or decrease (scale down) machine resource specifications for CPU, memory, storage, or networks. You can also add, edit, or remove custom properties and change descriptions. You can request to reconfigure machines for scale up or scale down that are in the On or Off state.

When you reconfigure a virtual or cloud machine for scale up, vRealize Automation allocates the requested resources on the current reservation before proceeding. If the resources are not available, the machine reconfigure fails. If a machine reconfigure request fails, any resources allocated for scale up are deallocated and available for new requests. When you reconfigure a virtual or cloud machine for scale down, resources are not made available to new requests unless the reconfigure finishes successfully.

Table 2. Required Entitlements for Machine Reconfigure for Scaling Scenarios (vSphere, vCloud Air, and vCloud Director only

Virtual or Cloud Machine Owner wants to...

Required Entitlements

Run the reconfigure for scaling immediately after any required approvals are given.


Specify a date and time to run the reconfiguration for scaling.


Reschedule a reconfigure for scaling because the request was not approved until after the scheduled time.


Retry a failed reconfigure request.

Execute reconfigure

Cancel a failed reconfigure request.

Cancel reconfigure

Cancel a scheduled reconfigure request.

Cancel reconfigure