You use a workload onboarding plan to identify machines that have been data-collected from a cloud account type in a target region or data center but that are not yet managed by an Automation Assembler project.

When you add a cloud account that contains machines that were deployed outside of Automation Assembler, the machines are not managed by Automation Assembler until you onboard them. Use an onboarding plan to bring unmanaged machines into Automation Assembler management. You create a plan, populate it with machines, and then run the plan to import the machines. Using the onboarding plan, you can create a cloud template and can also create one or many deployments with or without existing cloud templates.

You can use resource placement in your onboarding plan to enforce resource limits that are defined in the cloud zones or the resource quota policies associated with the project. When you use resource placement, users can only select eligible discovered machines from the cloud zones associated with the project. Once you create the onboarding plan, the Use Placement option is read only.

You can onboard one or many unmanaged machines in a single plan by selecting machines manually.

  • You can onboard up to 3,500 unmanaged machines within a single onboarding plan per hour.
  • You can onboard up to 17,000 unmanaged machines concurrently within multiple onboarding plans per hour.

Machines that are available for workload onboarding are listed on the Discovered tab on the Resources > Virtual Machines page. Only machines that have been data-collected are listed. After you onboard the machines, they appear on the Managed tab as Onboarded. You can filter for onboarded machines by clicking the filter icon.

The person who runs the workload onboarding plan is automatically assigned as the machine owner.

Onboarding also supports onboarding custom properties, attached disks, changing deployment owners, and vSphere networks.
  • Resource Limits. You can enable onboarded workloads to respect and count against established resource limits.
  • Custom properties. You can set custom properties at the plan and at the individual machine levels. A custom property set at the machine level overrides the same property on the plan level.
  • Attached disks. If a machine has any non-bootable disks, they are automatically onboarded with the parent machine. To view non-bootable disks, click the machine name in the plan, and then navigate to the Storage tab.
  • Deployment ownership. Onboarding allows you to change the default deployment owner. To change the owner, select a deployment from the Deployment tab, click Actions > Change Owner, and select the desired user associated with the project.

For additional information on bulk VMware Aria Automation onboarding, see VMware Aria Automation bulk onboarding.

Onboarding examples

During onboarding, each added machine is placed in its own Automation Assembler deployment.

Note: As of VMware Aria Automation 8.18, onboarding no longer supports automatic generation of templates. Administrators must onboard either with or without a template. Onboarding to existing deployments is no longer supported.
You can deploy onboarded machines in three different ways:
  • Onboard a machine or a set of machines that are not associated with a cloud template and create a deployment out of them in Automation Assembler.

    Once the machines are onboarded, deployment owners can run most day 2 actions on the deployment, except the Update day 2 action.

    For an example of this onboarding technique, see Example: Onboard selected machines as a single deployment in Automation Assembler .

  • Onboard machines and associate them with an existing template.
    If user input is provided in the cloud template, the Update day 2 action is available for such deployments. Howеver, the Update action might provide a plan that original resources are deleted and then re-created based on the cloud template details.
    Note: The Update day 2 action might delete the original resources and recreate them based on the template.
  • Onboard machines with a cloud template and mapping.
    Use this option to create a deployment where the VM is mapped to the resources in the selected template. The deployment must have the same number of machines as the selected cloud template and you must map the template resources to the respective machines.
    Note: Mapping is supported only for plans with vSphere accounts. Only the Cloud.Machine and Cloud.vSphere.Machine resource types and their associated disks and networks are supported. Clustered machines are not supported.

    Running the Update day 2 action on the onboarded deployments applies the new changes to the existing resources. The original resources are only recreated if there are major changes between the current version of cloud template and deployment.

    For an example of this onboarding technique, see Example: Onboard machines with template and mapping.

Onboarding event subscriptions

A Deployment Onboarded event is created when you run the plan. Using Extensibility tab options, you can subscribe to these deployment events and perform actions on them.

After onboarding, you can update a project as a day 2 action for onboarded deployments. To use the change project action, the target project must use the same clound zone resources as the deployment. You cannot run the change project action on any onboarded deployments where you made changes after onboarding.

IP allocation during onboarding

When you onboard VMs, their associated networks get onboarded and IP addresses get allocated. You can verify that networks are onboarded correctly at Infrastructure > Resources > Networks > IP Addresses.

To ensure IP allocation during onboarding, verify the following:

  1. The IP address of the VM must be data collected.
  2. IP ranges must be created for the network associated with the VM.

    If the VM belongs to a vSphere NSX network, the IP ranges for the NSX network must be created.

  3. A record for the IP address must already exist on the IP Addresses page in Automation Assembler.
    • If a record exists, the IP address is available. Only available addresses get allocated.
    • If a record does not exist under IP Addresses, the IP is Available by default and is available for allocation.
  4. In case of external IPAM onboarding, the __Infoblox.IPAM.Migration.ExtensibilityKey and __IPAM.Migration.ExtensibilityKey custom properties must be added to the VM before running the onboarding plan.

    The values are the resourceIds of the VM. The resourceIds can be retrieved from Infoblox under the extensible attributes. This helps to deallocate the IP from Infoblox in case the VM is deleted in Automation Assembler.

Troubleshooting

If you encounter problems with onboarding plans in Automation Assembler, you can refer to this troubleshooting section to understand the problem or solve it, if there is a workaround.
Template is not available

Problem: You want to use a particular template, but the template is not available for selection during onboarding.

Solution:
  • Verify that the onboarding plan is created in the same project as the template you want to use.
  • Verify that the template is in a valid state with no errors.
Update day 2 action is not enabled

Problem: The Update day 2 action is not available for the deployment.

Solution:
  • Verify that the underlying template expects inputs. If it doesn't, then the Update day 2 action is not enabled for both provisioned and onboarded deployments with assigned templates.
  • Verify that there is a Day 2 policy created that applies to the deployment.
Update day 2 action shows updates to onboarded resources

Problem: The Update day 2 action/iterative deployment shows updates to onboarded resources.

Solution:
  • Verify that the machines were correctly mapped to the template resources.
  • Unregister the machines and then onboard them again with the correct mapping.