VMware announced the general availability of vRealize Automation 8.1 a couple of weeks ago. This update includes a wide range of new features and capabilities. Some of these items restore functionality that was lost in transitioning from 7.x to 8.x (such as Approval Policies).
Governance and Policy
Version 8.1 adds some new items under Governance and Policy. Some of these include Approval Policy, limits on resources and view-only roles.
Approval Policy
Approval Policies have been expanded to be more in line with the functionality of what was in 7.x. In one of my first impressions posts about version 8.0, I noted there was only 2 policy types (Lease and Day 2 Actions). There is now a third option called simply Approval Policy.
I had been burned by updating vRealize Automation a little too quickly following a hotfix release. Chrome 75 caused some rendering issues in the deployment forms. These issues were resolved by Hotfix 1, which introduced some extra issues. The most visible one is the duplicate requests on an XAAS (Anything as a Service) blueprint. An example of this behaviour is shown below
Duplicate request
The second issue that I’ve seen as cosmetic. It was resolved in Hotfix 2. In this issue, labels on an XAAS blueprint rendered correctly in the Designer but when requesting the blueprint via the catalog, the label text would wrap. An example of this is in the image below:
In my first post about PowerShell 7.0, I made mention of a major issue that most likely prevent adoption of PowerShell 6.x by Windows system administrators. This issue was the loss of functionality in 6.x, specifically that some cmdlets would not be available due to 6.x being built on .NET Core. The release of 7.0 is meant to help address this, which is the intent of this post.
Cmdlet Compatibility Approach
In reviewing the compatibility for 5.1 and 7.0, I used the management server in my home lab. This is a Windows Server 2019 virtual machine, so it shares the common set of cmdlets that Windows 10 has. As a management server, it also has some additional modules/cmdlets available:
Windows Server Role-based modules such as ActiveDirectory and DnsServer
SQLPS from the installation of SQL Server 2014
cmdlets associated with VMware’s PowerCLI
cmdlets associated with ChefDK
AWS’s PowerShell module
While not comprehensive, this does give good coverage of built-in, Microsoft-provided and third-party provided items.
Microsoft has finally announced the General Availability (GA) release of PowerShell 7.0. This represents a fairly significant milestone in PowerShell’s history. In this post, I’ll go through some of the history prior to this point, what’s new in this release and how it works in practice.
One of the common things I’ve seen in automation implemented by infrastructure teams is a lack of rigor around testing. That is to say, code that tests the task that is being automated is actually successful. A script could execute to its end without errors, but that doesn’t necessarily mean it actually did what it was supposed to.
This leads into a concern I’ve seen raised by stakeholders, about visibility of what is happening in an automation pipeline. One of the key stakeholders in this sort of security is the IT Security team, who often want visibility of certain outputs (like virtual machines) to determine if those are secure. In a couple of environments I’ve raised the idea of performing automated vulnerability scans on newly provisioned assets, as a way of ensuring what is delivered is at an acceptable level. By automating this task, we place no extra burden on those involved and ensure consistency.
VMware have released a minor update for vRealize Automation (vRA) 8. This is my experience of attemtping to update the instance running in my home lab.
Update Preparation
In the Release Notes for 8.0.1 there’s a section for performing an upgrade. A couple of items in this section jump out. Firstly, that the vRA product supports upgrading from vRealize Suite Lifecycle Manager (LCM), with a link on the process. The second is an explicit mention of disk space requirements. Based on this, the first thing I checked was the free space for the two partitions mentioned.
VMUG recent added the vRealize Suite 2019 to their EVALExperience offering. For those not familiar with it, EVALExperience is part of the paid “Advantage” member in VMUG. This paid membership includes discounts on training and other benefits. This is on top of benefits of free membership.
This new addition means it’s now possible to get a 365-day license for all the components of the vRealize Suite 2019, including vRealize Automation 8. The license is for personal use in a home lab. I had previously tried updating the license on my vRA 8 installation from an Advanced to an Enterprise one, using Lifecycle Manager. It didn’t like that.
Sometimes you end up having to put in place an implementation that’s pretty crazy to get something (non-production) over the line. This was the case recently where I used vRealize Orchestrator (vRO) to call System Center Orchestrator (SCORCH) Runbooks. That is, using Orchestrator to call Orchestrator…
A lot of the credit for figuring out how to do this goes to Laurie Rhodes and their blog post about calling SCORCH runbooks via REST using Powershell. It was my starting point for this piece of work and I was able to adapt the core pieces of this for my scenario.
vRO Configuration
Assuming there’s existing SCORCH and vRO instances, the first task is to add the SCORCH server as a REST host in vRO. This can be achieved by running the “Add a REST Host” workflow that comes with vRO. The “Orchestrator Web Service” runs on port 81, so that will affect the settings for the host.
After spending a lot of time looking at the web interface for vRealize Automation 8 (vRA 8), I decided to look under the hook a bit. One of the first things I looked at was the logs. It seems one of the primary logs that vRA 8 uses is /var/log/vmware-vmsvc.log Upon viewing this log, I was greeted with the following spam:
[2019-12-05T11:47:54.126Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2019-12-05T11:47:54.126Z] [ warning] [guestinfo] Failed to get disk info.
[2019-12-05T11:48:24.128Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2019-12-05T11:48:24.128Z] [ warning] [guestinfo] Failed to get disk info.
[2019-12-05T11:48:54.127Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2019-12-05T11:48:54.128Z] [ warning] [guestinfo] Failed to get disk info.
As shown by the timestamps, this error will repeat every 30 seconds, resulting in this log being totally flooded with this error. I also confirmed this error was happening in another instance than my own. Upon googling the message, I found a Github issue entry that referenced this and how it can be caused by the very long paths with Kubernetes. vRA 8 uses Kubernetes heavily. The code fix that resolved this issue appears to have been folded into the v11.0.1 release of the open-vm-tools. When checking the version on the vRA 8 appliance, we can see the following:
That explains that
When checking the package info via yum, the versions available range from 10.2.0 to 10.3.10 from the repositories that vRA is configured to use. So it appears updating isn’t an option at this time.
The Server Broker section of vRealize Automation 8 contains the items that your consumers will interact with the most – the Catalog, and the Deployments tab where they can review the status of their requests. It also has some administration areas, such as Content & Policies and Infrastructure
