What actions can I run on Automation Assembler deployments or supported resources

After you deploy cloud templates or onboard resources, you can run actions in Automation Assembler to manage the resources. The available actions depend on the resource type and whether the actions are supported on a particular cloud account or integration platform.

The available actions also depend on what your administrator entitled you to run.

As an administrator or project administrator, you can set up Day 2 Actions policies in Automation Service Broker. See How do I entitle consumers to Automation Service Broker day 2 action policies

You might also see actions that are not included in the list. These are likely custom actions added by your administrator. For example, a vMotion action.

Caution:

To change a deployment, you can edit its cloud template and reapply it, or you can use day 2 actions. However, in most cases you should avoid mixing the two approaches.

Lifecycle day 2 changes such as power on/off are usually safe, but others require caution, such as when adding disks.

For example, if you add disks with a day 2 action, and then take a mixed approach by reapplying the cloud template, the cloud template could overwrite the day 2 change, which might remove disks and cause data loss.

Table 1. List of possible actions

Action	Applies to these resource types	Available for these cloud types	Resource origin	Description
Add Disk	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Add additional disks to existing virtual machines. If you add a disk to an Azure machine, the persistent disk or non-persistent disk is deployed in the resource group that includes the machine. When you add a disk to an Azure machines, you can also encrypt the new disk using the Azure disk encryption set configured in the storage profile. You cannot add a disk to an Azure machine with an unmanaged disk. When you add a disk to vSphere machines, you can select the SCSI controller, the order of which was set in the cloud template and deployed. You can also specify the unit number for the new disk. You cannot specify a unit number without a selected controller. If you do not select a controller or provide a unit number, the new disk is deployed to first available controller and assigned then next available unit number on that controller. If you add a disk to a vSphere machine for a project with defined storage limits, the added disk must not exceed the storage limits. Storage limits consider the actual capacity for thick and thin resource provisioning so that you cannot over-provision using thin provisioning. If you use VMware Storage DRS (SDRS) and the datastore cluster is configured in the storage profile, you can add disks on SDRS to vSphere machines.
Attach SaltStack Resource	Machines	Amazon Web Services Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Attach a SaltStack Resource to a deployment resource so that you can install a Salt minion and update the Salt configuration on the virtual machine. You can use this action to update a configuration on a resource or attach the resource and install the minion on another resource in the deployment. The Attach Salt Resource action is available if you configured the SaltStack Config integration. To apply a configuration, you must select an authentication method. The Remote access with existing credentials uses the remote access credentials that are included in the deployment. If you changed the credentials on the machine after deployment, the action can fail. If you know the new credentials, use the Password authentication method. The Password and Private key use the user name and the password or key to validate your credentials and then connect to the virtual machine using SSH. If you do not provide a value for the Master ID and Minion ID, Salt creates the values for you.
Cancel	Deployments Various resource types in deployments	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Cancel a deployment or a day 2 action on a deployment or a resource while the request is being processed. You can cancel the request on the deployment card or in the deployment details. After you cancel the request, it appears as a failed request on the Deployments page. Use the Delete action to release any deployed resources and clean up your deployment list. Canceling a request that you think has been running too long is one method for managing deployment time. However, it is more efficient to set the Request Timeout in the projects. The default timeout is two hours. You can set if for a longer period of time if the workload deployment for a project requires more time.
Change Lease	Deployments	Amazon Web Service Microsoft Azure VMware vSphere	Deployed Onboarded	Change the lease expiration date and time. When a lease expires, the deployment is destroyed and the resources are reclaimed. Lease policies are set in Automation Service Broker.
Change Owner	Deployments	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Changes the deployment owner to the selected user or Active Directory group. The selected user or AD group must be an administrator or a member of the same project that deployed the request. Only users or AD groups defined in the project are available to become the owner. Custom groups are not eligible to be the target owner. When a cloud template designer deploys a template, the designer is both the requester and the owner. However, a requester can make another project member the owner. You can use policies to control what an owner can do with a deployment, giving them permissions that are more restrictive or less restrictive.
Change Project	Deployments	Amazon Web Service Google Cloud Platform Microsoft Azure NSX-T NSX-V VMware Cloud on AWS VMware vSphere	Deployed Migrated Onboarded	You use the change project action to move a deployment from one project to another project. The change project action is available for deployments with deployed resources, migrated resources, onboarded resources, and deployments with a mixture of deployed, migrated, and onboarded resources. Supported resources include the following resource types and constraints: Deployments with deployed resources can contain virtual machines, disks, load balancers, networks, security groups, Azure groups, NATs, gateways, custom resources, Terraform configurations, and Ansible and Ansible Tower resources. Deployments with migrated resources can contain virtual machines, disks, load balancers, networks, security groups, NATs, gateways, and custom resources. Deployments with onboarded resources can contain virtual machines, disks, and networks. If you add an unsupported resource type in any deployment type, deployed, migrated, or onboarded resources, you cannot run the change project action. Roles, considerations, and constraints for deployments with deployed, migrated, onboarded, and hybrid/mixed resources: To change the project of a deployment with deployed or migrated resources, the initiating user must have the following role: Cloud administrator. You can only change the project when the target project contains all the cloud zones where the deployment's machines and disks are deployed. The moved deployment is then subject to the configured limits of the target project, including instance count, memory, CPU, and storage. After the move, the current usage is released from the source project. After you move a deployment to the target project, it is subject to the policies of target project. For example, lease, day 2 actions, resource quota, and other polices. To move a deployment, the deployment lease defined by the lease policy of the target project cannot expire in the next 24 hours. The Change Project action is available for deployments where the custom resources are scoped to be available to any project. The lifecycle and day 2 actions for each custom resource in the deployment must be shared with all projects to ensure that you can continue to manage the custom resource using lifecycle actions or day 2 actions after you move the deployment to the new project. The extensibility constraints of the target project must match the vRO integration or the same ABX FaaS provider as the source project. The integrations and providers must match so that you can manage the custom resource using lifecycle actions or day 2 actions after you move the deployment to the new project. The Change Project action is available for deployments with Terraform configurations where all the content sources are shared. If any content sources used in the deployment are not shared, the Change Project action fails validation and does not run. If a Change Project action fails because a Terraform GitHub repository content source was not shared, you can note the corresponding ID that you must share and then share the source. To share the source repository, select Infrastructure > Integrations and select the GitHub integration. In the open integration page, click the Projects tab, expand the project that contains the repository for the failed action and turn on the sharing for that repository. You can also use the API to share the content source repositories. The Change Project action might not be available if you migrated a deployment that contains a custom resource, where the custom resource includes an update action, and you have performed an iterative update of the deployment by redeploying the cloud template. Roles, considerations, and constraints for deployments with onboarded resources: To move a deployment with onboarded resources, the initiating user must have at least one of the following roles: Cloud administrator. Manage Deployments permission. This permission can be defined as a custom role. Project administrator of the target project. Project member of the target project and the deployments are shared between all users in the target project. While you can move onboarded resources to a project that does not contain the same cloud zones, if the target project does not have the same cloud zones, any future day 2 actions involving cloud account / region resources that you run might not work. General considerations: If you are an administrator who is moving the deployment, you might move the deployment to a project where the owner is not a member and therefore loses access. To resolve the problem, you can add the owner to the target project, move the deployment to a project where they are a member, or use the Change Owner action.
Change Security Groups	Machines	VMware vSphere	Deployed Onboarded	You can associate and dissociate security groups with machine networks in a deployment. The change action applies to existing and on-demand security groups for NSX-V and NSX-T. This action is available only for single machines, not machine clusters. To associate a security group with the machine network, the security group must be present in the deployment. Dissociating a security group from all networks of all machines in a deployment does not remove the security group from the deployment. These changes do not affect security groups applied as part of the network profiles. This action changes the machine's security group configuration without recreating the machine. This is a non-destructive change. To change the machine's security group configuration, select the machine in the topology pane, then click the Action menu in the right pane and select Change Security Groups. You can now add or remove the association on the security groups with the machine networks.
Connect to Remote Console	Machines	VMware vSphere	Deployed Discovered Onboarded	Open a remote session on the selected machine. Review the following requirements for a successful connection. As a cloud administrator, verify that the ESXi host is accessible over SSL from the network that your consumers are using. As a deployment consumer, verify that the provisioned machine is powered on. If your connection attempt indicates that a connection can not be established with the host, you might be required to accept the self-signed certificate. If you receive a certificate error, click accept the certificate and use the method provided by your browser to open the URL for the VMware ESXi page. Opening the VMware ESXi page is sufficient to accept the certificate. You can close the ESXi page. Refresh or reopen the remote connection page that previously displayed the warning. The console for the target machine opens. As an administrator, if you prefer to ensure trusted certificates, see KB2113926 to configure CA signed certificates for ESXi hosts.
Create Disk Snapshot	Machines and disks	Microsoft Azure	Deployed Onboarded	Create a snapshot of a virtual machine disk or a storage disk. For machines, you create snapshots for individual machine disks, including boot disk, image disks, and storage disks. For storage disks, you create snapshots of independent managed disks, not unmanaged disks. In addition to providing a snapshot name, you can also provide the following information for the snapshot: Incremental Snapshot. Select the check box to create a snapshot of the changes since the last snapshot rather full snapshot. Resource Group. Enter the name of the target resource group where you want to create the snapshot. By default, the snapshot is created in the same resource group that is used by the parent disk. Encryption Set Id. Select the encryption key for the snapshot. By default, the snapshot is encrypted with the same key that is used by the parent disk. Tags. Enter any tags that will help you manage the snapshots in Microsoft Azure.
Create Snapshot	Machines	Google Cloud Platform VMware vSphere	Deployed Onboarded	Create a snapshot of the virtual machine. If you are allowed only two snapshots in vSphere and you already have them, this command is not available until you delete a snapshot. When creating a snapshot for a Google Cloud Platform machine, you can also create a disk snapshot of the attached disks. The combined snapshot allows you to manage the machine as the attached disks as a single entity.
Delete	Deployments	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Destroy a deployment. All the resources are deleted and the reclaimed. If a delete fails, you can run the delete action on a deployment a second time. During the second attempt, you can select Ignore Delete Failures. If you select this option, the deployment is deleted, but the resources might not be reclaimed. You should check the systems on which the deployment was provisioned to ensure that all resources are removed. If they are not, you must manually delete the residual resources on those systems.
	NSX Gateway	NSX	Deployed Onboarded	Delete the NAT port forwarding rules from an NSX-T or NSX-V gateway.
	Machines and load balancers	Amazon Web Service Microsoft Azure VMware vSphere VMware NSX	Deployed Onboarded	Remove a machine or load balancer from a deployment. This action might result in an unusable deployment.
	Security groups	NSX-T NSX-V	Deployed Onboarded	If the security is not associated with any machine in the deployment, the process removes the security group from the deployment. If the security group is on-demand, then it is destroyed on the endpoint. If the security group is shared, the action fails.
	Tanzu Kubernetes clusters	VMware vSphere	Deployed Onboarded	Remove a Tanzu Kubernetes cluster from a deployment.
Delete Disk Snapshot	Machines and disks	Microsoft Azure	Deployed Onboarded	Delete an Azure virtual machine disk or managed disk snapshot. This action is available when there is at least one snapshot.
Delete Snapshot	Machines	VMware vSphere Google Cloud Platform	Deployed Onboarded	Delete a snapshot of the virtual machine.
Disable Boot Diagnostics	Machines	Microsoft Azure	Deployed Onboarded	Turn off the Azure virtual machine debugging feature. This option is only available if the feature is turned on.
Disable Log Analytics	Machines	Microsoft Azure	Deployed Onboarded	Turn off the ability to run log queries on Azure virtual machine logs. Select the name of the extension that you want to deactivate. If there is no extension name to select, then the log analytics are not currently enabled on this machine. To work with the log analytics, Azure Monitor and the cloud template must be configure to support the workspace. See Log Analytics.
Edit Tags	Deployments	Amazon Web Service Microsoft Azure VMware vSphere	Deployed Onboarded	Add or modify resource tags that are applied to individual deployment resources.
Enable Boot Diagnostics	Machines	Microsoft Azure	Deployed Onboarded	Turn on the Azure virtual machine debugging feature to diagnose virtual machine boot failures. The boot diagnostics information is available in your Azure console. The Enable option is only available if the feature is not currently turned on.
Enable Log Analytics	Machines	Microsoft Azure	Deployed Onboarded	Turn on the Azure virtual machine to edit and run log queries on data collected by Azure Monitor logs. You provide the extension name. The workspace ID and key must be the values that are configured in Azure. To work with the log analytics, Azure Monitor and the cloud template must be configure to support the workspace. See Log Analytics.
Get Terraform State	Terraform Configuration	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Display the Terraform state file. To view any changes that were made to the Terraform machines on the cloud platforms that they were deployed on and update the deployment, you first run the Refresh Terraform State action, and then run this Get Terraform State action. When the file is displayed in a dialog box. The file is available for approximately 1 hour before you need to run a new refresh action. You can copy it if you need it for later. You can also view the file on the deployment History tab. Select the Get Terraform State event on the Events tab, and then click Request Details. If the file is not expired, click View content. If the file is expired, run the Refresh and Get actions again. You can run other day 2 action on the Terraform resources that are embedded in the configuration. The available actions depend on the resource type, the cloud platform that they are deployed on, and whether you are entitled to run the actions based on a day 2 policy.
Power Off	Deployments	Amazon Web Service Microsoft Azure VMware vSphere	Deployed Discovered Onboarded	Power off the deployment after first attempting to shutdown the guest operating systems. If the soft power off fails, a hard power off still runs.
	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Power off the machine after first attempting to shut down the guest operating systems. If the soft power off fails, the hard power off still runs.
Power On	Deployments	Amazon Web Service Microsoft Azure VMware vSphere	Deployed Onboarded	Power on the deployment. If the resources were suspended, normal operation resumes from the point at which they were suspended.
	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Discovered Onboarded	Power on the machine. If the machine was suspended, normal operation resumes from the point at which the machine was suspended.
Reboot	Machines	Amazon Web Service VMware vSphere	Deployed Onboarded	Reboot the guest operating system on a virtual machine. For a vSphere machine, VMware Tools must be installed on the machine to use this action.
Rebuild	Deployments	VMware vSphere	Deployed Migrated Onboarded	Rebuild several or all virtual machines in the deployment where the deployment failed or not all requested VMs are provisioned successfully. The rebuild process keeps the same configuration, such as name, ID, IP address, machine data store, and custom properties for each selected machine. A non-persistent disk that is attached to a virtual machine is wiped clean and then recreated as part of the build action. Any attached first class disks are detached and the contents is retained. After you rebuild the machine, you can re-attach the disk. For machines with a missing image, you must select a valid image to rebuild.
	Machines	VMware vSphere	Deployed Migrated Onboarded	Rebuild a virtual machine where the deployment resulted in a partial deployment, the virtual machine is not usable, or to reprovision a problematic virtual machine after a successful deployment. The rebuild process keeps the same configuration, such as name, ID, IP address, machine data store, and custom properties. A non-persistent disk that is attached to a virtual machine is wiped clean and then recreated as part of the build action. Any attached first class disks are detached and the contents is retained. After you rebuild the machine, you can re-attach the disk.
Reconfigure	Load Balancers	Amazon Web Service Microsoft Azure VMware NSX	Deployed Onboarded	Change the load balancer size and logging level. You can also add or remove routes, and change the protocol, port, health configuration, and member pool settings. For NSX load balancers, you can enable or deactivate the health check and modify the health options. For NSX-T, you can set the check to active or passive. NSX-V does not support passive health checks.
	NSX Gateway port forwarding	NSX-T NSX-V	Deployed Onboarded	Add, edit, or delete the NAT port forwarding rules from an NSX-T or NSX-V gateway.
	Security Groups	NSX-T NSX-V VMware Cloud VMware vSphere	Deployed Onboarded	Add, edit, or remove firewall rules or constraints based on whether the security group is an on-demand or an existing security group. On-demand security group Add, edit, or remove firewall rules for NSX-T and VMware Cloud on-demand security groups. To add or remove a rule, select the security group in the topology pane, click the Action menu in the right pane, and select Reconfigure. You can now add, edit, or remove the rules. Existing security group Add, edit, or remove constraints for existing NSX-V, NSX-T, and VMware Cloud security groups. To add or remove a constraint, select the security group in the topology pane, click the Action menu in the right pane, and select Reconfigure. You can now add, edit, or remove the constraints.
Refresh Terraform State	Terraform Configuration	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Retrieve the latest iteration of the Terraform state file. To retrieve any changes that were made to the Terraform machines on the cloud platforms that they were deployed on and update the deployment, you first run this Refresh Terraform State action. To view the file, run the Get Terraform State action on the configuration. Use the deployment history tab to monitor the refresh process.
Remove Disk	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Remove disks from existing virtual machines. If you run the day 2 action on a deployment that is deployed as vSphere machines and disks, the disk count is reclaimed as it applies to project storage limits. Storage limits consider the actual capacity for thick and thin resource provisioning so that you cannot over-provision using thin provisioning. The project storage limits do not apply to additional disks that you added after deployment as a day 2 action.
Reset	Machines	Amazon Web Service Google Cloud Platform VMware vSphere	Deployed Onboarded	Force a virtual machine restart without shutting down the guest operating system.
Resize	Machines	Amazon Web Service Microsoft Azure Google Cloud Platform VMware vSphere	Deployed Onboarded	Increase or decrease the CPU and memory of a virtual machine.
Resize Boot Disk	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Increase or decrease the size of your boot disk medium. If you run the day 2 action on a deployment that is deployed as vSphere machines and disks, and the action fails with a message similar to “The requested storage is more than the available storage placement,” it is likely due to the defined storage limits on your vSphere VM templates and the content library that are defined in the project. Storage limits consider the actual capacity for thick and thin resource provisioning so that you cannot over-provision using thin provisioning. The project storage limits do not apply to additional disks that you added after deployment as a day 2 action.
Resize Disk	Storage disk	Amazon Web Service Google Cloud Platform	Deployed Onboarded	Increase the capacity of a storage disk. If you run the day 2 action on a deployment that is deployed as vSphere machines and disks, and the action fails with a message similar to “The requested storage is more than the available storage placement,” it is likely due to the defined storage limits on your vSphere VM templates and the content library that are defined in the project. Storage limits consider the actual capacity for thick and thin resource provisioning so that you cannot over-provision using thin provisioning. The project storage limits do not apply to additional disks that you added after deployment as a day 2 action. For the vSphere Storage DRS, you can relocate the virtual machine within the cluster of the current LUN lacks sufficient space.
	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed Onboarded	Increase or decrease the size of disks included in the machine image template and any attached disks.
Restart	Machines	Microsoft Azure	Deployed Onboarded	Shut down and restart a running machine.
Revert to Snapshot	Machines	Google Cloud Platform VMware vSphere	Deployed Onboarded	Revert to a previous snapshot of the machine. You must have an existing snapshot to use this action. If you created a snapshot for a Google Cloud Platform machine that included the attached disks, the full snapshot is reverted.
Run Puppet Task	Managed resources	Puppet Enterprise	Deployed Onboarded	Run the selected task on machines in your deployment. The tasks are defined in your Puppet instance. You must be able to identify the task and provide the input parameters.
Scale Worker Nodes	Tanzu Kubernetes clusters	VMware vSphere	Deployed Onboarded	Increase or decrease the number of Tanzu Kubernetes worker node virtual machines in your deployment.
Shutdown	Machines	VMware vSphere	Deployed	Shut down the guest operating system and power off the machine. VMware Tools must be installed on the machine to use this action.
Suspend	Machines	Microsoft Azure VMware vSphere	Deployed Onboarded	Pause the machine so that it cannot be used and does not consume any system resources other than the storage it is using.
Update	Deployments	Amazon Web Service Microsoft Azure VMware vSphere	Deployed Onboarded	Change the deployment based on the input parameters. For an example, see How to move a deployed machine to another network. If the deployment is based on vSphere resources, and the machine and disks include the count option, storage limits defined in the project might apply when you increase the count. If the action fails with a message similar to “The requested storage is more than the available storage placement,” it is likely due to the defined storage limits on your vSphere VM templates that are defined in the project. The project storage limits do not apply to additional disks that you added after deployment as a day 2 action. There are some properties that cannot be updated using this action. See Deployment properties that you cannot update using day 2 actions in VMware Aria Automation.
Update Salt Configuration	SaltStack Config resource	Amazon Web Service VMware vSphere	Deployed Onboarded	Add or change the Salt environment, apply state files, or provide variables for the selected Salt resource.
Update Tags	Machines and disks	Amazon Web Service Microsoft Azure VMware vSphere	Deployed Onboarded	Add, modify, or delete a tag that is applied to an individual resource.
Update Tanzu Version	Tanzu Kubernetes clusters	VMware vSphere	Deployed Onboarded	Update the current Kubernetes version to a later version.
Unregister	Machines	Amazon Web Service Google Cloud Platform Microsoft Azure VMware vSphere	Deployed (vSphere only) Onboarded	Unregister machines to remove them from VMware Aria Automation management and inventory. The machines are not removed from the cloud platform. Unregistered machines are available for onboarding. You can run the onboarding workflow to bring them back under management. For example, you might want to onboard a machine into a new project or a different VMware Aria Automation instance. Deployed vSphere machines considerations. You cannot unregister a machine that is part of a cluster or associated with a load balancer. These limitations avoid negatively affecting any scale-in or -out activities. The unregistered machine, along with any attached disks, is removed from VMware Aria Automation management. If you must continue to manage the disk, you can use the IaaS API to detach the disk before you unregister the machine. If a deployment has only one machine and you unregister the machine, the deployment remains in VMware Aria Automation. An unregistered machine can still be a discovered machine that you can onboarded, if needed. The machine is removed from VMware Aria Automation licensing and metering. The reservation quota and the storage limit are adjusted when the machine is no longer managed. When you unregister a machine, the IP address changes from ALLOCATED to UNREGISTERED in AUTOMATION. If the machine is re-onboarded, the IP address changes back to ALLOCATED. If an unregistered machine is deleted in vCenter, the IP address remains UNREGISTERED in VMware Aria Automation. To manually release the IP address, select Infrastructure > Resources > Networks. Select the IP Addresses tab and search for IP addresses where the status is Unregistered. Release the IP address as needed. All NAT rules that target the unregistered machine's NIC are removed from the NAT rules list in VMware Aria Automation when the machine is unregistered. If all the NAT rules target only the NICs on the machine that you want to unregister, the unregister fails. NAT needs at least one rule in the list. You can reconfigure the NAT rules or delete the NAT before you unregister the machine. No changes are made to the NSX DNAT or router configurations. Unregister extensibility events topics exist and pre and post unregister events are generated by the Event Broker Service. Onboarded machines considerations. The unregistered machine, along with the any attached disks, is removed from VMware Aria Automation management. After you remove the machine, you can then re-run the onboarding workflow for the unregistered machine. For example, you might want to onboard the resource again, this time to a new project. Missing machines considerations. The machine is listed as missing after migration or a backup and restore operation on the vCenter. Missing commonly means that the database record is unusable. You can unregister the missing machine to remove it from the database. The unregistered missing machine is not available for onboarding.