What actions can I run on Automation Assembler deployments or supported resources
Automation Assembler
deployments or supported resources After you deploy cloud templates, 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 policiesYou 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.
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.
Action | Applies to these resource types | Available for these cloud types | Resource origin | Description |
---|---|---|---|---|
Add Disk | Machines |
|
| 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 |
|
| 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 |
|
|
| 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 Display Name | Disk |
|
| Change the name of a
disk to a meaningful display name. This action changes
the display name in:
|
Change Lease | Deployments |
|
| 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 |
|
| 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 |
|
| 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:
Roles, considerations, and constraints for
deployments with deployed, migrated, onboarded, and hybrid/mixed
resources:
Roles, considerations, and constraints for
deployments with onboarded resources:
General considerations:
|
Change Security Groups | Machines |
|
| 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.
|
Connect to Remote Console | Machines |
|
| Open a remote session on the selected machine. Review the following
requirements for a successful connection.
|
Create Disk Snapshot | Machines and disks |
|
| Create a snapshot of
a virtual machine disk or a storage disk.
In addition to
providing a snapshot name, you can also provide the following
information for the snapshot:
|
Create Snapshot | Machines |
|
| 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 |
|
| 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 |
|
| Delete the NAT port forwarding rules from an NSX-T
or NSX-V gateway. | |
Machines and load balancers |
|
| Remove a machine or load balancer from a deployment. This action might
result in an unusable deployment. | |
Security groups |
|
| If the security is not associated with any machine
in the deployment, the process removes the security group from the
deployment.
| |
Tanzu Kubernetes clusters |
|
| Remove a Tanzu Kubernetes cluster from a
deployment. | |
Delete Disk Snapshot | Machines and
disks |
|
| Delete an Azure
virtual machine disk or managed disk snapshot. This action is
available when there is at least one snapshot. |
Delete Snapshot | Machines |
|
| Delete a snapshot of the virtual machine. |
Disable Boot Diagnostics | Machines |
|
| Turn off the Azure virtual machine debugging feature. This option is only
available if the feature is turned on. |
Disable Log Analytics | Machines |
|
| 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 |
|
| Add or modify resource tags that are applied to
individual deployment resources. |
Enable Boot Diagnostics | Machines |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| Power on the deployment. If the resources were
suspended, normal operation resumes from the point at which they
were suspended. |
Machines |
|
| Power on the machine. If the machine was
suspended, normal operation resumes from the point at which the
machine was suspended. | |
Reboot | Machines |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| Add, edit, or delete the NAT port forwarding rules
from an NSX-T or NSX-V gateway. | |
Security Groups |
|
| Add, edit, or remove
firewall rules or constraints based on whether the security
group is an on-demand or an existing security group.
| |
Refresh Terraform State | Terraform Configuration |
|
| 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 |
|
| 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 |
|
| Force a virtual machine
restart without shutting down the guest operating system. |
Resize | Machines |
|
| Increase or decrease the
CPU and memory of a virtual machine. |
Resize Boot Disk | Machines |
|
| 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 |
|
| 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 |
|
| Increase or decrease the size of disks included in
the machine image template and any attached disks. | |
Restart | Machines |
|
| Shut down and restart a running machine. |
Revert to Snapshot | Machines |
|
| 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 |
|
| 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 |
|
| Increase or decrease
the number of Tanzu Kubernetes worker node virtual machines in
your deployment. |
Shutdown | Machines |
|
| 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 |
|
| 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 |
|
| 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 |
|
| Add or change the Salt environment, apply state
files, or provide variables for the selected Salt resource. |
Update Tags | Machines and disks |
|
| Add, modify, or delete a tag that is applied to an
individual resource. |
Update Tanzu Version | Tanzu Kubernetes clusters |
|
| Update the current Kubernetes version to a later
version. |
Unregister | Machines |
|
| 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.
|