Intro Today, we have released a new version of PowervRA, 4.0.0 with support for vRA Cloud and vRA on-premises version 8.0. The observant among you will notice that we’ve incremented the PowervRA version from 3.7.0 to 4.0.0. We’ve done this since there is a significant breaking change.
The API for vRA Cloud / 8.0 is completely different to that which exists for vRA 7.x and earlier. If you’ve been with the product for a while you’ll be aware of the pain challenge it has been to work with since inception due to the split brain nature of the product, more info here and here.
A colleague requested some assistance as to whether it was possible to configure the vSphere Cluster Setting ‘VM dependency restart condition’ via PowerCLI. If you’re not familiar with this setting, it can be found in the vSphere Client web interface by editing the vSphere Availability cluster settings:
Digging around in the ExtensionData of a Cluster object in PowerCLI got us close, but it would appear that this value is not currently visible.
I’ve posted previously regarding returning output from PowerShell scripts that have been invoked by Ansible playbooks:
https://www.jonathanmedd.net/2019/10/ansible-windows-and-powershell-the-basics-part-6-displaying-output-from-powershell-code.html
https://www.jonathanmedd.net/2019/07/returning-data-from-powershell-scripts-to-be-consumed-by-ansible-playbooks.html
I encountered an issue recently where noise from a particular PowerCLI cmdlet, Invoke-VMScript, was polluting the output returned from the PowerShell script to Ansible. Specifically it looked like the below, a mess of Invoke-VMScript across the screen:
This is because Invoke-VMScript is one of those cmdlets which displays progress to the console while it is executing:
When Craig and I first created PowervRA and PowervRO in 2016 we only initially thought about using them for our own purposes, since we were on a project at the time which required heavy use of automation around vRA and vRO. When we decided to put them out into the community we never expected them to become as popular as they have done.
It was a fun experience for us, both in learning about collaborating, developing and releasing a PowerShell module, and the benefits it was bringing to our own jobs.
While carrying out some investigation around using the VMware Cloud Assembly API to work with Onboarding Plans we stumbled across a puzzling scenario. The documentation for creating an Onboarding Resource that is part of an Onboarding Plan shows the following content needs to be sent as part of the POST API request for the creation:
While figuring out what needed to be populated in each property I retrieved via the API the contents of existing Onboarding Resources:
As part of some automated deployment work for ESXi I was assisting a colleague with, they had hit an issue with an out of the box deployment of ESXi beginning with a blank password for the root account.
The automation tool of choice Ansible was using an SSH connection to ESXi to make the initial configuration and was blocked at the first step since it was unable to connect because the fresh ESXi install had no password set.
Back Story Back in January 2017 Craig and I made PowervRA available for macOS and Linux via PowerShell Core. It was always our intention to do the same thing for PowervRO and , although slightly later than we hoped, we’re finally able to do that. PowerShell Core has come a long way itself over the last year, currently in Release Candidate and soon to be GA, and I’m sure a lot of the hard work and community feedback which has gone into that has helped make the job of PowervRO supporting PowerShell Core very straightforward.
A few months ago we had an issue logged in PowervRA where it was not possible to make a connection to the vRA appliance after it had been locked down following the VMware hardening guide. Specifically this was because SSLv3/TLSv1 (weak ciphers) had been disabled.
By default, Windows PowerShell 5.1 has the following Security Protocols available, Ssl3 and Tls - hence the above failure.
It’s possible to workaround this by adding in the security protocol required, in this case TLS 1.
One of my colleagues showed me how to do this, so I thought it worth sharing since it has bugged me ever since I started using vRO.
If you have run a vRO workflow and are looking at the output, specifically the Variables tab:
you can then view what values each variable was at the time of workflow completion. If the value is a string or something else simple you will get a nice view of it.
There have recently been a number of blog posts around modifying the All Services icon in vRA, and how to change it programmatically:
http://www.vmtocloud.com/how-to-change-the-vra-7-2-all-services-icon/ - curl https://virtualbrakeman.wordpress.com/2017/03/17/replacing-the-all-services-icon-in-vrealize-automation/ - Python http://read.virtualizeplanet.com/?p=1539 - .Net http://michaelpoore.com/2017/03/how-to-change-the-vra-7-2-all-services-icon-using-vro/ - vRO We had a new feature request open in PowervRA for a while to do the same thing, so I figured it would be a good time to go and add it, so that the same change to the icon could be done from PowerShell.