This document is intended to educate and instruct users and prospective users of VMware vRealize Automation and Cloud Automation Services products. Specifically, the guide serves to educate users on what to expect “out of the box”, what’s available on the open source market, what features & functionality will require custom code, and what solutions are offered through commercially available enterprise software providers.
Ultimately, any organization using vRealize Automation (vRA) or Cloud Automation Services (CAS) has options. If the organization has an in-house software development team, they can build, support, and maintain these solutions completely on their own. If not, then the organization can leverage free or open-source solutions, which have limited support. Or the organization can deploy commercial grade enterprise software to address their specific needs within vRA or CAS.
Regardless of which option or combination of options any organization chooses, the buyers and decision makers should be well informed prior to making any such decisions.
Implementing a private or hybrid cloud requires multiple systems working together under a cloud management platform (CMP). VMware currently ships two different — but related — CMP packages: the locally-installed VMware vRealize Automation (vRA) and VMware Cloud Automation Services (CAS), which is a component of the VMware Cloud Management Services suite and is cloud-based Software as a Service (SaaS).
Both vRA and CAS offer basic CMP capabilities along with frameworks to add additional functionality such as integrations with other tools and the ability to enhance the capabilities of the CMP itself.
While Cloud Automation Services is fairly new, many companies have chosen to implement vRealize Automation to provide cloud services for the vSphere and VMware on AWS infrastructures.
When considering a CMP, companies need to make a list of requirements that includes (1) the 3rd party infrastructure components that need to be referenced during the virtual machine lifecycle and (2) the functionality expected from the CMP during the VM lifecycle such as email notifications at the various stages.
The following table lists some of the requirements companies frequently look for in a CMP, and how those requirements may be met:
|Functionality (Template, Notifications, Property Toolkit)|
|Set or request property values at request|
|Dynamically set property values at request|
|Dynamically manage property values during lifecycle|
|Email user at lifecycle events|
|REST calls at lifecycle events|
|Modify order of provisioning events|
|Call scripts throughout lifecycle|
|Multiple naming standards|
|Dynamic (templated) naming|
|Naming validated against vCenter, vRealize Automation, DNS|
|Custom naming for more than VMs|
|Statically assign OU|
|Dynamically assign OU|
|Dynamically provision OU|
|Execute script after provisioning|
|Execute script and any stage of provisioning|
|Select clusters for deployments|
|Statically assign VM properties|
|Statically set vSphere folder|
|Dynamically assign vSphere folder during provisioning|
|Dynamically assign VM properties|
|Create DRS rules|
|Policy-based vSphere snapshot management|
|Notification schedule for snapshot management|
|Place VMs on NSX networks|
|Dynamically assign NSX tags during provisioning|
|Assign IP address from a pool|
|Work with 3rd party IPAM and DNS providers|
|Validate IP availability|
|Dynamically determine network|
|Men and Mice|
|Quickly create complex load balancer blueprints|
|Dynamically set networks|
|Dynamically provision VIP/Pool|
|Dynamic inventory in vRA and Tower|
|Dynamically assign job templates|
|Using CM Framework|
|Without requiring vRA Enterprise|
|Ansible (not tower) playbook execution|
|Day 2 Actions|
|Utilize Puppet Enterprise from within vRA|
|vRA 7.5 and 7.6 support|
|Create Puppet configuration in vRA|
|Red Hat Satellite|
|Driving Red Hat Satellite from vRA|
|Create software-defined Red Hat Satellite configs directly in vRA|
|Access vRA objects from SNOW|
|Batch replication of vRA items in SNOW|
|Customizable vRA/SNOW integration|
|SNOW-native control for vRA|
|End user-available backup/restore out of the box|
|vRO plugin for Cohesity|
|Managed in vRA|
|End user-available backups and restores|
|Managed in vRA|
|End user-available backups and restores|
|Managed in vRA|
While many of the sections below are specific and self-explanatory, this section is more of a catch-all for utilities and features that meet many use cases, or that many CMP admins might just find useful.
One primary functionality for a CMP is a catalog allowing end users to request new workloads or tasks to assign to existing workloads. While vRA includes a service catalog, CAS currently does not. With either CMP, users can implement ServiceNow or another requestor such as Terraform, or the CMP administrator can create their own custom service catalog using vRA or CAS API calls.
Service catalogs provide a selection of items for end users to choose from and request. From virtual machine blueprints to applications deployable on existing virtual machines, a good service catalog should allow users to find what they need quickly and accurately. This also reduces the administrative overhead needed to manage and maintain a catalog. However, many companies find their catalogs bloated with “blueprint sprawl.”
Blueprint sprawl is usually caused by static settings on a blueprint. Any items or value statically set on a blueprint (such as which network to place VMs on) means a new blueprint is needed if that value changes. The more blueprint values the administrator sets statically means the more unique blueprints the admin has to maintain. Conversely, the more dynamic a blueprint item is, the fewer blueprint items will be needed.
Fewer blueprint items requires less administrative overhead to manage. Fewer blueprint items also makes resource catalogs simpler for end users to find what they need. While vRA and CAS are both good at static values and have some logic in place for dynamic values, additional functionality may be required to drive dynamic manipulation of values.
When you configure vRealize Automation System Notification Events, you can receive automatic notifications for several types of events, such as the successful completion of a catalog request or a required approval.
Users and administrators often want notification of lifecycle events like provisioning. The added capability of dynamic API calls for lifecycle events are also useful for working with monitoring tools or triggering other actions.
Many CMP admins need to change the order of certain lifecycle processes or to call scripts at different stages of the lifecycle and have those scripts run without agents on any machine in the environment. Each of these needs requires custom coding to function in the VMware CMPs.
Both vRA and CAS have some naming functionality for deployed virtual machines; however, administrators may want additional functionalities. Some of those naming functionalities might include:
While vRA can assign a VM to an organizational unit (OU), a dynamic organization might need the OU to be created during provisioning (with a custom name). Or the organization might need the VM to be moved between OUs at the end of provisioning. For example, one might move a VM from a less-restrictive “build” OU to the final OU. At deprovisioning, the OU can be removed if empty.
Since vRealize Automation is used primarily to manage vSphere virtual machines, there may be many aspects of vSphere to manage during the virtual machine lifecycle. While all admins would want to ensure VMs are placed on the proper cluster, some admins may want to create Distributed Resource Scheduler (DRS) rules to ensure VMs remain on the correct host(s). CMP admins may also want to set tags on the VMs (either static tags or dynamically chosen or created tags) and dynamically assign the proper folder in the vSphere environment.
Along with vSphere virtual machine options, virtual machines may need to be tagged for NSX (virtual networking and security software) and be deployed onto NSX virtual networks.
If your environment is using an IP Address Management (IPAM) server, or if the deployed machines are required to have DNS records, the CMP will require IPAM and DNS integration. Free resources exist for Solarwinds and Infoblox; however, other vendors’ solutions will require custom code. You may also require custom IPAM/DNS integration code if you require additional features like custom naming integration, your IPAM and DNS are from different providers, or you require production-level support availability.
Integration with F5 BIG IP — the physical appliances or the virtual edition deployed locally or on VMConAWS — will require custom coding.
An environment leveraging Ansible Tower for deployments will require custom coding to integrate with the provisioning or Day 2 functionality of a CMP. A recent community effort was announced that leverages Ansible playbooks (not Tower) from within CAS using scripts called from CAS and executed on an Ansible Control Host. however, that effort currently has no dynamic capabilities or official support from Red Hat Ansible. Since scripts can be called from vRA, that capability can be achieved in vRA if needed.
Puppet offers a free plug-in for vRO, which can integrate with vRealize Automation with additional custom code. Support for this integration is best-effort and apparently has not been tested since vRA 7.3. Support for newer versions and functionality such as creating Puppet configurations from vRA will require additional custom coding.
CMP integration with Red Hat Satellite will require custom coding.
Leveraging ServiceNow is possible with vRealize Automation, if batch replication is all that is required. Additional functionality such as native ServiceNOW control of vRA objects will require custom coding.
Currently both Cohesity and Rubrik have limited-functionality vRO plugins available; however, additional custom work is required for vRA integration and support for that customization is questionable. Additional functionality or integration with VEEAM will require custom coding.