Hol-2201-12-Cmp PDF en Simulation

HANDS-ON LABS MANUAL - 2022
HOL-2201-12-CMP
HOL-2201-12-CMP
Administering vRealize
Automation
HOL-2201-12-CMP: HOL-2201-12-CMP Administering vRealize Automation
Table of contents
Lab Overview - HOL-2201-12-CMP Administering vRealize Automation 4
Lab Guidance ...................................................................................4
Module 1 - Configuring Infrastructure in vRealize Automation (30 minutes) 7
Introduction......................................................................................7
Hands-on Labs Interactive Simulation: vRealize Automation Quick
Start ................................................................................................ 8
Logging in to vRealize Automation (HOLadmin) ................................. 9
Creating Cloud Accounts, Cloud Zones, and Projects ........................ 12
Creating Mappings and Profiles .......................................................44
Configuring Service Broker Content ................................................. 75
Conclusion......................................................................................89
Module 2 - Building Cloud Templates in vRealize Automation (30 minutes) 91
Introduction.................................................................................... 91
Logging in to vRealize Automation ...................................................92
Creating Your First Application Cloud Template ................................94
Cloud Template Iteration ................................................................ 112
Understanding Infrastructure With Tags ..........................................123
Conclusion.....................................................................................128
Module 3 - Managing Resource Infrastructure with Tags (15 minutes) 130
Introduction.................................................................................. 130
What Are Tags and Why Do We Need Them?................................. 130
Putting Tags to Use........................................................................136
Examine a Cloud Template with Tags ..............................................138

Test the Cloud Template.................................................................142
Test the Cloud Template Again ...................................................... 150
Conclusion..................................................................................... 157
Module 4 - Property Groups and Secrets (30 minutes) 160
Introduction.................................................................................. 160
Log in to vRealize Automation as holadmin...................................... 161
Using Property Groups to simplify cloud templates ..........................164
Using Secure Properties to securely store sensitive data ..................184
Conclusion....................................................................................205
Module 5 - Designing Custom Request Forms (30 minutes) 207
HANDS-ON LABS MANUAL | 2

Introduction.................................................................................. 207
Log into vRealize Automation ........................................................208
Customize a Request Form ............................................................ 210
Set Restrictions to a Text Field ........................................................ 211
Design a Computed Value Field......................................................214
Enable a Custom Request Form......................................................216
Test the Custom Request Form.......................................................218
Design a Drop-Down with an External Source................................. 224
Design a Conditionally Visible Field................................................ 233
Conclusion....................................................................................240
Module 6 - Policy-Based Lifecycle Management and Governance (30
minutes) 242
Introduction.................................................................................. 242
Open Chrome Browser.................................................................. 243
Logging in to vRealize Automation (HOLadmin) .............................. 243
Launch the Cloud Assembly Service ............................................... 245
Sharing Blueprints Between Multiple Projects ................................. 245
Configuring Policies in Service Broker ............................................ 257
Custom Forms in Service Broker .....................................................281
Consuming Custom Policies in vRealize Automation........................ 297
Conclusion................................................................................... 308
Appendix 310
Hands-on Labs Interface ............................................................... 310

Lab Overview - HOL-2201-12-CMP Administering vRealize Automation
Lab Guidance [2]
Note: It may take more than 90 minutes to complete this lab. You may only finish 2-3 of the modules during your time. However, you
may take this lab as many times as you want. The modules are independent of each other so you can start at the beginning of any
module and proceed from there. Use the Table of Contents to access any module in the lab. The Table of Contents can be accessed in
the upper right-hand corner of the Lab Manual.
In this lab, we will provide an overview of fundamental features available in vRealize Automation.
Lab Module List:
•Module
Module 1 - Configuring Infrastructure in vRealize Automation (30 minutes) - Basic - Explore infrastructure configurations in
Cloud Assembly and Service Broker. Configure the environment step-by-step for multi-cloud provisioning.
•Module
Module 2 - Cloud Templates in vRealize Automation (30 minutes) - Basic - Design your first cloud template in Cloud
Assembly, and explore provisioning and lifecycle management of your deployment.
•Module
Module 3 - Managing your resource infrastructure with tags (30 minutes) - Basic - Understand best practices in leveraging
tags to manage machine metadata.
•Module
Module 4 - Property Groups and Secrets (30 minutes) - Intermediate - Learn how property groups make it easy to set custom
properties and secrets provide encrypted values that project users may add to their cloud template designs.
•Module
Module 5 - Working with Custom Request Form Designer (30 minutes) - Basic - Use the custom request form designer in
Service Broker and discover how to create useful forms based on input parameters.
•Module
Module 6 - Policy-Based Lifecycle Management and Governance (30 minutes) - Basic - Assume the role of a Cloud
Administrator in Service Broker to create governance policies for users, and then consume those policies as a user.
Lab Captains:
•Trisha Navarro, Consulting Architect, USA
•Scott Bowe, Sr. Cloud Solutions Architect, USA
This lab manual can be downloaded from the Hands-on Labs document site found here:
http://docs.hol.vmware.com
This lab may be available in other languages. To set your language preference and view a localized manual deployed with your lab,
utilize this document to guide you through the process:
http://docs.hol.vmware.com/announcements/nee-default-language.pdf

First time using Hands-on Labs? [3]
Welcome! If this is your first time taking a lab navigate to the Appendix in the Table of Contents to review the interface and features
before proceeding.
For returning users, feel free to start your lab by clicking next in the manual.

You are ready....is your lab? [4]
Please verify that your lab has finished all the startup routines and is ready for you to start. If you see anything other than "Ready",
please wait a few minutes. If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

Module 1 - Configuring Infrastructure in vRealize Automation (30 minutes)
Introduction [6]
vRealize Automation 8.4 includes five primary components:
•Cloud
Cloud Assembly
Assembly, the blueprinting engine for vRealize Automation
•Service
Service Broker
Broker, the catalog for consumption of vRealize Automation and other resources
•Code
Code Stream
Stream, the pipeline and release orchestration engine
•Orchestrator
Orchestrator, the workflow engine of vRealize Automation
•Saltstack
Saltstack Config, the configuration management engine of vRealize Automation
While each component of vRealize Automation can be used individually, to get the most out of a deployment, proper configuration of
Cloud Assembly resources is required. In this module, we will explore configuration of Cloud Assembly resources as a cloud
administrator.
You will need approximately 30 minutes to complete all of the lessons within this module.
Lab Captain: Scott Bowe
Configuring Cloud Assembly [7]
Cloud Assembly consists of several resources, including Cloud Accounts and Zones, Image and Flavor Mappings, and Network and
Storage Profiles. Configuration of these resources allows blueprint designers to consume them. Proper configuration allows blueprints
to use these resources in a cloud agnostic manner - meaning that the same blueprint can be used across multiple clouds without the
need to modify the blueprints for each specific environment.

Introduction to Lab Scenario [8]
In this module, we will configure Cloud Assembly resources in 2 ways:
•QuickStart, a wizard-driven approach to configure connectivity to an on-premises vCenter Server and create a simple
blueprint.
•Manual configuration of resources in the infrastructure section of Cloud Assembly, following the Guided Setup flow shown in
the screenshot.
Hands-on Labs Interactive Simulation: vRealize Automation Quick Start [9]
This part of the lab is presented as a Hands-on Labs Interactive Simulation

Simulation. This will allow you to experience steps which are too time-
consuming or resource intensive to do live in the lab environment. In this simulation, you can use the software interface as if you are
interacting with a live environment.
1. Click here to open the interactive simulation. It will open in a new browser window or tab.

2.When finished, click the “Return to the lab” link to continue with this lab.
The lab continues to run in the background. If the lab goes into standby mode, you can resume it after completing the module.
Logging in to vRealize Automation (HOLadmin) [10]
In this lesson we will start by logging into vRealize Automation. We will be utilizing a blank tenant to walk through the configuration.
Launch vRealize Automation [11]
From within the Chrome web browser:
1. Click vRA Build from the bookmarks bar.
IMPORTANT - for this lesson you must select the 'vRA Build' link and not the 'vRealize Automation' link. vRealize Automation is
configured with two tenants in this environment. The 'vRA Build' tenant does not have any infrastructure configured yet - it will be used
in this lab lesson.

Select the login domain [12]
As this is the first time we have attempted to log into the vRA Build tenant, then we may be prompted to confirm which default domain
to use going forward. If we do not receive this screen and are prompted to logon, please move to the next step in the manual.
1. Ensure that corp.local is selected in the Select your domain pull down
2.Click Next

Log in to vRealize Automation [13]
At the Workspace ONE login screen:
1. Enter holadmin into the username field.
2.Enter VMware1! into the password field.
3.Click Sign In
In.

Creating Cloud Accounts, Cloud Zones, and Projects [14]
Now that we are logged into vRealize Automation, we can go through the configuration step by step and apply a basic configuration
using Guided Setup. We will start with Cloud Zones and Projects.
Navigate to Cloud Assembly [15]
1. Click the Cloud Assembly service tile
Guided Setup Diagram [16]
The Guided Setup Diagram provides us with an overview of the process of creating a working vRealize Automation configuration.
1. Click the Continue button to launch the Guided Setup Wizard to begin configuring vRealize Automation

Create a New Cloud Account [17]
As we progress through the Guided Setup, the Guided Setup Wizard, will provide contextual information about the step we are
currently on. Cloud Accounts specify the configured targets for provisioning of Cloud Assembly resources.
1. Click the vCenter cloud account tile to being adding

Configure Cloud Account [18]
1. For Name, enter Private Cloud
2.For vCenter IP address / FQDN, enter vcsa-01a.corp.local
3.For Username, enter [email protected]
4.For Password, enter VMware1!
5.Click VALIDATE
VALIDATE. This will verify connectivity to vCenter Server using the provided credentials. When the validation is
complete, a green "Credentials validated successfully" box will appear, and additional fields will appear below it.

Configure Cloud Account (Continued) [19]
1. Click the checkbox next to RegionA01 to allow provisioning to this datacenter.
Note that this vCenter Server only has one datacenter configured. In addition, when the RegionA01 checkbox is selected, a new
checkbox appears beneath it labeled "Create a cloud zone for the selected datacenters." This checkbox is automatically selected. We
will explore this cloud zone later in the lesson.
2.Note the NSX endpoint option. We will leave this value blank for this lesson, but when creating an NSX cloud account, it must
be associated with a vCenter cloud account. This will be covered in Module 9 of lab HOL-2201-10-CMP.
3.Click ADD (Note: it may be necessary to scroll down to see the Add and Cancel buttons)


Cloud Account Created [20]


The Private Cloud vCenter cloud account has been created. In order to see the resources this cloud account maps to in this
environment, we will log in to vCenter.
1. Click the + in the browser bar to open a new tab
2.Click the vSphere Client bookmark to open the login page
3.Check the box to Use Windows session authentication
4.Click LOGIN
View vCenter Datacenter [21]

1. Note the RegionA01 datacenter. When we created the Private Cloud cloud account, we configured Cloud Assembly to allow
provisioning to resources within this datacenter. As we continue with this lesson, we will specify how vRealize Automation will
provision new machines to the clusters in this datacenter.
2.Click the Cloud Assembly browser tab to return to Cloud Assembly
View Cloud Zones [22]

1. Use the scrollbar to scroll up to the top of the left menu
2.Click on Cloud Zones
3.Click OPEN to open the existing cloud zone
The Private Cloud / RegionA01 cloud zone was created automatically when we created the Private Cloud cloud account. Note that
cloud zones corresponding to the AWS and Azure cloud accounts do not exist at this time. First, we will configure the Private Cloud /
RegionA01 cloud zone, and after that, we will create cloud zones for AWS and for Azure.
Configure Private Cloud Cloud Zone [23]
1. Click on the Placement policy field, and change the value to SPREAD
2.Click on the Capability tags field, disregard the autocomplete, and type cloud:vsphere and press Enter. This will create a new
tag and apply it to this cloud zone.
By specifying a capability tag for this cloud zone, we can configure unique identifiers that Cloud Assembly blueprints can use as
constraints. Any deployment of blueprint with a constraint tag of cloud:vsphere will be directed to this cloud zone.
3.Click the Compute tab

Add Compute to Cloud Zone [24]
We only want to use the Workload 1 cluster in this vCenter datacenter. In order to specify only those clusters, we will add a new tag to
each cluster, and then filter on that tag.
1. Select Dynamically include compute by tags in the pull down.
2.Click the checkbox next to Workload 1 to select the cluster.
3.Click TAGS

Add New Tag to Clusters [25]
1. In the Add tags field, type compute:vsphere and press Enter

Enter. This will create a new tag to assign to the clusters.
2.Click SAVE
Filter On Tag [26]

1. In the Filter tags field, type compute:vsphere and press Enter

Enter. Applying this filter tag will reduce the list to only the Workload
1 cluster.
2.Click SAVE to save this cloud zone
View vCenter Resources [27]
1. Click the vSphere browser tab to return to vCenter
2.Note that the RegionA01 datacenter has 2 clusters: Management, Workload 1.
The Management cluster is dedicated to management workloads and as such, we do not want deployments to constrain resources in
this cluster. Therefore, we chose to use the Workload 1 cluster only. The Placement policy of SPREAD set in the Summary section of
the cloud zone allows for deployments to be distributed across multiple clusters if we were to add additional hosts to the environment.

Cloud Zones Created [28]
1. Cloud zones are configured for each cloud account in this environment. Note the capability tags present on each cloud zone -
blueprint consumers can specify these tags as constraints in their blueprints to easily direct deployments to specific cloud
zones.
2.Click Projects

Create New Project [29]
Projects are a collection of users, blueprints, provisioning targets (in the form of cloud zones,) and more.
1. Click + NEW PROJECT

Name Project [30]
1. For Name, type Private Cloud
2.Click on the Users tab

Add Users to Project [31]
Initially, no users or groups are assigned to this project. Users/groups can be assigned using one of three roles:
•Administrator
Administrator: Must have read and write access to the entire user interface and API resources. This is the only user role that
can see and do everything, including add cloud accounts, create new projects, and assign a project administrator.
•Member
Member: A user who does not have the Cloud Assembly Administrator role.
•In a vRealize Automation Cloud Assembly project, the administrator adds users to projects as project members. The
administrator can also add a project administrator. The permission for these two roles are defined below.
•Viewer
Viewer: A user who can see information but cannot create, update, or delete values. This is a read-only role.
•Users with the viewer role can see the blueprints and deployments for all projects regardless of project membership or
whether the project deployments are shared.
1. Click + ADD USERS

Add Holadmin User [32]
1. In the Users field, type holadmin and wait for the search to complete
2.Select Admin HOL - holadmin from the list

Configure Holadmin as Administrator [33]
1. Click Administrator to set holadmin as an Administrator for this project
2.Click ADD

Add Additional Users to Project [34]
1. Click + ADD USERS
Add Users as Members [35]

1. In the Users field, type holdev and wait for the search to complete to select Developer HOL
HOLfrom the list.
◦Repeat this process for holuser and select User HOL from the list.
2.Click Member to assign both holdev and holuser with the Member role.
3.Click ADD
Users Added [36]
Users have been added to this project. The holadmin user can configure resources in the project, and the holdev and holuser users can
consume them. Next, we will add resources to this project.
1. Click Provisioning

Add vSphere Cloud Zone [37]
Click the + ADD ZONE button (not shown) then Cloud Zone (not shown) to add the cloud zone we created earlier with the vSphere
integration.
1. Click on the Cloud zone field, and Cloud Zone and select Private Cloud / RegionA01
2.Click on Provisioning priority, and set the value to 1 (either by deleting the 0, or by using the up arrow on the right to
increment the value)
3.For Instances limit, enter 20
4.For Memory limit (MB), enter 32768
5.For CPU limit, enter 40
Note the Storage limit (GB) option, since this is a vSphere cloud zone. However, in this environment we will leave this value at 0, setting
no limit within the zone itself.
6.Click ADD

Cloud Zones Added to Project [38]
We have now added a cloud zone to the HOL Project project. Users in this project will be able to use the tags applied to each cloud
zone in their own blueprints in order to direct deployments to specific cloud zones.
1. Scroll down to see the rest of the Provisioning configuration options

Additional Provisioning Properties [39]
In addition to specifying cloud zones, priority, and optional limits per cloud zone, project provisioning can apply tags to deployed
resources, include specific constraints for network, storage, and extensibility configuration, apply custom properties to requests, specify
a project-specific custom naming standard for deployed objects, and set a project-wide request timeout for deployments that need
more than the default 2 hours.
1. For Custom Naming Template, type ${resource.name}-${###} (Note that it may be easier to copy and paste this value into
the lab by selecting it in the manual, and dragging and dropping into the lab environment itself)
If you type out the value above, note that the words inside the ${} will autocomplete. These are expressions, and they will be covered in
module 1 of lab HOL-2201-10-CMP.
2.Click CREATE to create the project

Add Integration to Project [40]
The HOL Project project has been created, and members assigned to this project can log in to Cloud Assembly and begin to create
blueprints. But why create new blueprints when we already have blueprints available in a GitHub repository? Next, we will add
integration with a GitHub repo to this project.
1. Scroll down in the left menu
2.Click Integrations
3.Click Add Integration

Add Gitlab Integration [41]
Integrations allow Cloud Assembly to leverage additional solutions. We will configure the integration with GitLab to enable access to
the HOL Lab Files GitLab repo. Other lessons will use the embedded-vRO and vr-operations integrations, and some lessons will
require new integrations to be created.
1. Click on the Gitlab integration tile.

Configure Gitlab Integration [42]
1. For Name
Name, enter gitlab.hol
2.For Server URL

URL, enter https://gitlab.hol [Please make sure you are NOT trying to reach gitlab.com]
3.Enter N_h5uVpXRXT3MnsXNcnt for Token
4.Click VALIDATE
a.Accept the SSL certificate that is presented by GitLab (not shown) to unlock the Add button
5.Click Add
We have now added an integration to GitLab, which will allow us to source cloud templates, and ABX actions into vRA directly from an
external repository.

Open GitLab Integration [43]
1. Click Open to open the integration to configure what content to synchronize

Add Project to Integration [44]
1. Click the Projects tab
2.Click + ADD PROJECT

Select Private Cloud Project [45]
1. Click on the Project field, and select Private Project
2.Click NEXT
Add Repository [46]

1. Click on the Type field, and select Cloud templates
2.For Repository, enter hol/rainpole
3.For Branch, enter main
4.For Folder, enter blueprints
5.Click ADD
View Repository Sync [47]
1. Click the > next to Private Cloud to view the settings and sync in progress
2.When the sync completes, the number of updated objects will be listed (not shown)
3.Since we are not changing the integration itself at this time, click CANCEL to exit

Return to Projects [48]
1. Scroll up in the left menu
2.Click Projects
3.Note the new parameter for HOL Project showing a number of available cloud templates
While the project is configured and cloud templates are available for users, we have more configuration to complete. In the next
lesson, we will configure mappings and profiles.

Creating Mappings and Profiles [49]
In the previous lesson, we configured a cloud zone for vSphere and assigned that zone to a new project. Cloud zones specify the
compute resources available to projects, but additional configuration is still needed in order for blueprints to make the most effective
use of resources across multiple clouds.
In this lesson we will configure mappings and profiles, completing the Cloud Assembly configuration.
Navigate to Flavor Mappings [50]
1. Click on Flavor Mappings

Create Flavor Mappings [51]
Flavor Mappings consist of sizes to use across multiple clouds. We will configure four flavor sizes for our environment. We will add a
configuration for the Private Cloud vSphere cloud zone to each mapping in this environment. If we needed to add additional cloud
zones you simply add the additional cloud zone to each flavor mapping that requires it.
1. Click + NEW FLAVOR MAPPING to create the first flavor mapping

Create Large Flavor Mapping [52]
1. In the Flavor name field, type large
2.Click on the Account/Region field in the new line and select Private Cloud / RegionA01
3.Click in the first Value field (Number of CPUs), and enter 2
4.Click in the second value field (Memory), and enter 4
When the large flavor mapping is specified for a machine in a blueprint, the specific sizes will be used:
•2
2 CPU and 4GB RAM if the machine is deployed to vSphere
5.We can click on the + to add flavor mappings for additional cloud zones, or the - to remove unneeded mappings
6.Click CREATE

Create Medium Flavor Mapping [53]
With the first flavor mapping configured, we will apply similar configurations to each of the remaining flavor mappings in this
environment, so that every flavor mapping will have a configuration for the Private Cloud / RegionA01 cloud zone in addition to AWS
and Azure.
1. Click + NEW FLAVOR MAPPING to create a new mapping for medium (not shown)
2.Click on the Account/Region field in the new line, and select Private Cloud / RegionA01
3.Click in the first Value field, and enter 1
4.Click in the second value field, and enter 2
5.Again, we can click on the + to add flavor mappings for additional cloud zones, or the - to remove unneeded mappings
6.Click SAVE

Create Small and Tiny Flavor Mappings [54]
We have created two flavor mappings for consumption by our cloud templates, we will repeat the instructions from the previous two
steps to create a flavor mapping for small and tiny. Create the flavor mappings using the following configuration sizes.
•small
◦CPU: 1
◦Memory: 1 GB
•tiny
◦CPU: 1
◦Memory: 512 MB

Create Image Mappings [55]
Image mappings detail the OS-specific images to use. Similar to flavor mappings, image mappings can be configured to include
options for each available cloud, allowing images to be specified in a cloud-agnostic manner in blueprints.
We will create three flavor mappings for our vSphere environment: Ubuntu 18, Ubuntu 20, and Windows 2019
1. Click on Image Mappings
2.Click + NEW IMAGE MAPPING

Create Ubuntu 18 Image Mapping [56]
The process for adding configurations to an existing flavor mapping is similar to image mappings.
1. Enter ubuntu18 as the image name.
3.Click on the Image field in the new line, and select ubuntu18 from the list
4.Click CREATE
5.We can click on the + to add image mappings for additional cloud zones, or the - to remove unneeded mappings

View Templates in vCenter [57]
1. Click on the vSphere browser tab to return to vCenter
2.In the vSphere Client, click the VMs and Templates icon to switch to the VMs and Templates view
3.Note the four templates available in this datacenter, including the ubuntu18 template used in the ubuntu18 image mapping.
The other three templates will be used in the next steps.
By default, Cloud Assembly will update the list of available templates in a vSphere cloud zone every 24 hours.

Create Ubuntu 20 Image Mapping [58]
The process for adding configurations to an existing flavor mapping is similar to image mappings.
1. Enter ubuntu20 as the image name.
3.Click on the Image field in the new line, and select ubuntu20 from the list
4.Click CREATE
5.We can click on the + to add image mappings for additional cloud zones, or the - to remove unneeded mappings

Create the remaining Image Mappings [59]
We have created two Ubuntu based image mappings, but as we observed in vCenter, there are two more templates available in
vCenter.
1. Repeat the steps we just executed for creating image mappings and create the following Image Mappings
a.Image Name: windows2019
b.Image Name: ubuntu20-mdisk
Image Mapping Updates Complete [60]

We created image mapping four our four vSphere templates: ubuntu18, ubuntu20, ubuntu20-mdisk, windows2019.
Next, we will create a network profile.
1. Click Network Profiles
Create New Network Profile [61]
Network profiles specify configuration for available networks in Cloud Assembly. Currently there are no network profiles configured.
1. Click + NEW NETWORK PROFILE

Configure New Network Profile [62]
1. Click on the Account / region field, and select Private Cloud / RegionA01 from the list
2.For Name, enter vSphere Networks
3.For Description, enter vSphere networks where VMs will be deployed
4.Click on the Capability tags field, type net:vsphere

net:vsphere, and press Enter to create a new tag for this profile
5.Click the Networks tab

Add Network to Profile [63]
Initially, no networks are assigned to this profile.
1. Click + ADD NETWORK

Add VM Network [64]
1. Click the checkbox next to VM-RegionA01-vDS-COMP
2.Click ADD to add this network

Network Added [65]
The VM-RegionA01-vDS-COMP network has been added to the profile. But what is this network? We will return to vCenter to see.
1. Click the vSphere browser tab

View vCenter Networks [66]
1. Click the Networking icon to change the view
2.Click the down arrow next to RegionA01 to expand it
3.Click the down arrow next to RegionA01-vDS-COMP to expand it
The networks from the previous step are shown here. This environment includes a distributed virtual switch (dvSwitch) named
RegionA01-vDS-COMP. This dvSwitch provides all networking for the hosts and VMs in the RegionA01 datacenter. The VM-
RegionA01-vDS-COMP network we chose in the previous step is a port group on this dvSwitch.

Configure Added Network [67]
In vRealize Automation terms, the newly added VM-RegionA01-vDS-COMP network is an existing network, since it was discovered by
vRealize Automation when we created the Private Cloud / RegionA01 datacenter. This network can be used as-is, but for machines
deployed on this network to have proper network configuration, we will need an external source (such as a DHCP server, or an IP
Address Management system) or additional configuration in vRealize Automation. In the next steps, we will configure more detail for
this network in vRealize Automation and add a range of IP addresses for vRealize Automation to assign and manage.
1. Click the VM-RegionA01-vDS-COMP network to open it

Add Network Configuration [68]
1. For Domain, enter corp.local
2.For IPv4 CIDR, enter 192.168.110.0/24
3.For IPv4 default gateway, enter 192.168.110.1
4.For DNS servers, enter 192.168.110.10
5.Scroll
Scroll down to apply additional configuration

Add Network Configuration (Continued) [69]
1. Click the checkbox next to Default for zone
2.Click on the Tags field, type net:vsphere

net:vsphere, and press Enter to add a new tag
Although initially this will be the only network available to this profile, setting a default and using tags are both ways to allow blueprint
creators to control the networks machines are deployed to.
3.Click SAVE

Add Managed IP Range to Network [70]
The configuration added in the previous step is now visible. But in this environment, we want vRealize Automation to manage IP
allocations for machines on this network.
1. Click the checkbox next to VM-RegionA01-vDS-COMP
2.Click MANAGE IP RANGES
Create New IP Range [71]

1. Click + NEW IP RANGE
Configure New IP Range [72]
1. For Name, enter vSphere Static Pool
2.For Description, enter For static IP assignment to deployed VMs
3.Click on the Start IP address field and change the IP to 192.168.110.225

4.Click on the End IP address field and change the IP to 192.168.110.254 (note that this IP might already be specified after
entering the Start IP address in step 3)
5.Click ADD

Network Range Added [73]
The network range has been added. Cloud Assembly will allocate IPs within this range to machines deployed using this network profile.
Additional networks can be added to the profile as needed, and networks can have multiple managed IP ranges, although they must
be from the same provider (either Cloud Assembly, or an external provider such as Infoblox.)
1. Click CLOSE to return to the network profile

Save Network Profile [74]
The network profile configuration for this exercise is complete. In later labs we will explore expanding network profiles by adding
existing networks, and by including options for creating on-demand networking and security.
1. Click CREATE

Network Profile Created [75]
1. Click Storage Profiles

Create New Storage Profile [76]
Like network profiles, storage profiles determine how storage within specific cloud zones is used.
1. Click + NEW STORAGE PROFILE

Configure Storage Profile [77]

1. Click on the Account / region field, and select Private Cloud / RegionA01
2.For Name, enter vSphere Storage
3.For Description, enter vSphere shared datastore where VMs will be deployed
4.Click on the Datastore / cluster field, and select RegionA01-iSCSI-COMP01 datastore from the list
5.Click on the Provisioning type field, and select Thin
6.Click the checkbox next to Preferred storage for this region
7. Click on the Capability tags field, type storage:vsphere

storage:vsphere, and press Enter to create a new tag
8.Click CREATE
Configuration Complete [78]

With the creation of the storage profile, the Cloud Assembly configuration is complete for this lesson. Next, we will create a
deployment of a blueprint that is designed to use this configuration.
1. Click the Design tab
Open Ubuntu 18 Cloud Template [79]
The blueprints synchronized from GitHub are available to be used.
1. Click on the Ubuntu 18 cloud template to open it

View and Deploy Ubuntu 18 Cloud Template [80]
The cloud template canvas and code sections include several of the tags we set for infrastructure objects in this lesson. This is how the
cloud template will consume the specific resources. For more information on cloud templates in Cloud Assembly, see module 2 in this
lab.
1. Click DEPLOY to begin the deployment process

Name Deployment [81]
1. For Deployment Name, enter vSphere Ubuntu
2.For Description, enter Deployment of vSphere vm from cloud template
3.Click DEPLOY

View Deployment In Progress [82]
1. The cloud template deployment process will take 3-5 minutes to complete. As the deployment starts, objects will appear on
the Topology canvas.

Deployment Complete [83]
When the deployment is complete, a green Create Successful message will appear. The deployed machine is now available for use.
Configuring Service Broker Content [84]
In previous lessons, we have applied Cloud Assembly configuration, imported blueprints from a GibHub repository, and created a
deployment using the Cloud Assembly configuration we've applied. But we are still missing Service Broker configuration, and the cloud
templates we've added to HOL Project are not yet available in the Service Broker catalog. In this lesson, we will release these cloud
templates to the catalog, import them into Service Broker, and share them with HOL Project so that project members can request
deployments through the catalog.

Return to Ubuntu The 18 Cloud Template [85]
Before we can share a cloud template with other projects (if we had any), we must enable it for sharing.
2.Click Settings

Allow the Cloud Template to be shared [86]
1. Click Allow an administrator to share with any project in this organization
2.Click Save

View the Cloud Template Version History [87]
1. Click on the Design tab. The Ubuntu 18 cloud template was previously opened, so it will still be shown.
2.Click VERSION HISTORY
Release Version 1 to Catalog [88]

Version 1 of this blueprint became available when we synchronized the project with the GitHub repository. With a version created, we
can release it to Service Broker.
1. Click RELEASE
Release Version 1 [89]
1. Click RELEASE again to finish the process of releasing the blueprint to Service Broker

Return to Cloud Templates List [90]
1. Click the left arrow next to the blueprint name to return to the blueprint editor
2.Click CLOSE (not shown) to close the blueprint and return to the blueprint list

Release Additional Cloud Templates [91]
NOTE: Recall that we are performing this lesson in a blank tenant, so while we will release the cloud templates the AWS and Azure
cloud templates will not function in this lesson. To release these blueprints, repeat our previous steps, starting with the AWS Machine
blueprint:
1. Click on AWS Machine to open the blueprint editor
2.Click on VERSION HISTORY
3.Click RELEASE to release version 1 of the blueprint to the catalog

4.Click RELEASE again to release the blueprint version
5.Click the left arrow to return to the blueprint editor
6.Click CLOSE to return to the blueprint list
Repeat this process for the Azure Machine blueprint, and then for the Cloud VM with Form blueprint. You can do this for other
blueprints in this list as well, if desired.

Navigate to Service Broker [92]
1. Click on the 9 dots in the upper right corner to open the menu
2.Click on Service Broker

Navigate to Content Sources [93]
Our first step in Service Broker is to create a new Content Source. This source can be a variety of types of objects, including Cloud
Assembly blueprints, Code Stream pipelines, and vRealize Orchestrator workflows, but also objects external to vRealize Automation
such as AWS CloudFormation templates.
1. Click on the Content & Policies tab
2.Click NEW to add a new Content Source

Select Content Source Type [94]
1. Click on VMware Cloud Templates

Configure Content Source [95]
1. For Name, enter HOL Cloud Templates
2.For Description, enter Released cloud templates in the Private Cloud project
3.Click on the Source project field, and select the Private Cloud project from the list
4.Click VALIDATE (a green box will appear with the number of items found matching the number of blueprints we released to
the catalog from within Cloud Assembly.)
5.Click CREATE & IMPORT

Validate Import from Content Source [96]
Although the Content Source has been added, import of discovered resources will not begin immediately.
1. Click the refresh icon in the upper right to refresh the view
2.After a few moments, the import will run and the Number of items column will show the same number of imported blueprints
and discovered blueprints (4/4 in this screenshot, since we released 4 blueprints to the catalog and Service Broker imported
all 4 successfully.)
Navigate to Content Sharing [97]

With the Content Source created and import complete, we will next share the content source with our HOL Project project.
1. Click on Content Sharing
2.Click on the Project field and select Private Cloud from the project list
3.Click + ADD ITEMS
Share Items with the Private Cloud Project [98]
1. Click the > to expand the list of items in the HOL Project Cloud Templates content source. All cloud templates previously
released from within Cloud Assembly and imported by the HOL Project Cloud Templates content source will appear in this
list.
2.Click the checkbox next to HOL Project Blueprints to select it
3.Click SAVE

View Catalog Items [99]
1. Click the Catalog tab to return to the Catalog, where all released cloud templates are now available to be requested.
2.On the Ubuntu 18 catalog item, click REQUEST

View Catalog Deployment Request [100]
The request itself contains the same fields as when we deployed it using the DEPLOY button from within Cloud Assembly.
You do not have to submit this request, but if you do, you will be taken to a list of deployments in the Deployments tab, with the same
layout as the Deployments tab in Cloud Assembly.
Conclusion [101]
In this module, we explored options for configuring Cloud Assembly resources in a cloud agnostic manner. With proper understanding
of these resources, we can make optimal use of Cloud Assembly blueprints.

You've finished the module [102]
Congratulations on completing the lab module.
If you are looking for additional information, see:
•Getting Started with vRealize Automation Cloud Assembly
•Building Your Resource Infrastructure
From here you can:
1. Click to advance to the next page and continue with the next lab module
2.Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
3.Click on the END button if you are done with the lab for now and want to exit

Module 2 - Building Cloud Templates in vRealize Automation (30 minutes)
Introduction [104]
Cloud Templates are a critical component to enabling multi-cloud automation and self-service. In this lesson we are going to look at
how to create a blueprint and adding tags to make then dynamic.
Learning Objectives:
•How to build a blueprint
•How to add infrastructure to a blueprint
•How to use tags for placement and resource allocation

Logging in to vRealize Automation [105]
In this lesson we will start by logging into vRealize Automation. In this lesson we will be utilizing the fully configured vRA tenant that is
part of the lab, as opposed to the blank tenant we configured in the previous lesson
1. Click vRealize Automation from the bookmarks bar.

3.Click Sign In
In.

Creating Your First Application Cloud Template [108]
Cloud Templates are our way of describing a topology of components that need to be provisioned for an application to run on. In this
section you will create a new blueprint and then work with some pre-configured abstractions to control where (and in some cases how)
these components are provisioned.
1. Click on Cloud Assembly.
The Cloud Assembly service orchestrates and expedites infrastructure and application delivery in line with DevOps principles. So, we
will create a blueprint from the Cloud Assembly tile.
Create a New Blueprint [110]

1. Click on the Design tab to open up the initial Blueprints page.
You will note that there are a number of actions here apart from just the ability to create or delete a blueprint. We will explore the other
options later in this lab. For now, please:
2.Click on the + New button, to launch the cloud template design menu
3.Click on Blank Canvas

Canvas, to create a new blueprint
Add Cloud Template Details [111]
On this page, you need to enter some basic details about your cloud template. In the context of this lab, the amount of information that
you provide here is not going to have significant impact on how you use the product. However, in a production environment where the
number of blueprints that you have would increase, adding details in the Description field becomes far more useful, as you can search
against this information.
1. In the Name field, type My First App

App.
2.In the Project drop-down, select HOL Project

Project.
3.Click the Create button.

Exploring the Cloud Template Canvas [112]
The cloud template canvas is split up into three main sections:
1. The Components panel, where you select the components that you want to use for your application.
2.The Canvas, where your application infrastructure topology is represented.

3.The Editor where your YAML will be presented and modified.
There are two other useful items to be aware of on this page that will help you with managing screen real estate.
4.The Components hide/show button; and
5.The Editor hide/show button. You may have noticed that the red box expands all the way across the bar, and not just on the
button. This has been done because you can click anywhere on the bar to minimize these panels. Hide or show these panels
as you see fit throughout the lab to make viewing relevant content easier.

Add a vSphere Cloud Machine [113]
1. Drag a Machine object from the vSphere section onto the canvas.
2.You will see the YAML description automatically populated. Hover your mouse over the properties field. You will notice that it
is a hyperlink. Click on it and see that you get a list of all available properties that can be defined for this object type. After you
are done looking at the content in the pop-up box, click anywhere in the blueprint area to close the pop-up box.
◦Note how the YAML editor highlights syntax errors, in this case it's informing us that the image property does not
have a valid value

Edit the YAML Description [114]
1. Click between the single quotes on the image field. You will see the list of images that have been defined in vRealize
Automation and have been made available to the Project you are working in
2.Click to select Ubuntu18

Ubuntu18. Note that if there were other Image Mappings available for this project, they would also be displayed
in the list.
◦Note that once we select a image, the syntax error is cleared

Add a Constraint [115]
Constraints allow you to specify parameters that must match a tag on the infrastructure (a Cloud Zone for example). The constraint is a
way to force vRealize Automation to only deploy the blueprint to infrastructure that has a matching tag.
1. Place your cursor after the totalMemoryMB: 1024 property and press the Enter key to add a new line in your YAML that is
aligned under the properties section then type con and pause so see the auto-populate options
2.Click to select constraints: from the list

Add a Constraint Tag to the Virtual Machine [116]
In our environment, we have applied the "compute:vsphere" tag to our two compute clusters in the vRA-Managed vSphere Compute
cloud zone but not to our management hosts or cluster. By using that constraint tag in our blueprint, we will ensure that the virtual
machine gets provisioned to our compute clusters and not to our management cluster.
1. Press the Enter key to add a new line under constraints:
2.Click tag: to add a tag constraint

3.Click the compute:vsphere tag to select it
Note that you could also have typed the tag value here and if the tag had not previously been defined in vRealize Automation, it would
have been created at that point.
Be aware that YAML is whitespace sensitive, and incorrect indenting may lead to issues with provisioning. If you do make a mistake, you
should see a red exclamation appear beside the line where the mistake has been made. Try it out now if you like by adding an extra
space before image
image. Resolve the error and move to the next page.
Add a Network [117]
Since we will want our virtual machine to be attached to a network, we need to add a network object to the blueprint.
1. Drag a Network object from the vSphere section onto the canvas.
2.To attach your Machine object to the network, hover over the white circle on the left-hand side of the
Cloud_vSphere_Machine_1 box, and then click and drag the circle onto the Cloud_vSphere_Network_1 box.
3.You will see the YAML definition for the network itself and for the networks section added to your VM resource.

Our Configured Network Profile [118]
In this environment we have configured the vsphere-networks Network Profile with three different networks that were discovered in
vSphere. There is no need to verify this but if you want to, you can do so on the Infrastructure tab.
1. In the image, note that we have applied the "net:vsphere" tag (as well as some others) to the VM-RegionA01-vDS-COMP
vSphere network. This is the network we will want to attach our machine to so we will be using this tag.
2.In addition, note that for the above network, we have defined an IP range from 192.168.110.200-192.168.110.189. This range
will act as a pool from which vRealize Automation can assign static IP addresses to virtual machines using this network

Configure the Network [119]
Now it's time to configure the network object.
1. Use what you have learned about YAML editing to add a new entry on the vSphere Machine object under -network to set the
IP address assignment to static
2.Use what you have learned about YAML editing to add a new constraint tag "net:vsphere
net:vsphere" to the vSphere Network object

Finish Your Blueprint [120]
1. Once that is complete, click on the VERSION button to begin the versioning process.

Version Your Blueprint [121]
Now that your basic configuration has been setup, it would be a good idea to capture the state it is in as a version 1 blueprint.
1. In the Version field set it to 1
2.In the Change log text box, type Initial Configuration

Configuration.
3.Click on CREATE
CREATE.
We will look at versioning in more detail later in the lesson, including how you can identify differences between versions.

Test Your Blueprint [122]


1. Click on Test to validate your blueprint.
Close the test window once you have validated the blueprint.
Deploy Your Blueprint [123]
It's time to deploy the blueprint.
1. Click the DEPLOY button

Deployment Information [124]
1. In the Deployment name field, enter simple blueprint

blueprint.
2.Select Current Draft in the Blueprint Version field.
3.Click on the DEPLOY button.

Explore Your Deployment [125]
The deployment will take a few minutes to come up. Note that due to browser zoom and rendering in this lab environment, you might
not see the linkage between the vSphere Machine and the vSphere network in the topology diagram. Rest assured that the linkage is
still there.
1. Once the deployment has successfully deployed, you will see the status change to "Create
Create Successful
Successful". You may need to click
the refresh icon to the right of the Actions drop-down in order to get the status to update.
2.Click on the Cloud vSphere Machine object to highlight it
3.Take a look at the information panel to the right.
a.Your deployment should be powered on and you can see details about the virtual machine.
b.Expand the deployed virtual machine to expose additional information about the virtual machine
4.Note that the machine will have an IP address assigned from the static IP pool we saw above

If you want to, you can open a new browser tab, log in to the vSphere Client and see the machine being deployed there.
Username
Username: [email protected]
Password
Password: VMware1!
View Available Actions [126]
In the information panel, you can also access a list of actions that you can take on the virtual machine
1. Click the Actions link to see the list of available actions. Note that this list can be modified via policies in the Service Broker
module of vRealize Automation.
2.Click Connect to Remote Console
This will open a new tab in your browser with a remote console session to the deployed virtual machine. You can log in if you want
(login: root / Password: VMware1!) and run a command like ip addr show to verify the assigned IP address.
When you are done with the console, just close the console browser tab.

Cloud Template Iteration [127]
Cloud Templates are our way of describing a topology of components that need to be provisioned for an application to run on. In this
section you will create a new blueprint and then work with some pre-configured abstractions to control where (and in some cases how)
these components are provisioned.
Increase the Number of Machine Instances [128]

We are now going to modify the blueprint to increase the number of deployed virtual machines to two.
1. Click On the Blueprints tab,
2.Click the vSphere Machine on the canvas to select it
3.In the panel, click Properties to open the properties pane. Note that if you find it easier to build and modify your blueprint
with forms and fields instead of by editing YAML code, you might prefer to work in this tab.
4.Click the toggle to Show all properties
5.In the Count field, change the value to 2
6.Note that on the canvas, the image for the vSphere machine changes from a single box to stacked boxes. This is an indication
that the object count is greater than one.
7. You can click on the Code tab if you want and see that the YAML definition was updated with the count: 2 property
8.Click TEST to test your blueprint for proper syntax
Test Results [129]
1. Your blueprint test should return Successful

Successful. If it doesn't, address the issue before proceeding.
2.Click the X to close the test window

Version Your Blueprint [130]
Let's version the blueprint
1. Click the VERSION button
2.In the Version field, set the version 2
3.In the Change Log text box, type Changed VM count to 2
4.Click the CREATE button

Update the Deployment [131]
vRealize Automation gives you the option of updating an existing deployment. So instead of having to delete or current deployment
with a single VM, we can update the deployment by applying this revised blueprint.
1. Click the DEPLOY button
2.From the deployment type drop-down select Update an existing deployment

deployment.
3.In the Blueprint version field, select version 2
4.Click the radio button next to simple blueprint
5.Click the NEXT button.

View the Plan [132]
At this stage, you will be notified of additions, changes or deletions that will occur.
1. Expand the Adds and Deletes sections to see what changes will be made to the deployment
2.Click the DEPLOY button

Wait Patiently [133]
This will take a little longer.
1. As the provisioning is progressing, click History to expand the request history.
Request History [134]
You will see all the task list and request in progress related to your request and how long it takes.
1. Click on Provisioning diagram link

Navigation of Request Details [135]
1. Scroll down to review the request information.
2. Click the Dev mode toggle to see additional information
If you have a resource mapping issue, you will see the resource error on this view.

Request Details in Dev mode [136]
Navigate the Request Details to get familiar to the request workflow.
1. Close the provisioning diagram when you are done exploring the page
If the request failed, you should be able to see on this view which steps in your blueprint have problems.

Clean Up [137]
Once your deployment updates successfully, you can explore the details either here on the deployment page or in the vSphere Client.
To ensure you have enough resources for future tasks in this lab, you will need to clean up your deployment.
1. Click on the Actions drop-down
2.Click to Delete the deployment
a.Click Submit on the confirmation dialog (not shown)
3.We are going to take another look at versioning, so click on the Design tab.

Cloud Template Version History [138]
The version history for each blueprint is stored with the blueprint.
1. In order to access it, click on Version History.
Reviewing Version Differences [139]

1. To get started, select version 2.
2.Click Diff to see the differences between the versions
3.In the Diff against drop-down, select 1.
This shows the differences in the YAML between the two blueprint versions. Scroll down and take a look at the changes that have
occurred. The detailed diff is quite valuable but doesn't lend itself to a quick view of what has changed.
4.Click on Diff Visually
Visual Differences [140]
Now this is a nice way to see what changed between versions!
Wrapping it Up [141]
In this lesson, you learned how to configure Cloud Assembly to get it ready for provisioning, how to navigate the blueprint canvas to
create, version and deploy blueprints.
Next up, we will configure all of the abstractions that are required in order to provide cloud agnostic blueprints - blueprints that can be
deployed to different public and private clouds depending on conditions.

Understanding Infrastructure With Tags [142]
We have used constraint tags in the last two lessons to dictate where (which cloud zones) vRealize Automation placed the objects when
our cloud templates were deployed.
In this lesson, we are going to spend some more time exploring tags and discussing some best practices around managing your tags.
You will discover a new way to manage your virtual machine metadata. Fundamentally, tags are labels that you add to vRealize
Automation Cloud Assembly items. You can create any tags that are appropriate for your Organization and implementation. Tags
function as much more than labels though, because they control how and where vRealize Automation Cloud Assembly uses resources
and infrastructure to build deployable services. Tags also support governance within Cloud Assembly.
Tags are a critical component that drive the placement of deployments through the matching of capabilities and constraints so you must
carefully plan and implement an appropriate tagging strategy based on your organizations IT structure and goals to maximize Cloud
Assembly functionality and minimize potential confusion.
Tag Overload [143]

In the new platform, there are tags, capability tags, constraint tags, standard tags, project tags, project constraint tags, and custom
properties. There is a bit of tag overload going on here. Some of these tags are used when making placement decisions, while others
propagate from higher level objects and go on to set tags on the endpoint itself, and some do not propagate. Each of the referenced
tag types are defined as follows:
•Capability
Capability tags: enable you to define placement logic for deployment of infrastructure components.
•Constraint
Constraint tags: apply to cloud templates and various other components within vRealize Automation Cloud Assembly to
match capabilities defined on resources, cloud zones, and profiles to generate appropriate deployments.
•Standard
Standard tags: unique within vRealize Automation Cloud Assembly. These tags are stored as system custom properties, and
they are added to deployments after provisioning.
•Project
Project Resource Tags: A project resource tag operates as a standardized identifying tag that you can use to manage the
deployed resources and ensure compliance.
•Project
Project Constraint Tags: A project constraint operates as a governance definition. It is a key:value tag that defines what
resources the deployment request consumes or avoids in the project cloud zones.
Tag-based Capability and Constraint Functionality [144]
The primary function of tags is to configure deployments using capabilities and constraints. These are really the same thing, just
referred to differently based on what you’re doing and where you are in the Cloud Assembly interface.
•Capability
Capability Tags are used in Cloud Accounts, Integrations, Cloud Zones, Network/Storage Profiles
•Constraint
Constraint Tags are used in Image Profiles, Projects and Cloud Templates
Capability tags placed on cloud zones, network and storage profiles, and individual infrastructure resources define desired capabilities
for deployments.
Constraint tags that cloud administrators place on projects enable them to exercise a form of governance over those projects. These
constraint tags are added to other constraints expressed in cloud templates.
Typically, you would create tags for things like:
•Different platforms: AWS, Azure, vSphere
•Different compute resources: linux-cluster, windows-cluster, database-cluster
•Different environments : PROD, DEV, TEST
•Storage tags: Tier 1/Tier 2/Tier 3, Gold, Bronze, Silver, SSD
•Networking tags: DMZ, public, private appX-net
During provisioning, Cloud Assembly matches these capabilities with constraints in cloud templates to define deployment configuration.
This tag-based capability and constraint functionality serves as the foundation for deployment configuration in Cloud Assembly (e.g.,
you can use tags to make infrastructure available only on specific resources in a particular region).
NOTE: Tags also facilitate search and identification of storage items, network items, and other infrastructure resources.

Constraint Tag Types [145]
There are two main areas where constraint tags are applicable.
•The first is on the configuration side in projects and images.
•The second is on the deployment side in cloud templates.
Constraints applied in both areas are merged in cloud templates to form a set of deployment requirements.
Constraints in both projects and cloud templates can be of the following types:
•hard
hard - rigidly enforced
•soft
soft - preferred if available
•!! - negative / not logic
By default all constraints are hard. Hard constraints allow you to rigidly enforce deployment restrictions. If one or more hard constraints
are not met, the deployment will fail. Soft constraints express preferences that apply if available, but they won't fail if not met.

Discovered External Tags [146]
External Tags are imported automatically from public cloud accounts that you associate with a vRealize Automation 8 instance. These
tags might be imported from vSphere, AWS, Azure or other external endpoints. When imported, these tags are available for use in the
same manner as user created tags.
Network Resource Tags are written back to provisioned resources when they are created in the cloud infrastructure and contain key/
value pairs.
Be careful when modifying or creating/naming tags in AWS on subnet resources. These will be synced back to vRealize Automation 8 in
the network profile.
NOTE: Take care not to create tags and values in your AWS console that might be used for placement decisions in vRealize Automation
8.

Standard Tags [147]
Standard tags are applied to some deployments to support analysis, monitoring, and grouping of deployed resources. These tags are
used under the hood by vRealize Automation for internal sorting and when calculating placement decisions.
Standard tags are unique within vRealize Automation. Unlike other tags, users do not work with them during deployment configuration,
and no constraints are applied. These tags are applied automatically during provisioning on AWS, Azure, and vSphere deployments.
Standard tags are automatically stored as system custom properties, and they are added to deployments after provisioning.
How Do Tags Work [148]
Cloud Assembly uses a specific order and hierarchy in resolving tags to create provisioned deployments. Understanding the basics of
this process will help you to implement tags efficiently to create predictable deployments.
•Cloud
Cloud zones are filtered by several criteria, including availability and profiles
profiles; tags in profiles for the region the zone belongs
to are matched at this point.
•Zone and compute capability tags are used to filter the remaining cloud zones by hard constraints
constraints.
•Out of the filtered zones, priority is used to select a cloud zone. If there are several cloud zones with the same priority, they
are sorted by matching soft constraints

constraints, using a combination of the cloud zone and compute capabilities.
•After a cloud zone is selected, a host is selected by matching a series of filters, including hard & soft constraints as expressed
in cloud templates.
If tags on the project conflict with the tags in the cloud template
template, the tags from the project take precedence.
Similar to priority matches, if multiple resources meet a hard constraint, soft constraints are used as a tiebreaker to select the actual
resource used in the deployment.

Conclusion [149]
In this module, we explored options for configuring Cloud Assembly resources in a cloud agnostic manner. With proper understanding
of these resources, we can make optimal use of Cloud Assembly blueprints.

•Getting Started with vRealize Automation Cloud Assembly
•Building Your Resource Infrastructure
From here you can:

Module 3 - Managing Resource Infrastructure with Tags (15 minutes)
Introduction [152]
Tags are a critical component of vRealize Automation Cloud Assembly that drive the placement of deployments through matching of
capabilities and constraints. We must understand and implement tags effectively to make optimal use of vRealize Automation Cloud
Assembly.
In this lesson, we will dive into some best practices for implementing an appropriate tagging strategy based on your organization's IT
structure and goals.
Lab Captain: Trisha Navarro
What Are Tags and Why Do We Need Them? [153]
Fundamentally, tags are labels that we add to vRealize Automation Cloud Assembly items. We can create any tags that are appropriate
for our organization and implementation.
Tags function as much more than labels, because they also control how and where Cloud Assembly uses resources and infrastructure to
build deployable services. Tags also support governance within Cloud Assembly.
While tagging serves several common purposes, our tagging strategy must be tailored to our deployment needs, structure, and goals.

Tagging Overload [154]
In vRealize Automation Cloud Assembly, there are capability tags, constraint tags, standard tags, project tags, project constraint tags,
and custom properties. There is a bit of tagging overload going on here. Some of these tags are used in placement decisioning, some
of them propagate from higher level objects and go on to set tags on the endpoint itself, and some of them do not. Each of the
referenced tag types are defined as follows:
•Capability
Capability tags enable us to define placement logic for deployment of infrastructure components.
•Constraint
Constraint tags apply to cloud templates and various other components within vRealize Automation Cloud Assembly to match
capabilities defined on resources, cloud zones, and profiles to generate appropriate deployments.
•Standard
Standard tags are unique within vRealize Automation Cloud Assembly. These are stored as system custom properties, and
they are added to deployments after provisioning.
•Project
Project Resource Tags operate as a standardized identifying that you can use to manage the deployed resources and ensure
compliance.
•Project
Project Constraint Tags: A project constraint operates as a governance definition. It is a key:value tag that defines what
resources the deployment request consumes or avoids in the project cloud zones.

Tag-Based Capability and Constraint Functionality [155]
The primary function of tags is to configure deployments using capabilities and constraints. These are really the same, just named
differently based on what we are doing and where we are in the Cloud Assembly interface.
•Capability
Capability Tags are used in cloud accounts, integrations, cloud zones, network/storage profiles
•Constraint
Constraint Tags are used in image profiles, projects and cloud templates
Capability tags placed on cloud zones, network and storage profiles, and individual infrastructure resources define desired capabilities
for deployments.
Constraint tags that cloud administrators place on projects enable them to exercise a form of governance over those projects. These
constraint tags are added to other constraints expressed in cloud templates.
Typically, you would create tags for things like:
•Different platforms: AWS, Azure, vSphere
•Different compute resources: linux-cluster, windows-cluster, database-cluster
•Different environments : PROD, DEV, TEST
•Storage tags: Tier 1/Tier 2/Tier 3, Gold, Bronze, Silver, SSD
•Networking tags: DMZ, public, private appX-net
During provisioning, Cloud Assembly matches these capabilities with constraints in cloud templates to define deployment configuration.
This tag-based capability and constraint functionality serves as the foundation for deployment configuration in Cloud Assembly (e.g.,
We can use tags to make infrastructure available only on specific resources in a particular region).
NOTE: Tags also facilitate search and identification of storage items, network items, and other infrastructure resources.
Constraint Tag Types [156]
There are two main areas where constraint tags are applicable.
•The first is on the configuration side in projects and images.
•The second is on the deployment side in cloud templates.
Constraints applied in both areas are merged in cloud templates to form a set of deployment requirements.
Constraints in both projects and cloud templates can be of the following types:
•hard - rigidly enforced
•soft - preferred if available
•! - negative / not logic

By default, all constraints are hard. Hard constraints allow you to rigidly enforce deployment restrictions. If one or more hard constraints
are not met, the deployment will fail. Soft constraints express preferences that apply if available, but they won't fail if not met.
Synced Tags [157]
The tags property (not to be confused with the constraint tag) allows for the addition of tags for deployed resources in the
corresponding public cloud account (AWS, Azure, etc.).
It supports tags on the following resources:
•Machines
•Volumes
•Load balancers
•Network (does not appear unless using an on-demand network)
Tags are case sensitive

sensitive.
Tags are synched both ways

ways, to and from the remote cloud account to the Cloud Assembly Tags Management list.

Discovered External Tags [158]

External Tags are imported automatically from public cloud accounts that you associate with a vRealize Automation instance. These tags
might be imported from vSphere, AWS, Azure or other external endpoints. When imported, these tags are available for use in the same
manner as user created tags.
Network Resource Tags are written back to provisioned resources when they are created in the cloud infrastructure and contain key/
value pairs.
Be careful when modifying or creating/naming tags in AWS on subnet resources. These will be synced back to vRealize Automation in
the network profile.
NOTE: Take care not to create tags and values in your AWS console that might be used for placement decisions in vRealize Automation
Cloud Assembly.
Standard Tag [159]
Standard tags are applied to some deployments to support analysis, monitoring, and grouping of deployed resources. These tags are
used under the hood by vRealize Automation for internal sorting and when calculating placement decisions.
Standard tags are unique within vRealize Automation. Unlike other tags, users do not work with them during deployment configuration,
and no constraints are applied. These tags are applied automatically during provisioning on AWS, Azure, and vSphere deployments.
Standard tags are automatically stored as system custom properties, and they are added to deployments after provisioning.

Tag Processing Hierarchy [160]
Cloud Assembly uses a specific order and hierarchy in resolving tags to create provisioned deployments. Understanding the basics of
this process will help you to implement tags efficiently to create predictable deployments.
•Cloud
Cloud zones are filtered by several criteria, including availability and profiles
profiles; tags in profiles for the region the zone belongs
to are matched at this point.
•Zone and compute capability tags are used to filter the remaining cloud zones by hard constraints
constraints.
•Out of the filtered zones, priority is used to select a cloud zone. If there are several cloud zones with the same priority, they
are sorted by matching soft constraints

constraints, using a combination of the cloud zone and compute capabilities.
•After a cloud zone is selected, a host is selected by matching a series of filters, including hard & soft constraints as expressed
in cloud templates.
If tags on the project conflict with the tags in the cloud template
template, the tags from the project take precedence.
Similar to priority matches, if multiple resources meet a hard constraint, soft constraints are used as a tiebreaker to select the actual
resource used in the deployment.
Putting Tags to Use [161]
Let's Play [162]
Now that we have covered the various kinds of tags that exist within vRealize Automation Cloud Assembly, let's put them to use.
We will start by logging into vRealize Automation.
1. Click vRealize Automation from the bookmarks bar

Log into vRealize Automation [164]
1. Enter username holadmin
2.Enter password VMware1!
3.Click Sign In

Examine a Cloud Template with Tags [165]
Let's look at an example of a cloud template that utilizes multiple constraint tags.
1. Click on Cloud Assembly

Edit the Cloud Template [167]
2.Click the cloud template name Ubuntu 18 with Tags to open it for editing

Review the Cloud Template [168]
The cloud template consists of the following:
1. An on-prem (vSphere) VM
2.A cloud VM
3.The on-prem VM is attached to a network
This hybrid cloud template is designed to create a VM in vSphere, and a VM in the public cloud.

Review the YAML Code [169]

On the right-most pane, review the YAML code:
1. The inputs are presented on the request form, to be selected at the time of provisioning.
2.Each virtual machine has constraint tags defined such that their names are computed by concatenating the input parameters
with other string values and dictate placement logic. Notice that some tags have been defined as hard or soft.
3.The on-prem VM has a env tag defined which will be added as vSphere Tag on the provisioned virtual machine.
4.The network also has a constraint tag for the network, which is hardcoded to net:vsphere.
Be careful when you mix and match soft and ! constraints as you are letting the deployment engine “loosely” chose placements for
your resource, especially for multi-resource cloud templates.
Test the Cloud Template [170]
Let's run a test to simulate how the contraint tags of the cloud template impact placement for a deployment.
Test How Tags Impact Placement for the Cloud Template [171]
1. Click the TEST button on the bottom left of the cloud template design canvas

Please do not deploy any virtual machines here. The Test functionality will allow us to observe the necessary settings without the need
to deploy.
Cloud Template Inputs [172]
The request form for the cloud template will require user input of a T-Shirt Size
Size, the Platform
Platform, and the Environment
Environment.
•Because of the limitations of resources in the lab, the VM sizes are "tiny
tiny" and "small
small". However, these choices will not affect
the provisioning of the virtual machines.
•The platform choice is limited to Amazon (AWS) and vSphere

vSphere.
•The environment is limited to just dev for a development instance.
1. Set the platform to vSphere
2.Click TEST
It will take a moment for the test to run.

Review the Test Results [173]
1. Once the test has completed, you should see a successful result highlighted in green.
2.A really cool feature of the testing functionality is the ability to observe the Provisioning Diagram. Click this link.

Request Details [174]

The request details will display the various objects that make up the provision request.
1. The details start with the NETWORK ALLOCATION
2.Observe that the vSphere Networks network profile was selected for allocation because of the net:vsphere aggregated tag
Recall that the YAML code defined the on-prem VM to be configured on an existing network with the constraint that it must have the
tag net:vsphere
net:vsphere.
Virtual Machine Details [175]
1. Click MACHINE ALLOCATION
2.In the drop-down, click onpremvm-...

On-Prem VM Details [176]
Review the details of the virtual machine.
1. Notice the constraint tags for each of the objects.
Scroll down to the Cloud Zone allocation.

Placement is decided by matching the constraint tags with the appropriate objects:
1. The tag cloud:vsphere was matched with the request, placing this machine on the vSphere platform
Select the Cloud VM [177]

Scroll up and select the other virtual machine.
1. Click MACHINE ALLOCATION
2.Click cloudvm-...
Cloud VM Details [178]
Again, review the details of the objects that were selected for the virtual machine.
1. Take note of the constraint tags for each of the objects
Scroll down to the Cloud Zone allocation.

1. Notice the constraint tags that matched for this object were cloud:aws and env:dev
◦The hardcoded value for the tag forces aws to always be selected, no matter which platform was chosen.
2.Click CLOSE
Test the Cloud Template Again [179]
Let's run another test to simulate how selecting a different value for one of the inputs impacts the computed contraint tags of the cloud
template, and thus changes the placement for a deployment.

Return to the Cloud Template [180]
Now let's run the test again, but on AWS platform this time.
1. Return to the Design tab
2.Close the test window
3.Click TEST to run another test

Try the Test Again [181]
1. This time, set platform to aws
2.Click TEST

Provisioning Diagram [182]
Once the test completes,
1. Click Provisioning Diagram
Select the On-Prem VM [183]

The details will again start with NETWORK ALLOCATION

ALLOCATION. Feel free to review the details of the network allocation before proceeding
further.
1. Select MACHINE ALLOCATION
2.In the drop-down, click onpremvm-...
On-Prem Details [184]
Scroll down to the cloud zone allocation.
1. Notice the unmatched constraint cloud:aws:soft
Even though we chose the aws platform, the on-prem VM was allocated to the vSphere cloud zone since the unmatched constraint is a
soft constraint.

Select the Cloud VM [185]
1. Select MACHINE ALLOCATION

ALLOCATION.
2.In the drop-down, click cloudvm-...

Cloud VM Details [186]
Scroll down to the cloud zone allocation.

Again, notice that the cloudvm is placed in Amazon (AWS). It was placed here for the same reason as the first test: The hardcoded tag
forces AWS to always be selected, no matter which platform was chosen.
Conclusion [187]
This lesson demonstrated that tags are more prevalent and more powerful than ever in vRealize Automation Cloud Assembly. Tags can
be used to formulate a computer hostname, or as shown, can help determine placement of virtual machines during deployment. Tags
are driven by business needs and requirements. It is recommended to carefully plan, map out, educate, and implement an appropriate
tagging strategy based on those needs to maximize vRealize Automation functionality.
A couple of recommendations for your tagging strategy:
•There is no one rule or naming convention for how and where to create tags
•Keep them simple and descriptive

Want to learn more about tags? Here's a few links that can help you with the subject (each link opens in a new window):
•VMware Cloud Assembly Deep Dive in under 60 minutes
•Understanding and Using Tags

•AWS Tag Naming Strategies
•Using constraint tags in Cloud Assembly
•Cloud template expression syntax in vRealize Automation Cloud Assembly
•How to use expressions to make cloud template code more versatile in vRealize Automation Cloud Assembly
From here you can:


Module 4 - Property Groups and Secrets (30 minutes)
Introduction [190]
vRealize Automation 8.4 includes a new type of objects call property groups and secure properties. These were introduced in vRealize
Automation 8.3. In this lesson we will review these objects before walking through an example use case of each.
In this module we will examine how to properly leverage both Property Groups and Secure Properties.
Property Groups [192]

Property Groups enhance Cloud Templates allowing users to save time by reusing pre-defined properties. Property Groups can be both
inputs and custom properties with pre-defined data. An example use case for a property group is to create a reusable list of values for a
pull-down menu, or a variable that will be referenced in multiple cloud templates but controlled in a single definition.
Secure Properties [193]
You can manage encrypted secrets variables AKA Secure Properties within the project scope and use in cloud templates. ABX actions
can use now encrypted input values called “Secrets” for protecting sensitive data, such as passwords or certificates. An example use
cases for Secrets within vRealize Automation might include defining a password to set for a user as a resource is deployed.
Log in to vRealize Automation as holadmin [194]
In this lesson we will start by logging into vRealize Automation.


3.Click Sign In
In.

Using Property Groups to simplify cloud templates [197]
The templating language of vRealize Automation allows us to create cloud templates inputs that present the user with a predefined list
of inputs to choose from. As you create blueprints you may find that many of these variables are used across multiple blueprints.
Inputs sets such availability zone, operating system, flavor size, and others. Prior to using property groups, you had to curate the list of
potential values in all cloud templates. Property Groups allow you to define and manage these input sets centrally, greatly reducing the
administrative burden in managing multiple cloud templates.
Let's explore using property groups to define an input set centrally instead of on each blueprint.
1. If you have not closed the Quickstart

Quickstart, click the X to close it for the remainder of the lab
2.Click on Cloud Assembly

Open a Cloud Template with a form [199]
1. Click Design
2.Open the Cloud VM with Form cloud template by click on the link

Examine our input menu [200]
1. This cloud template has an input defined named image

image. It has two possible values Ubuntu18 and Windows 2019.
2.The image property of the cloud template references the selected value of the input by referencing the variable input.image
3.Click TEST to view the input form
1. Click CANCEL (not shown)
4.Click CLOSE

Create an input property group [201]
The two property groups are handled differently in Cloud Assembly and we will review how both types work.
To locate the property groups;
1. Navigate to Cloud Assembly (if not already there)
2.Click on Design
3.Select Property Groups
4.Click + NEW PROPERTY GROUP to create a new property group
NOTE: If you don't have Property Groups already configured, you would see this image with the two options for the group types we
discussed earlier.



Complete the details of the Property Group by inputting the following values:
1. Ensure that Input Values is selected.
2.Enter a name for the property group. Example pgInput

pgInput.
3.Provide a Display Name for the Property Group. Example Form Inputs
4.(Optional) Provide a detailed description so that others may know what the property group is for.
5.Select the appropriate Project that can utilize the Property Group. Example HOL Project
Project.
6.Once completed, click on New Property

Property.

Create a input property [202]


1. Enter image for name.
2.Enter Image to Deploy for display name
3.(Optional) Enter a description for the property
4.Enter Ubuntu18 as the default value for the property
5.Enter Windows2019 as a value in the enum field
6.Enter Ubuntu18 as an additional value
7. Click Create
8.Click Create ((not shown) to create the property group
Repeat this process to add a second or third input property to our form. Try creating an integer property and explore how you can
provide not just a default value, but a minimum and maximum value!

Navigate back to a cloud template [203]
1. Click Design
2.Click Cloud Templates

Update the Cloud Template [204]
We will reference our new input property group by using it to replace the current image input field. By using property groups to define
our inputs, we are able to curate a standard set of inputs and potential values across many cloud templates from a central administrative
point.
Leverage the YAML editor's auto-complete function to make editing easier!
1. Comment out lines 5-10 (they will be replaced by our property group)
2.Paste the following lines in:
a.pgInput: type: object title: Standard Inputs description: Inputs defined through a standard
property group $ref: /ref/property-groups/pgInput
3.Update the image reference to'${input.pgInput.image}'

'${input.pgInput.image}'
4.Click TEST to view the updated menu

We've successfully created a property group that can be utilized to provide a standardized and centrally managed set of inputs across
multiple cloud templates. Next we will create a property group, that contains constant variables for us to reference!
Create an constant property group [205]
NOTE: We will now create a property group that contains constants. We can use these within our cloud templates to define standard
values such as constraints, custom properties, etc. We will be using the to create a centralized constant to reference a cloud target
within a constraint on our Cloud Template.

2.Click on Design
4.Click + NEW PROPERTY GROUP to create a new property group


Complete the details of the Property Group by inputting the following values:
1. Ensure that Constant Values is selected.
a.Confirm that you want to change the property group type (not shown)
2.Enter a name for the property group. Example pgConstant

pgConstant.
3.Provide a Display Name for the Property Group. Example: Cloud Template Constants
4.(Optional) Provide a detailed description so that others may know what the property group is for.
5.Select the appropriate Project that can utilize the Property Group. Example: HOL Project
Project.
6.Once completed, click on New Property

Property.

Cloud Target Property Creation [206]
Create the new property by inputting the following values.
1. Enter a cloudTarget for the name of the property.
2.(Optional) Provide a description for the property.
3.Enter vsphere for the value
4.Click Create
Create.
5.Click Create to save the property group (not shown)
Repeat this process to add a second (or third) standard constant to our property group!

1. Click Design

We will reference our new constant value property, by using it to replace the constraints on the compute target and network target.
This allows you to perform administrative actions such as updating your tagging taxonomy without having to update all blueprint
references to a specific tag.
1. Remove vsphere from the constraint, and replace it with ${propgroup.pgConstant.cloudTarget}
2.Remove vsphere from the constraint, and replace it with ${propgroup.pgConstant.cloudTarget}
3.Click TEST to view the updated menu
Test VM Form [209]
Performing a test allows us to validate that vRealize Automation is able to successfully resolve our constraints to deploy a virtual
machine.

1. Complete the form
2.Click Test

After a few moments, we should receive a success notice for our simulation, indicating that vRealize Automation successfully resolved
the property group to determine the compute and network constraints for our request.
Using Secure Properties to securely store sensitive data [210]
Secrets is a broad term used to define sensitive data in computer systems. When performing a task such as deploying a new virtual
machine secrets are used in creating user accounts or configuring an application as it is installed. Within vRealize Automation Secure
Properties give us a simple and easy way to encrypt them to reduce the chances of them becoming exposed in our cloud templates.
In this section we will use secure properties to securely define the password of a user created on a server at deploy time. We will
explore two different methods of passing a secure property to a cloud template: Form input and vRA secrets. Additionally, we will
explore on how you can set a custom property at the project level to pass to extensibility.
Let's get started!

Update input property group [211]
2.Click on Design
4.Click pgInput to open the property group we created in the previous lesson


1. Click + NEW PROPERTY to add a new property
1. Enter sshUser as the property name
2.Enter a display name to appear on the form, such as Username
3.Enter a default value for the user name, such as sshuser
4.Click Create
5.Click + NEW PROPERTY again, to create a property to store the password (not shown)

1. Enter sshUser as the property name
2.Enter a display name to appear on the form, such as Password
3.Click the check box to indicate that this is an encrypted value
a.This will lock us out from entering a default value, requiring the user to enter a value!
4.Click Create
5.Click
Click SAVE to save the property group (not shown)

vRealize Automation warns us that updating this property group will result in an update to all versions of our blueprints. Make sure to
properly communicate form changes to your customers to prevent surprises and/or unintended outcomes!

1. Click Design

We will make a simple update to our cloud template to reference the username and password to create a user and set it's password on
our deployed VM.
1. Paste the following lines in after the hostname line in the cloudconfig section
ssh_pwauth: True
users:
- name: '${input.pgInput.sshUser}'
shell: /bin/bash
sudo: ['ALL=(ALL) NOPASSWD:ALL']
chpasswd:
list: |
${input.pgInput.sshUser}:${input.pgInput.sshPassword}
2.Click DEPLOY to view the updated menu

1. Enter a deployment name such as PasswordPrompt
2.Click NEXT

1. Ensure that select that Ubuntu18 is selected
2.Enter a value for the user to create such as: sshuser
3.Enter a password
4.Enter a hostname for the operating system being deployed.
5.Enter a value for the cost center input
6.Click DEPLOY
The deployment will take a few minutes.

Check the result of the deployment [214]
1. When the deployment is complete, click on the virtual machine in the topology view.
2.Expand the Cloud Config section of the resource details
3.Notice how the value entered for the password is not rendered in plain text - keeping it secure!
While the value is not displayed in plain text in the properties, let's examine what vRA record as the inputs to the request

1. Click History
2.Click Request details
3.Notice how vRA displays the input as ***** indicating that it is an encrypted input.
Create a vRA Secret [215]
Next we will create an encrypted property that can be referenced on a larger scale. Secrets created in this way are constrained by
project, similar to secrets in CodeStream
1. Click Infrastructure
2.Click Secrets
3.Click + NEW SECRET to launch the Create Secret window

1. Select HOL PROJECT
2.Enter a name for the secret, such as secretPassword
3.Enter a value for the password, such as VMware123!
4.You can click the eyeball icon to toggle masking of the input field
5.Click CREATE to create the secret.
Secrets are created and scoped to a particular project! This allows us to create multiple secrets with the same name, but scoped to
different projects, allowing us to standardize how they are referenced on cloud templates, but contain different values depending on
the who deploys a resource.
Create an encrypted custom property [216]
Finally, we will examine how we can create an encrypted custom property at the project level. This could be useful to pass sensitive
information such as a password or API key for use in extensibility.

1. Click Infrastructure
2.Click Projects
3.Click OPEN

1. Click Provisioning
2.Enter a name for the custom property, such as: projectPassword
3.Enter a value to encypt, such as VMware1!
4.Check the Encrypted box
a.Checking the box will cause vRA to mask your input value.
Update Cloud Template [217]
Let's update our cloud template to use the vRA Secret as the password instead of our input, and add the custom property to the
blueprint.

1. Click Design

1. Update line 52 to reference ${secret.secretPassword} from the value we set previously
2.Click DEPLOY
Notice that we don't reference our custom property that we defined on the project - as that will be automatically inserted by vRA at
execution time!

Deploy a Test VM [218]
1. Enter a deployment name such as PasswordTest 2
2.Click NEXT

1. Ensure that select that Ubuntu18 is selected
2.Enter a value for the user to create such as: sshuser
3.Enter a password
a.Our goal is to deploy a VM using the password from the secret - so enter gibberish here - to make it easier to test!
4.Enter a hostname for the operating system being deployed.
5.Enter a value for the cost center input
6.Click DEPLOY
The deployment will take a few minutes.

1. When the deployment is complete, click on the virtual machine in the topology view.
2.Expand the Cloud Config section of the resource details
a.Note that the value is different then our previous hashed value (ending in sw==) - indicating that a different
password was used
3.Expand Custom Properties and scroll down to locate the property projectPassword

Notice that the value is masked and not visible to the user, but will be available for user like all other custom properties through our
extensibility!
Validate the passwords were applied [219]
During this lesson we deployed we deployed two virtual machines - both of which were configured to have a user added named
sshuser
sshuser, with passwords set via two different methods of storing secure values within vRA. Use putty to ssh into both deployed systems
and validate the password was set properly!
Summary [220]
In this lesson we reviewed how you can use encrypted properties to securely store sensitive data, while making it available to
extensibility and the deployed virtual machine during start up.
This allows us to perform functions like setting a users password, authenticating to an API using a password or API Key - and many
other use cases.

Conclusion [221]
In this module ... <YOUR TEXT HERE>. Summarize what was covered.
Congratulations on completing the lab module. In this module we learned how you can use property groups to simplify your cloud
templates by centralizing input sets, allowing you to propagate changes to your required inputs across multiple cloud templates. We
also learned how you can store and utilize sensitive data within vRA, both by prompting the user for it and creating centralized secrets
to reference across many blueprints.
If you are looking for additional information about custom properties or secure properties in vRealize Automation, here are some
suggested web pages.
https://blogs.vmware.com/management/2021/02/ca-secure-properties.html
https://blogs.vmware.com/management/2020/12/introducing-vrealize-automation-property-groups.html

From here you can:

Module 5 - Designing Custom Request Forms (30 minutes)
Introduction [224]
vRealize Automation Service Broker allows us to customize the request form for the items in our catalog.
In this module, we will demonstrate how to customize the request form, design the input parameters that allow the user requesting a
catalog item to provide the values, and customize how the custom options are presented in the form.
Lab Captain: Trisha Navarro
Example of a Custom Request Form [225]

In the upcoming exercise, we will build the custom request form displayed here.
We will restrict the hostname text field to alphanumeric characters and define a minimum and maximum length. We will see that if any
of these restrictions are violated, the form will display a useful error message so that the end-user can correct their input value.
Next, we will hide the default deployment name field, and then define it to set the deployment name based on the inputted hostname.
This way, the end-user doesn't have to spend the time deciding on a deployment name--it will be calculated for them.
We will also leverage a vRealize Orchestrator workflow to dynamically populate the cost center drop-down.
Finally, we will make the cost center field hidden or visible depending on the image selected. In this scenario, we will pretend that the
cost center is only for Windows machines.
This exercise should give you a solid foundation for creating dynamic, flexible custom request forms for your catalog.
Let's begin.
We will start by logging into vRealize Automation.

1. Enter username holadmin
2.Enter password VMware1!
3.Click Sign In

Customize a Request Form [229]
Let's navigate to the custom request form designer for the cloud template we want to customize.
1. Click on Service Broker

Navigate to the Custom Request Forms Designer [231]
To add or modify custom forms in Service Broker:
1. Click the Content & Policies tab
2.Click Content
3.For Cloud VM with Form

Form, click its vertical ellipses button
4.Click Customize form (not shown)
Set Restrictions to a Text Field [232]
Now that we are in the custom request form designer, let's start with a basic feature for custom request forms: Setting restrictions to a
text field.

Design a Custom Form Text Field [233]
We'll start by defining the behavior of the hostname field:
1. Click the Hostname field in the design palette

Define Constraints of a Field [234]
Let's restrict the length and set of characters that can be entered for the hostname field:
1. On the right-hand side, click the Constraints tab
expression, type ^[a-zA-Z0-9]*$

2.For Regular expression
◦This restricts the hostname field to alphanumeric

3.Click the caret next to Regular expression to expand its options
message, enter Alphanumeric characters only

4.Under Validation error message
5.For minimum value, type 6
◦This means the hostname must be at least 6 characters in length
6.For the maximum value, type 15
◦This means the hostname must be no more than 15 characters in length
That was easy. Now let's try something more interesting.

Design a Computed Value Field [235]
Now let's define the deployment name as a computed value based on other, more useful fields, so that the user doesn't have to bother
inputting it.
Define a Field As Hidden [236]
We will first make the deployment a hidden field:
1. Click the Deployment Name field in the design palette
2.On the right-hand side, the Appearance tab is selected by default
3.For the Visibility field, select No

Design a Computed Value Field [237]
Next, we will set the deployment name based on the inputted hostname:
1. Click the Values tab
2.Click Default value to expand its options
3.For Value source

source, select Computed value
4.For Operator
Operator, select Concatenate
5.Click ADD VALUE
6.Under the new Constant field that appears, type Deployment-
7. Click ADD VALUE once more, then for the new Constant field that appears, change it to Field
Field, then select the blank space to
the right

In the Select string popup:
1. Select Canvas fields > Hostname
2.Click SELECT
Enable a Custom Request Form [238]
Now that we've made our changes to the request form, let's save and enable the form so that we can look at the customizations from
the catalog.

Enable the Custom Request Form [239]
The custom form won't be displayed to the end user until it is enabled.
1. Notice the form is currently in DRAFT mode
2.At the top of the design canvas, click ENABLE
Enabled Custom Request Form [240]
1. Notice the custom request from status is enabled.

Save the Custom RequestForm [241]
Finally save the changes we have made to the custom form.
1. At the bottom-left of the custom request form designer, click SAVE
Test the Custom Request Form [242]
Finally, it's time to test out our custom form from the service catalog.

Test the Customized Form [243]
1. Click Catalog
2.Find the Cloud VM with Form catalog item tile and click REQUEST

Test Minimum Length Constraint [244]
1. In the Hostname field, type cloud
2.When an error icon is displayed, mouseover it
Note that the error message notifies us that the entry violates the minimum length for the field.

Test Maximum Length Constraint [245]
1. In the Hostname field, enter cloud12345abcdef
Note that the error message notifies us that the entry violates the maximum length for the field.

Test Regular Expression Constraint [246]
1. In the Hostname field, enter cloud@
Note that the error message notifies us that the entry is invalid, and we see the validation error message, Alphanumeric characters only
only,
which we provided for the regular expression validation error message.

Test Computed Value [247]
1. For project, select HOL Project
2.For Image, select Ubuntu18
3.In the Hostname field, type cloudmod5
Center, enter 123456

4.For Cost Center
5.Click SUBMIT

View the Deployment Name [248]
We are automatically redirected to the Deployments tab.
1. Verify that the name of our latest deployment name is computed as Deployment-cloudmod5
As expected, the deployment name is the concatenation of "Deployment-" and the hostname we inputed.
There is no need to wait for the deployment to complete, since the build may take a few minutes.
Design a Drop-Down with an External Source [249]
Now let's enhance our form once more with a drop-down populated via an external source, a vRealize Orchestrator action.

Launch vRealize Orchestrator Web Client [250]
Launch the vRealize Orchestrator web client:
1. Click the VMware Cloud Services menu in the top-right corner
2.Click Orchestrator

Explore a vRealize Orchestrator Action [251]
One of your integration engineers has built an action that will provide a list of cost centers.
To inspect the action:
1. Under Library
Library, click Actions
2.In the Filter... field, type getCostCenters and press ENTER
3.Find the getCostCenters action and click OPEN

Review the Action [252]
1. Click the Script tab
2.Notice that the Return type is a Properties object
◦Note:
Note: Returning a Properties object allows us to display a user-friendly string for each drop-down value, while a
different underlying value will be saved as the cost center value. A string array type is also an accepted return type
for custom form external sources, such that the value that is displayed in the drop-down is the same value that will
be saved as the cost center value.
3.When you are finished reviewing the action, click CLOSE
The script here employs a simplistic way to obtain random values to populate a Properties object for the purposes of demonstration,
but you could have a script that does something much more interesting, like make REST or database calls to obtain values from an
external source of truth.

Return to Service Broker [253]
Return to Service Broker:
1. Click on the Cloud Services menu in the top-right corner
2.Click Service Broker

Go to the Content Forms Designer [254]
Let's modify our Cloud VM with Form custom form once more:
2.Click Content


Set a Drop-Down Field [255]
Let's update the Cost Center field to use our vRealize Orchestrator action:
1. Click the Cost Center field in the design palette
2.In the Appearance tab, change Display type to DropDown

Set the DropDown External Source [256]
2.Click Value options to expand its menu
3.Set Value source to External source
action, start typing the name of our action, getCost and wait for the list to populate
4.For Select action
5.When the getCostCenters action appears in the search results, select it
6.At the bottom-left of page, click SAVE (not shown) to save the changes to the custom form

Now we will test out our custom form from the service catalog.
1. Click Catalog

Test the External Source DropDown [258]
1. Click the Cost Center field to view its values
This is a great way to dynamically retrieve data values from a single source of truth.
There is no need to submit another deployment request at this time.
For our final demonstration, we'll look at making a field visible based on the selected value of another field.
Design a Conditionally Visible Field [259]
Let's modify our Cloud VM with Form custom form one final time to demonstrate a conditionally visible field.

Return to the Content Forms Designer [260]
2.Click Content


Set Conditional Visibility [261]
Let's update the Cost Center field so that it is only visible and mandatory if the Windows image is selected. Otherwise, it will be hidden
and non-mandatory.
1. Click the Cost Center field in the design palette
2.In the Appearance tab, click Visibility to expand its options
3.For Value source

source, select Conditional value
4.For Set value

value, select Yes
5.For If
If, select the first field

Base Conditional Visibility on Image Field [262]
In the Select any pop-up:
1. Select Canvas fields > Image
2.Click SELECT

Set Conditional Visibility, continued [263]
1. For the next If field, select Equals
2.For the last If field, enter Windows2019

3.Click ADD EXPRESSION
4.Repeat the previous steps to define another expression:
1. Set value = No
If = Image Not equal Windows2019

2.If
5.At the bottom-left of page, click SAVE (not shown) to save the changes to the custom form
We've effectively defined the cost center field to be visibile only when the Windows2019 image is selected.

Now we will test out our custom form from the service catalog.
1. Click Catalog

Test the Visibility of Cost Center for Windows2019 [265]
1. Set Image to Windows2019
2.Notice Cost Center is visible

Test the Visibility of Cost Center for Ubuntu18 [266]
1. Set Image to Ubuntu18
2.Notice Cost Center is hidden again
This is a useful way to only display relevant fields based on other field values.
Conclusion [267]
We have just demonstrated various ways we can design a custom form to enhance the end-user experience:
We restricted a text field to alphanumeric characters with a minimum and maximum length, hid the deployment and defined it to set the
deployment name based on the inputted hostname, leveraged a vRealize Orchestrator workflow to dynamically populate a dropdown,
and then made a field hidden or visible depending on another field value.
This should give you a solid foundation for creating dynamic, flexible custom request forms for your catalog.

If you are looking for additional information, visit the product documentation at Learn more about vRealize Automation Service Broker
custom forms.
From here you can:

Module 6 - Policy-Based Lifecycle Management and Governance (30 minutes)
Introduction [270]
In this module, we will explore the Service Broker component of vRealize Automation. As an administrator, we will leverage policies
and custom forms to provide governance and customization, and as an end user, we will see what governance looks like.
Service Broker in vRealize Automation 8.4 can import content from a variety of sources, including external sources such as
CloudFormation templates. Users can request deployments of this content from the Service Broker catalog. Policies in Service Broker
add governance by adding approval requirements, lease options for deployments, and specific day 2 actions available, all based on a
variety of conditions.

Open Chrome Browser [272]
Open Chrome Browser from Windows Quick Launch Task Bar [273]
1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.
Logging in to vRealize Automation (HOLadmin) [274]
In this lesson we will start by logging into vRealize Automation.

3.Click Sign In
In.

Launch the Cloud Assembly Service [277]
Use this for launching the cloud assembly service in your modules
Launch the Cloud Assembly Service [278]
From within the Cloud Services Console

Console, under My Services
Services:
1. Click the Cloud Assembly service.
Sharing Blueprints Between Multiple Projects [279]
Cloud Assembly blueprints can be shared between multiple projects. In this lesson, we will create a new project and assign an existing
blueprint to it, rather than creating a new blueprint.

Navigate to Projects [280]
1. Click the Infrastructure tab
2.Click Projects
3.Click + NEW PROJECT to add a new project

Create a New Project [281]
1. For Name, enter Web Hosting Development
2.Click the Users tab to proceed
Add Users to a Project [282]
When managing access to a project, we must explicitly add users or groups via different windows.

1. Click + ADD USERS to open the Add Users window

Add a Member User to Project [283]
1. In the Users field, type websupport but do not click Enter. When user Web Support 01 appears in the list, select it and it will
appear in green as in the screenshot above.
2.Click ADD to add this user as a member of the project
The Web Support 01 User will be able to consume project resources, but not able to create or administer any policies.
Add Groups to a Project [284]
Now that we have added a user, and administrator to the project, we will add a group of users with member access.

1. Click + ADD Groups to open the Add Users window
Add a Member Group to Project [285]

1. In the Users field, type web-admin-team but do not click Enter. When user web-admin-team appears in the list, select it and
it will appear in green as in the screenshot above.
2.Click ADD to add this user as a member of the project
Members of the web-admin-team will be able to consume project resources, but not able to create or administer any policies.
Add Administrator to Project [286]
1. Click + ADD USERS to open the Add Users window again (not shown)
2.In the Users field, type holadmin but do not click Enter. When Admin HOL appears in the list, select it and it will appear in
green as in the screenshot above.
3.Click the Assign role field and select Administrator from the list
4.Click ADD to add holadmin as an Administrator of this project

Configure Provisioning Settings [287]
By default, no cloud zones will be assigned to this project. Assigning cloud zones to the project will allow users assigned to the project
to deploy blueprints using resources in those cloud zones.
1. Click the Provisioning tab
2.Click + ADD CLOUD ZONE
3.Select Cloud Zone from the menu to add a Cloud Zone

Add Cloud Zone to Project [288]
1. Click on the Cloud zone field, and select Private Cloud / RegionA01 from the list
2.Click ADD to add this cloud zone as a provisioning target for this project
In this lesson we will not be setting limits within this cloud zone for the project. But project-specific limits for resources and number of
instances can be specified per cloud zone within the project.

Create the Project [289]
1. Click the Summary tab
2.Click CREATE to create this project and return to the list of available projects

Navigate to Blueprints [290]
With the new project created, new blueprints can be created as part of the project. However, rather than creating new blueprints from
scratch, in this lesson we will modify an existing blueprint so that it can be shared between multiple projects.
1. Click the Design tab to view the list of available blueprints
2.Click on the Base Linux Server blueprint to open it in the blueprint designer
1. Notice that it is owned by the Web Hosting Project
Modify Blueprint Settings [291]
1. Click SETTINGS to open the Edit Blueprint window

Configure Blueprint Sharing [292]
1. Click the button next to Allow an administrator to share with any project in this organization
2.Click SAVE to save the blueprint settings
3.Click CLOSE (not shown) to close the blueprint and return to the list

Verify Blueprint Sharing [293]
1. Note that the Base Linux Server blueprint includes an icon in the Project column signifying that this blueprint can be shared
with other projects in the org
Now that this blueprint is available to the newly created Web Hosting Development Project, we will enable it in Service Broker and
create policies that will apply to Web Support 01 User's deployments of this blueprint.
Configuring Policies in Service Broker [294]
In the previous lesson, we created a new project for the Web Hosting team to use as a development space. But rather than creating
new blueprints specifically for that project, we enabled a blueprint to be shared among multiple projects. In this lesson, we will move
from Cloud Assembly to Service Broker, share the blueprint, and set up policy and customization for more specific control over
deployments in this project.

1. On the right side of the browser window, click the 9 dots in the upper right and the menu will slide open
2.Click Service Broker to switch to the Service Broker service

View Catalog [296]
Note that, as the holadmin user, we already have access to several blueprints due to membership in the "HOL
HOL Project
Project" project. The
"Base
Base Linux Server
Server" cloud template was made shareable in the previous lesson, and we will now update Service Broker and then add
this blueprint to the new Rainpole Project.
1. Click Content & Policies
Update Content Source [297]

The cloud template we want to add to our new project (Base Linux Server) is already available to Service Broker as part of the Web
Hosting Cloud Templates content source. By updating this content source, Service Broker will update the blueprint setting change we
made in the previous lesson.
1. Click Web Hosting Cloud Templates to open the content source
Update Content Source (Continued) [298]
This content source pulls Cloud Assembly cloud templates assigned to the Web Hosting project. By updating the content source, we
will update Service Broker to include the sharing changes made to the "Base
Base Linux Server
Server" blueprint.
1. Click VALIDATE to verify the content. Note the number of items found in the validation message.
2.Click SAVE & IMPORT to save this updated content source.

Add Item to New Project [299]
With Service Broker updated, we can now share the updated blueprint with the Web Hosting Development project.
1. Click on Content Sharing on the left to proceed
2.Click on the Project field to open the list of projects
3.Select Web Hosting Development from the list
Add Item to New Project (Continued) [300]

With the project specified, the Add Items button will become usable.
1. Click + ADD ITEMS
Select Items to Add [301]
1. Click the down arrow next to Web Hosting Cloud Templates to expand the content source. Note that the Base Linux Server
Cloud Template is the only one listed, because this is the blueprint that we modified to be shareable.
2.Click the checkbox to share all shareable items in this content source with Web Hosting Development project
3.Click SAVE to proceed
4.Click the Catalog tab to return to the catalog (not shown)

View Catalog Items [302]
Now that the Base Linux Server cloud template has been shared with Web Hosting Development Project, it will be available for
members of that project to use. But when we return to the Catalog tab, we still see the same set of blueprints as before. This is
because holadmin belongs to several projects in this org.
1. Note the projects listed for the "Base Linux Server" blueprint, and how it varies from the other blueprints shown
2.Click the Filter icon to open the filter options

Filter Catalog View [303]
1. Click the checkbox next to Web Hosting Development in the filter list. After a moment, the Catalog Items list will update and
only show 1 item - our shared Base Linux Server cloud template. This is what members of the Web Hosting Development
Project will see in the catalog upon logging in.

When a cloud template is shared with multiple projects, and a user (such as holadmin) is a member of multiple projects, notice how the
user is presented with multiple options when they select which project to deploy the resource to.
At this point, members of the Web Hosting project can request deployments of the Base Linux Server cloud template through Service
Broker. But currently, they have no limitations on the number of deployments because we did not set limits when assigning the cloud
zone to the project previously. What if we want to provide more control over resources used in this project to reduce the potential
impact that development can have over production deployments?

Navigate to Policy Definitions [304]
1. Click Content & Policies
2.In the Policies section of the menu on the left, click Definitions
3.Click + NEW POLICY to begin the process of creating a new policy

Policy Types [305]
In vRealize Automation 8.4, 3 Policy Types are available:
•Approval Policies, which will pause deployment requests for approval by one or more approvers
•Day 2 Actions Policies, which will allow for specific Day 2 actions to be available to deployed resources
•Lease Policies, which allow administrators to set expiration dates for deployed resources
All policies can be applied conditionally.
1. First, we will create a new approval policy. Click Approval policy to proceed.

Create New Approval Policy [306]
1. For Name, enter Web Hosting Development Approval
2.Click on the Scope field, and select Project
3.Select Web Hosting Development to limit this approval policy to this project specifically. Policies can be applied to a specific
project, or to the entire organization.
4.Click the + button to add Deployment criteria

Set Deployment Criteria [307]
Adding deployment criteria for a policy allows for conditional application of that policy, giving project administrators granular control
over how policies are applied. Individual criteria or groups of criteria can be combined with and/or logic to make the criteria as specific
as desired.
1. Click Select clause to open the menu
2.Click blueprint to set this value
Set Deployment Criteria (Continued) [308]
1. Click on the Select operator field, and select equals from the list
2.Click on the Enter value field, and select Base Linux Server from the list
This establishes a single criterion for the approval policy, allowing this approval policy to be applied to every deployment of the Base
Linux Server blueprint within the "Rainpole Project" project.

Continue Policy Creation [309]
Click the scrollbar (not shown) to scroll down to view the rest of the approval policy settings. In an approval policy, multiple approvers
can be specified. Policy settings can require all users to approve, or any single user.
1. Click + ADD USERS to add an Approver to this policy
2.In the Add Users window (not shown,) enter holadmin and wait for the selection, select Admin HOL, and press Add to add
holadmin as an approver

Approval Policy Creation [310]
1. Note that the holadmin user is now available as an approver following the previous step
2.Click on the Auto expiry decision field, and select Reject

Reject. This will allow for requests that expire to be automatically rejected.
3.For Auto expiry trigger, enter 2. Combined with the Auto expiry decision setting, this will cause all approval requests to
automatically be rejected after 2 days.
4.Click on the Actions field, and search for Deployment.Create to filter the list. This approval policy will only be enforced when
new deployments of this blueprint are created. If we wish to select multiple actions to apply this approval policy to, such as
when a deployment is deleted, use the Select multiple button to display a multi-select window (not shown)
5.Click CREATE to complete the creation of this approval policy

Approval Policy Created [311]
Note that the Web Hosting Development Approval approval policy is now created. This policy will:
•Only apply to the Web Hosting Development project
•Apply to all new deployments of the Base Linux Server cloud template specifically
•Require the approval of holadmin to proceed
•Automatically be rejected if not approved within 2 days
With the approval policy in place, we will create additional policies to further enforce governance of the Web Hosting Development
project.
1. Click + NEW POLICY

Create Day 2 Actions Policy [312]
1. Click Day 2 Actions Policy

Configure Day 2 Actions Policy [313]
Day 2 actions policies allow for control over what actions can be executed on deployed resources. Example actions include rebooting
machines, taking or deleting snapshots, and deleting deployments, but custom day 2 actions can also be created and then controlled
via policy.
The initial configuration of this policy will be similar to the approval policy - limited to the Rainpole Project project, and applicable to
deployments of the Ubuntu 18 blueprint.
1. For Name, enter Web Hosting Development Actions
2.Click on the Scope field, and select Project
4.Click the + to add one deployment criteria
5.Set the clause to Cloud Template

Template, the operator to equals
equals, and the value to Base Linux Server
Server, as shown in the screenshot
above
6.Scroll down to view the rest of the policy settings (not shown)

Configure Day 2 Actions Policy (Continued) [314]
1. Click on the Role field, and change the value to Member

Member. This will apply the policy to all users in the Rainpole Project
assigned to the Member role (recall from the previous lesson that rpuser is a member of this project.)
2.Click into the search box to display a list of available actions.
3.We want to add multiple actions to this approval policy, so we will use the Select multiple link to launch a multi-select menu.

Add Multiple Actions to a Policy [315]

1. Click in the filter field and search for snapshot

snapshot.
2.Select Cloud.vSphere.Machine.Snapshot.Create
Cloud.vSphere.Machine.Snapshot.Create, Cloud.vSphere.Machine.Snapshot.Delete
Cloud.vSphere.Machine.Snapshot.Delete,
Cloud.vSphere.Machine.Snapshot.Revert
3.Click Select to add these actions to the policy.
4.Repeat steps 1-3 to add Deployment.ChangeLease (not shown)
In this way, the day 2 actions policy limits all members of the project to only these specific actions on deployments.
3.Click CREATE
Day 2 Actions Policy Created [316]
Note that the Web Hosting Development Actions day 2 actions policy is now created. This policy will:

•Apply to deployments of the Base Linux Server cloud template specifically
•Limit all members of the Web Hosting Development project to only take, delete, or revert to snapshots of vSphere machines,
and to change the lease of deployed resources
We have one more policy to create.
1. Click + NEW POLICY

Create Lease Policy [317]
1. Click Lease Policy

Configure Lease Policy [318]
Lease policies allow for deployments to be deleted after a specified time, freeing up resources to be used by the rest of the
organization.
The initial configuration of this policy will be similar to the previous policies - limited to the Rainpole Project project, and applicable to
deployments of the Ubuntu 18 blueprint.
1. For Name, enter Web Hosting Development Lease
2.Click on Scope and select Project
4.Click the + to add one deployment criteria
5.Set the clause to Cloud Template

Template, the operator to equals
equals, and the value to Base Linux Server
Server, as shown in the screenshot
above
6.Scroll down to view the rest of the policy settings (not shown)

Configure Lease Policy (Continued) [319]
1. For Maximum lease (days), enter 7
2.For Maximum total lease (days), enter 30
3.For Grace period (days), enter 2
For all deployments to which this lease policy applies, the deployments will be available for a maximum of 30 days. The lease will expire
after 7 days, and the user has a 2 day grace period to extend the lease for a maximum of 7 days each time, until the 30 day timeframe is
met.
4.Since this policy may affect existing deployments, a preview option is included to validate the effect the policy creation will
have. Click Preview to open the Policy Enforcement Preview window, to view the impact of enforcing this policy.
5.Click the x to close the Policy Enforcement Preview window (not shown,) and click CREATE to create the policy

Lease Policy Created [320]
Note that the Web Hosting Development Lease lease policy is now created. This policy will:
•Apply to deployments of the Base Linux Server cloud template specifically
•Apply a lease of 7 days to all deployments, which can be renewed 7 days at a time up to a maximum of 30 days. This includes
a 2 day grace period to renew the 7 day lease.
Custom Forms in Service Broker [321]
Content in Service Broker can be enhanced with a custom form. Custom forms allow administrators to specify default values, customize
the name and appearance of request form items, and to include specific details generated from vRealize Orchestrator workflows.

Open Custom Form Designer for Ubuntu 18 Blueprint [322]
1. Click Content in the left menu
2.Click the 3 vertical dots next to the Base Linux Server blueprint to open the customization menu
3.Click Customize form

View Custom Forms Designer [323]
The Custom Forms Designer allows several options for customizing existing blueprint inputs, as well as adding new ones.
1. Click and drag the bar above General Elements to drag the menu and reveal several of the elements that can be added to a
request form.
2.The canvas shows current inputs for the blueprint. This blueprint does not have any custom inputs now, but we will make
several changes to the form in this lesson. Click on the Description section to select that specific input.
3.Details of selected inputs will appear in the Properties pane. The default appearance and value of the element can be
modified, and constraints (such as a pattern, minimum/maximum length, and others) can be set as well.
4.Click the Values tab

Set Conditional Value for Description Element [324]
1. Click the down arrow next to Default value to expose additional options
Form elements can have several types of values, including:
•A constant
constant, such as a string or a number
•A conditional value
value, based on one or more statements
•A value from an external source (a vRealize Orchestrator workflow)
•A specific value based on the value of another field in the request form (bind
bind field
field)
•A computed value - either a concatenated string or a calculated number
In this lesson, we will set a conditional value for the Description element.
2.Click the Value source field and select Conditional value
3.For Set value, type Web Support User's deployment for Web Development
4.Click on the first field under If and select Requested by

by. Click on the field next to it, and select Equals
5.Click on the field labeled Enter value, and type [email protected]
This expression will set a specific description when this blueprint is requested by rpuser. Otherwise, the description field will be empty.

Add DropDown Element to Form [325]
1. Click and drag the DropDown element from the Generic Elements section onto the canvas as shown
2.Click on the newly added DropDown element on the canvas to select it

Change Input Appearance [326]
1. Click on the label field, and change the value to Cloud to rename the DropDown field
2.Click the down arrow next to Custom help
3.For Signpost help, enter Preview - not in use yet
Adding text to the Signpost help field will add a small help icon next to the DropDown field in the form itself. Clicking on that icon will
reveal this message. In addition to the help message, the field's visibility can be set in this tab, and the field can be marked as Read-
only if needed.

View Values for DropDown Field [327]
DropDown value options can be set from a vRealize Orchestrator workflow (an external source,) or a specific list of values can be
defined. In this lesson, we will set a list of constants.
2.Click the down arrow next to Value options
Note the format for the values: Value|Label|Description(optional),Value|Label|Description

Set Values for DropDown [328]
1. In the Value source text area, type none|No Preference|No preferred cloud,vsphere|vSphere|Private Cloud,aws|AWS|AWS,
azure|Azure|Azure and press Enter (Note: select the text in the manual, and drag and drop it into the lab console to copy and
paste)
Remember that the format is Value|Label|Description. The Label entries will appear to the requestor in the form, and when a specific
item in the list is selected, that it's Description entry will appear beneath the DropDown element.
2.Set a default value of none (or any other of the Value entries in the Value source text area, to set a different default value)
3.Click on the Appearance tab to save the value

Add Text to Top of Form [329]
1. Click and drag the Text element from the Generic Elements section to the small section above Deployment Name at the top of
the form
2.Click on the Text element in the form to select it

Set Value for Text Element [330]
1. In the Properties pane, click on the Values tab
2.For Default value, enter Web Development Machine Request Form
3.Note the Field ID for this element. Select it, and then right click and select Copy to save this ID for later
In addition to customizing the appearance and values of form elements, it is also possible to further customize the appearance of the
request form with CSS.
Open Visual Studio Code [331]
1. Click the Visual Studio Code icon in the taskbar to open it

Open CSS File [332]
1. Click File
File, and select Open File (not shown)
2.Click the Lab Files folder in the Favorites list, and double click on the folder named HOL-2201-12 (not shown)
3.Click on the whd-form.css file to select it
4.Click Open

Replace CSS Element with Text Element ID [333]
1. Select the <field_ID> entry in line 1 of the file (note: be sure to include the < and >, but not the # on the line)
1. Repeat step one for the second <field_ID> entry. This is required because of how the form elements are nested
(not shown)
2.Right
Right click on the selection, and select Paste to paste the field ID value copied from the Text element in the request form

View and Save CSS File [334]
The file should look like the following:
1. The first block will apply customization to the text area we added to the request form. Note that the specific ID of this field in
the lab may vary from the screenshot, which is why it was necessary to copy and paste.
2.The second block will apply customization to the Description field in the request form.
3.Click on the File menu and select Save to save the changes, and click the Service Broker browser in the taskbar (not shown) to
return to Service Broker

Import CSS File [335]
1. Click ACTIONS to open the menu
2.Select Import CSS from the list

Choose File to Import [336]
1. Click the Lab Files folder in the Favorites list, and double click on the folder named HOL-2201-12 (not shown)
2.Click on the whd-form.css file to select it
3.Click Open to import the customizations

CSS Import Complete [337]
The import will complete quickly, although the changes are not reflected in the canvas.
1. Click ENABLE to enable the custom form for this blueprint. With the form enabled, the changes we've made will be visible to
anyone who requests this blueprint from the catalog.
Save Custom Form Settings [338]
1. Scroll down (not shown) and click SAVE to save the custom form settings

Consuming Custom Policies in vRealize Automation [339]
In previous lessons, we created a new project and shared an existing blueprint with it, and then configured policies and a custom form
for members of that project. But what does this look like for the Service Broker consumer? In this lesson, we will assume the role of
rpuser and request a deployment in Service Broker.
Open Incognito Browser Window [340]
1. Click the 3 vertical dots to the right of the URL bar in the browser to open the menu
2.Select New incognito window from the list

1. Click the vRealize Automation bookmark in the bar to connect to vRealize Automation
2.Since this is an incognito session, you will be presented with a domain selection screen. Click Next to continue.

Log In to vRealize Automation (Continued) [342]
1. For username, enter rpuser
2.For password, enter VMware1!
3.Click Sign in to log in

Open Service Broker [343]
With only Member access to the Web Hosting Development project, websupport01 has fewer options than holadmin.
1. Click Service Broker
Request Deployment [344]

The Base Linux Server blueprint we previously shared with Web Hosting Development project is available to be requested.
1. Click REQUEST

Enter Request Details [345]


Note that the customizations made to the form in the previous lesson are visible, including:
•The text added to the top of the form, with new font style and color
•Font changes to the Description element
•The text in the Description field, set because we are requesting as websupport01 user
•The Cloud input, with the default value set and the descriptive text below the select box (feel free to set this input to any
value)
•The signpost icon next to the Cloud input, which will display the help text when clicked on
Next, we will begin the deployment.
1. For Deployment Name, enter Linux Test
2.Click SUBMIT
Note Pause for Approval [346]
1. Switch to the tile deployment view.
2.The deployment will begin as usual, but it will pause at step 3 with a status of Create - Approval Pending due to the approval
policy configured earlier. This deployment will not proceed until holadmin approves the request.
3.Click the other browser task in the taskbar to return to holadmin's session (note: if the session has timed out, click the vRealize
Automation bookmark in the bookmark bar, log in with the stored holadmin credentials, and go to Service Broker.)

View Approval Request [347]
1. Click the Approvals tab
A summary of the approval is shown. Note that details of the deployment (name, requestor, and project) are shown, as well as the
action awaiting approval (Deployment.Create) and the associated approval policy. This approval request is set to expire in 48 hours due
to policy setting.
1. Click on the Development Test deployment name to open the approval request for more detail
View Request Details [348]
The request includes additional detail about the objects in the deployment in the Request Details tab, and more detail on the approval
itself in the Approval Details tab.
1. Click APPROVE

Approve the Request [349]
1. For Comment, enter Approved
2.Click APPROVE to approve the request
View Request in Progress [350]
Click on the other browser task in the taskbar (not shown) to return to rpuser's session. Note that the deployment status is now Create
- In Progress following holadmin's approval. The request will complete in 3-5 minutes.
1. While the deployment is in progress, click on the deployment name Linux Test to open the deployment

View Deployment Actions [351]
When the deployment completes, a green Create Successful message will appear.
1. Click ACTIONS next to the success message to open the menu of deployment actions. Note that the only action available is
Change Lease, since that was the only deployment action that we set previously in the Rainpole Actions Day 2 Actions policy.
Note: You can attempt to change the lease for this deployment, but since it was only recently deployed and the maximum lease time is
7 days per the Rainpole Lease policy, it may only be possible to extend the lease by a few minutes.
View Machine Actions [352]

1. The linux machine may already be selected in the Topology section. If not, click on it to select it.
2.In the details pane on the right, click ACTIONS to see available actions for this machine. Since the only vSphere Machine
actions allowed per the Web Hosting Development Actions policy are for snapshot create/delete/revert, only those actions
will be available for websupport01.
Conclusion [353]
In this module, we explored Service Broker from the cloud administrator's perspective, and the end user's perspective. Policies in
Service Broker allow for a considerable range of governance options for requests and existing deployments, and custom forms allow
administrators to further enhance request forms for end users.

•Getting Started with vRealize Automation Service Broker
•Setting up vRealize Automation Service Broker Policies
•Customize a vRealize Automation Service Broker Icon and Request Form
From here you can:

Appendix
Hands-on Labs Interface [356]
Welcome to Hands-on Labs! This overview of the interface and features will help you to get started quickly. Click next in the manual to
explore the Main Console or use the Table of Contents to return to the Lab Overview page or another module.
Location of the Main Console [357]
1. The area in the large RED box contains the Main Console. The Lab Manual is on the tab to the right of the Main Console.
2.Your lab starts with 90 minutes on the timer. The lab cannot be saved. Your lab will end when the timer expires. Click the
EXTEND button to increase the time allowed. If you are at a VMware event, you can extend your lab time twice up to 30
minutes. Each click gives you an additional 15 minutes. Outside of VMware events, you can extend your lab time up to 9
hours and 30 minutes. Each click gives you an additional hour.
Alternate Methods of Keyboard Data Entry [358]
In this lab you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data
which make it easier to enter complex data.

Do Not Enable The Intercept Paste Feature [359]
The lab interface environment has the option of intercepting your paste keyboard shortcut (ctrl-v
ctrl-v on Windows, command-v on Mac) to
paste from your desktop environment into the lab console. This is not recommend for the lab because you will be copying and pasting
within the lab console and enabling this feature will make that impossible.
When you first attempt to use your paste keyboard shortcut within a lab session, you will be prompted to enable the intercept feature. If
you are prompted, be sure to:
1. Click CANCEL

To Disable Paste Intercept [360]
If you do find when copying text in the lab console and attempting to paste it that you are either not getting any text pasted or the text
is coming from the host computer where you are accessing the lab, you will need to turn off the Intercept Paste feature.
1. Click the gear icon at the top-right corner of the interface above the docked manual

2.Uncheck the Intercept Paste box

Click and Drag Lab Manual Content Into Console Active Window [361]
https://www.youtube.com/watch?v=xS07n6GzGuo
You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in
the Main Console.
Accessing the Online International Keyboard [362]
You can also use the Online International Keyboard found in the Main Console.
1. Click on the keyboard icon found on the Windows Quick Launch Task Bar.

Click once in active console window [363]
In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard
layouts.
1. Click once in the active console window.
2.Click on the Shift key.
Click on the @ key [364]
1. Click on the "@"

@" key.
Notice the @ sign entered in the active console window.

Activation Prompt or Watermark [365]
When the lab starts you may notice a watermark on the desktop indicating that Windows is not activated.
A major benefit of virtualization allows virtual machines to be moved and run on any platform. Hands-on Labs utilizes this benefit and
hosts labs from multiple datacenters. However, these datacenters may not have identical processors which triggers a Microsoft
activation check through the Internet.
Rest assured VMware and Hands-on Labs are in full compliance with Microsoft licensing requirements. The lab that you are using is a
self-contained pod and does not have full access to the Internet. Without this the Microsoft activation process fails, and you see this
watermark.
This cosmetic issue has no effect on your lab.
Return to Lab Guidance [366]
Use the Table of Contents to return to the Lab Overview page or another module.

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 vmware.com.
Copyright © 2022 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or
more patents listed at vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. and its subsidiaries in the United States and other jurisdictions. All other
marks and names mentioned herein may be trademarks of their respective companies. Lab SKU: HOL-2201-12-CMP Version: 20221025-145712

Hol-2201-12-Cmp PDF en Simulation

Uploaded by

Copyright:

Available Formats

Hol-2201-12-Cmp PDF en Simulation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hol-2201-12-Cmp PDF en Simulation

Uploaded by

Copyright:

Available Formats

HANDS-ON LABS MANUAL - 2022

Lab Guidance ...................................................................................4

Module 1 - Configuring Infrastructure in vRealize Automation (30 minutes) 7

Hands-on Labs Interactive Simulation: vRealize Automation Quick

Logging in to vRealize Automation (HOLadmin) ................................. 9

Creating Cloud Accounts, Cloud Zones, and Projects ........................ 12

Creating Mappings and Profiles .......................................................44

Configuring Service Broker Content ................................................. 75

Module 2 - Building Cloud Templates in vRealize Automation (30 minutes) 91

Logging in to vRealize Automation ...................................................92

Creating Your First Application Cloud Template ................................94

Cloud Template Iteration ................................................................ 112

Understanding Infrastructure With Tags ..........................................123

Module 3 - Managing Resource Infrastructure with Tags (15 minutes) 130

What Are Tags and Why Do We Need Them?................................. 130

Putting Tags to Use........................................................................136

Examine a Cloud Template with Tags ..............................................138

Test the Cloud Template Again ...................................................... 150

Module 4 - Property Groups and Secrets (30 minutes) 160

Log in to vRealize Automation as holadmin...................................... 161

Using Property Groups to simplify cloud templates ..........................164

Using Secure Properties to securely store sensitive data ..................184

Module 5 - Designing Custom Request Forms (30 minutes) 207

HANDS-ON LABS MANUAL | 2

Log into vRealize Automation ........................................................208

Customize a Request Form ............................................................ 210

Set Restrictions to a Text Field ........................................................ 211

Design a Computed Value Field......................................................214

Enable a Custom Request Form......................................................216

Test the Custom Request Form.......................................................218

Design a Drop-Down with an External Source................................. 224

Design a Conditionally Visible Field................................................ 233

Module 6 - Policy-Based Lifecycle Management and Governance (30

Open Chrome Browser.................................................................. 243

Logging in to vRealize Automation (HOLadmin) .............................. 243

Launch the Cloud Assembly Service ............................................... 245

Sharing Blueprints Between Multiple Projects ................................. 245

Configuring Policies in Service Broker ............................................ 257

Custom Forms in Service Broker .....................................................281

Consuming Custom Policies in vRealize Automation........................ 297

Hands-on Labs Interface ............................................................... 310

HANDS-ON LABS MANUAL | 3

Lab Overview - HOL-2201-12-CMP Administering vRealize Automation

Lab Guidance [2]

Lab Module List:

Assembly, and explore provisioning and lifecycle management of your deployment.

tags to manage machine metadata.

•Trisha Navarro, Consulting Architect, USA

•Scott Bowe, Sr. Cloud Solutions Architect, USA

HANDS-ON LABS MANUAL | 4

First time using Hands-on Labs? [3]

HANDS-ON LABS MANUAL | 5

You are ready....is your lab? [4]

HANDS-ON LABS MANUAL | 6

Module 1 - Configuring Infrastructure in vRealize Automation (30 minutes)

vRealize Automation 8.4 includes five primary components:

Lab Captain: Scott Bowe

Configuring Cloud Assembly [7]

HANDS-ON LABS MANUAL | 7