Integrating Red Hat Ansible Tower with VMware vRealize Automation is a very popular enterprise automation solution. SovLabs has several excellent integrations that can help you accomplish and scale your integration of these two powerful cloud automation tools. This article is the first in a series of four articles covering the integration of Red Hat Ansible Tower with VMware vRealize Automation, based primarily on the content and discussion from our webinar with Red Hat Ansible on May 22.
Requesting a vRealize Automation deployment from Ansible. How, and why you would want to do it.
The SovLabs Ansible Tower Module for vRealize Automation with Static Inventory
The SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory
The SovLabs Ansible Tower Plug-in for vRealize Automation CM Framework
Requesting a vRealize Automation deployment from Ansible
With Ansible Tower quickly growing in popularity, many developers and system administrators want to be able to utilize Ansible Tower to deploy infrastructure. This type of deployment is the subject of many debates within enterprise organizations, especially those with cloud teams trying to develop standards while enforcing policy and governance across organizations.
The good news is that organizations no longer have to choose between solutions. If you want to use Ansible to develop standards while enforcing policy and governance across organizations, now you can. Using the solution below you can request workloads from Ansible facilitated by vRA to enforce the desired standards and governance policies. Let’s take a look at how it works.
SovLabs has released it’s latest version of it’s vRealize Automation plugin version 2019.8.0. Among other key updated it is Certified for vRealize Automation 7.6 as well as ServiceNow Madrid. Below is the full list of updates available in this release:
Certified for vRA 7.6!
A new SovLabs 2019.x license key is needed in order to use the SovLabs 2019.x Plug-in
If you read my blogs you know I’m usually all business talking tech and providing my readers with what I hope is useful information. Today I’m writing to ask for your support. My wife and I are raising money for Muscular Dystrophy by participating in the Harley Davidson Ride for life fund raiser. Last year Ride for Life donated $1.09M dollars to the MDA as part of this charitable event and hopefully this year we can raise even more.
My ask of you:
If you have found the information on this blog useful please show your support by donating to Ride for Life. My wife and I are trying to reach a goal of $3,000 raised for MDS through Ride for Life. Any donation you can make is greatly appreciated. You can make a donation by visiting my donation page at http://www2.mda.org/site/TR/General/22-NortheastDivision?px=3059956&pg=personal&fr_id=12249. For every dollar raised a matching donation will be made by VMware Foundation up to $3,141.59 as part of their Matching Gift program for employees. All donation must be in by 5/1/2015.
Regardless of whether you are able to donate or not I want to thank you all for following my blog and may you all have happiness and good health!
vCAC has what is referred to as the “Master Workflow” which makes up the Virtual Machine Lifecycle. The Master workflow is the top level workflow states that a virtual machine will go through, throughout it’s life. These workflow states tie pretty closely to the Workflow stubs that are shipped with the designer, but they are not a direct match to them. I often see confusion around the workflow states and the workflow stubs. I’m hoping to clear up the confusion around this and help everyone understand the difference between them.
I have seen a rise in questions regarding vCAC 5.x and integration with XenDesktop. This article is not a step by step on how to configure integration with XenDesktop, but information on capabilities and use cases for integration.
Supported XenDesktop Versions:
XenDesktop 4.0 (Only VMware Hypervisor and vCAC VDI agent must be installed on a 32-bit host.)
XenDesktop 5.0 (SP1 (Supported on VMware and XenServer)
XenDesktop 5.5 (Supported on VMware and XenServer)
vCAC utilizes custom properties in many different ways. They can be very useful if properly understood. To start with there are two high level classifications for custom properties. Those are:
Reserved Custom Properties – These are properties that vCAC understands and utilizes as part of it’s operations. vCAC has hundreds of reserved custom properties that it utilizes. These can be explored further at the end of the vCAC 5.1 Operating Guide.
Non-Reserved Custom Properties – These are properties that you can create on your own. These can simply be utilized to attach metadata to a machine, or they can be utilized within custom workflows and scripts.
Reserved Custom Properties
Reserved custom properties come in four different types:
Internal Properties – Internal custom properties are for vCAC use. These properties hold information relevant to features within vCAC such as approvals which don’t leverage any external systems.
External Properties – External custom properties are used for configuration outside vCAC. Properties that utilized to customize a provisioned machine are external custom properties. An example of this would be a property that defined the drive letter and label to be assigned to a disk inside a machine. (Note: If the values change on the provides machines they do not get updated in vCAC. The properties are utilized at provisioning time to perform the configuration only)
Read-Only Properties – Read only custom properties represent values such as the UUID of a virtual machine that cannot be changed or altered on the virtual machine or within vCAC.
Updated Properties – Updated custom properties represent items that can be changed and the updates reflected in vCAC. For example if the memory associated with a virtual machine were update through vCetner, when vCAC did it’s next docovery it would detect the change and update the property value for memory associated with the virtual machine.
Reserved custom properties are integral to the operation of vCAC. The properties are utilized by the built-in workflows to perform specific tasks as well as enable features. All machines in vCAC have a minimal set of properties that are attached to them for vCAC to be able to perform it’s functions. If we look at a vCenter virtual machine you will see these properties association with each one: Continue reading “vCloud Automation Center – vCAC 5.1 – Custom Properties Demystified”
I have written a few articles that show you how to configure “Reservations” in vCAC. In this article I’m going to dig in to some details around “Reservations”, how they work, and the additional options that are available for them.
What are Reservations?
Reservations are a way for Enterprise Administrators to provide a subset of resources to the users within the organization. When a reservation is created it is assigned to a specific Provisioning Group and only a single Provisioning Group. They are a construct within vCAC and are not related to “Resource Pools” in vCenter. They can however be mapped to one which we will discuss. There are (3) primary types of Reservations:
Virtual Reservations are used to allocate resources for the following:
There are two types of DEMs that are used within vCAC. Those are:
DEMs in General
You have to have at least one Orchestrator DEM and Worker DEM, but depending on the size of your environment you may have more than one of each. You may have more than one of each for redundancy purposes as well. DEMs can be installed in active-active pairs providing full resiliency for each other. DEM’s communicate with the vCAC Model Manager to receive work items that need processing. The really nice part is they pull from the Model Manager, the Model manager doesn’t push items to them. This is very helpful if you need ti utilize a DEM in a fire-walled environment. Continue reading “vCloud Automation Center- vCAC 5.1 – DEMs Demystified”