This document is intended to educate and instruct users and prospective users of VMware vRealize Automation and vRealize Automation Cloud 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 vRealize Automation Cloud (vRAC) 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 vRAC.
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 vRealize Automation Cloud (vRAC), which is a component of the VMware Cloud Management Services suite and is cloud-based Software as a Service (SaaS).
Both vRA and vRAC 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 vRealize Automation Cloud 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:
Currently, VMware has released vRealize Automation 8, which is not an upgrade from vRealize Automation 7, but an entirely new application. Custom properties are obsolete, custom workflows must be rewritten and users are learning to get acquainted with the new software. Though there is a vRealize Automation Migration tool, not all users have their customizations and workloads ready to be migrated. Sid Smith, Principal Solution Architect at SovLabs, discusses the many things to consider before attempting to migrate in A First Look at the vRA8 Migration Assessment Tool Part 1 and Part 2. Before making the big switch to vRealize Automation 8, be sure to consider the potential gaps and limitations of the new application.
|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.
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 vRAC 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.
SovLabs Modules introduct several ways to create dynamic blueprints and fight the sprawl including bulk finding, adding and modifying custom properties across blueprints the ability to create global custom properties using dynamic elements in your custom properties. SovLabs modules can also allow you to set multiple values from a single request input.
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.
If you are using SovLabs Modules, you can easily make custom emails for vRealize Automation notifications.
Both vRA and vRAC have some naming functionality for deployed virtual machines; however, administrators may want additional functionalities. Some of those naming functionalities might include:
You can read about how SovLabs modules can help creating custom naming sequences in our three-part blog series “Harness the Power of vRA.”
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.
You can see a video on our Active Directory module in action on YouTube.
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.
You can find a whitepaper covering SolarWinds IPAM/DNS and vRA here and a general whitepaper on the advantages of integrating IPAM/DNS with vRA here. There are also YouTube videos covering integrating vRA with Bluecat, Men and Mice, Microsoft, and SolarWinds IPAM/DNS solutions.
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 vRAC using scripts called from vRAC 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.
SovLabs also recently presented a webinar with Ansible which you can view here.
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.
Read up on integrating ServiceNow with vRA here or checkout this recent blog post on some of the latest enhancements for the SovLabs Module for ServiceNow. You can also view a video of the ServiceNow integration on Youtube.
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.
The SovLabs blog site has articles on creating self-service backup and recovery using Veeam, Rubrik and Cohesity. We have also posted videos on YouTube covering the Veeam, Rubrik and Cohesity integrations.