After you deploy a cloud template, you can run day 2 actions that change the deployment. Cloud Assembly includes many day 2 actions, but you might want to provide others. You can create custom resource actions and make them available to users as day 2 actions.

The custom resource actions can be based on vRealize Orchestrator workflows or extensibility actions. This example of a custom day 2 resource action is meant to introduce you to the creation process for vRealize Orchestrator based resource actions.

Prerequisites

Procedure

  1. Create a custom resource action that uses vMotion to move a vSphere virtual machine from one host to another.
    1. In Cloud Assembly, select Design > Resource Actions, and click New Resource Action.
    2. Provide the following values.

      Remember, except for the workflow names, these are sample values.

      Setting Sample Value
      Name vSphere_VM_vMotion

      This is the name that appears in the resource actions list.

      Display name Move VM

      This is the name that users see in the deployment actions menu.
    3. Click the Activate option to enable this action in the day 2 actions menu for resources that matches the resource type.
    4. Select the resource type and workflow that define the day 2 action.
      Setting Sample Value
      Resource Type Select the Cloud.vSphere.Machine resource type.

      This is the resource type that is deployed as a cloud template component, not necessarily what is in the cloud template. For example, you might have a cloud agnostic machine in your cloud template, but when it is deployed on a vCenter Server, the machine is Cloud.vSphere.Machine. Because the action applies to the deployed type, do not use cloud agnostic types when you define your resource actions.

      In this example, vMotion only works for vSphere machines, but you might have other actions that you want to run on multiple resource types. You must create an action for each resource type.

      Workflow Select the Migrate virtual machine with vMotion workflow.

      If you have multiple vRealize Orchestrator integrations, select the workflow on the integration instance you use to run these custom resource actions.

  2. Create a binding for the vRealize Orchestrator properties to the Cloud Assembly schema properties. Cloud Assembly day 2 actions support three types of bindings.
    Binding type Description
    in request The default value binding type. When selected, the input property is displayed in the request form and its value must be provided by the user at the request time.
    with binding action This option is available only for reference type inputs such as:
    • VC:VirtualMachine
    • VC:Folder

    The user selects an action that performs the binding. The selected action must return the same type as the input parameter. The correct property definition is ${properties.someProperty}.
    direct This option is available for input properties that use primitive data types. When selected, the property, with the suitable type, is mapped directly from the schema of the input property. The user selects the property from the schema tree. Properties with different types are inactive.
    In this use case, the binding is a vRealize Orchestrator action that makes the connection between vRealize Orchestrator VC:VirtualMachine input type used in the workflow and the Cloud Assembly Cloud.vSphere.Machine resource type. By setting up the binding, you make the day 2 action seamless for the user requesting the vMotion action on a vSphere VM machine. The system provides the name in the workflow so that the user does not have to do it.
    1. After selecting the Migrate virtual machine with vMotion workflow, navigate to the Property Binding pane.
    2. Select the binding of the vm input property.
    3. Under Binding, select with binding action.
      The findVcVmByVcAndVmUuid action is automatically selected. This action comes preconfigured with your vRealize Orchestrator integration in Cloud Assembly.
    4. Click Save.
  3. To save the changes to your day 2 action, click Create.
  4. To account for the other input parameters in the workflow, you can customize the request form that users see when they request the action.
    1. From Resource Actions, select your recently created day 2 action.
    2. Click Edit Request Parameters.
      You can customize how the request page is presented to users.
      Default Field Name Appearance Values Constraints
      Destination resource pool for the virtual machine. Default is the current resource pool.
      • Label = Target resource pool
      • Display type = Value Picker
      Destination host to which to migrate the virtual machine
      • Label = Target host
      • Display type = Value Picker
      		 Required = Yes
      Priority of the migration task Label = Priority of the task Value options
      • Value source = Constant
        In the text box, enter a comma-separated list. 
        lowPriority|Low,defaultPriority|Default,highPriority|High
      		 Required = Yes
      (Optional) Only migrate the virtual machine if its power on state matches the specified state Delete this text box.

      vMotion can move machines in any power state.
    3. Click Save.
  5. To limit when the action is available, you can configure the conditions.
    For example, you only want the vMotion action to be available when the machine has four or fewer CPUs.
    1. Toggle on Requires condition.
    2. Enter the condition.
      Key Operator Value
      ${properties.cpuCount} lessThan 4

      If you need complex conditions, see How to build advanced conditions for Cloud Assembly custom actions.

    3. Click Update.
  6. Verify that the Move VM action is available for deployed machines that match the criteria.
    1. Select Deployments.
    2. Locate a deployment that includes a deployed machine that matches the defined criteria.
    3. Open the deployment and select the machine.
    4. Click actions in the right pane and verity that the Move VM action exists.
      Example of the Move VM action in the Actions menu.
    5. Run the action.