When vRealize Orchestrator 7.6 became generally available last week (and related to the simultaneous availability of vRealize Automation 7.6), an eagle-eyed VMware Partner spotted a statement in the release notes under the Feature and Support Notice section.
One of the statements in that section initially read:
vRealize Automation XAAS forms support only workflows created in the Orchestrator Legacy Client.
I asked a colleague in the Cloud Management Business Unit (CMBU) about this and was eventually put in touch with the right person in R&D who could expand on the meaning further.
The statement has now been adjusted to read:
The input parameter constraints of workflows created or edited in the vRealize Orchestrator Client do not automatically transfer to the XaaS blueprint request form in vRealize Automation. When using these workflows in XaaS operations, you must manually define the input parameters constraints in the XaaS blueprint request form. This limitation does not impact workflows created and edited exclusively in the Orchestrator Legacy Client.
It is important to note that in vRO 7.6, the term “vRealize Orchestrator Client” refers to the new HTML5 web client, whereas the term “vRealize Orchestrator Legacy Client” is used to describe the Java client that anyone used to vRO knows very well! In case you haven’t yet seen the new HTML5 client for vRO, I have a screenshot of it in my posting on the availability of vRA 7.6, and I’ll paste it here too.
Going back to the clarification, it means that workflows that are created / edited in the new client interface will not automatically have their presentation settings imported when adding the workflow as a XaaS blueprint or when refreshing the form design. Instead, a custom form would have to be created. The functionality is unaffected when using the legacy (Java) client.
vSphere 6.7 was released several months ago, and I’ve been meaning to upgrade my homelab for a while now. vSphere 6.5 has been pretty rock-solid, but it’s time for me to keep up with the Joneses. This post covers my upgrade process and experiences.
My original vCenter server was built straight on to version 6.5 when that first launched, way back when. In theory there was nothing wrong with it, except for a deployment decision that I was no longer happy with. When I deployed my vCenter previously, I configured it with an external Platform Services Controller (PSC) as I wanted to mess about with load balancing PSCs at the time. The messing around didn’t take long and I moved on to other things. Problem is, you cannot (currently) go from an external PSC to an embedded one and the external PSC was an extra piece of complexity that I just didn’t need anymore.
That pretty much left me with one option: migrate to a new vCenter.
Deploying vCenter is a doddle, and I won’t cover how that works. What I will mention though is how I moved my hosts and VMs across. The first step was to liberate one of my 6.5 ESXi hosts from the original cluster and add it to the new vCenter. At this time, I didn’t upgrade the host itself to 6.7 for reasons that will be apparent in a minute or two.
Secondly, I went through the VMs that I had registered in my original vCenter and weighed up whether or not I still needed them. Things like old distributed vRA deployments to a quick trip to the virtual bin, other things like AD, jumphosts, remote access solutions etc were powered down and removed from the inventory before being re-added to the new vCenter.
Before long, there wasn’t much left and what little is left will probably be left idle for a couple of weeks before I bin it completely.
Having upgraded my vRA instance in my HomeLab to 7.4 not long after it GA’d, I recently decided to create some nice, new templates as well. You know, latest patches, hardware, basic config etc.
I won’t bore you with exactly how I installed Windows, patched it or configured it. The relevant part of the process to this article was the installation of the vRA Guest Agent and subsequent testing of it.
I already had my vRA blueprint configured; just a simple Windows Server 2012 R2 template that has the vRealize LogInsight agent installed and configured on it automatically as part of the provision process:
Installing the vRA Guest Agent
This is a documented process to install the software agent on a Virtual Machine that is then subsequently turned in to a template. For vRA 7.4, the documentation can be found on VMware’s site:
A colleague of mine was working with a customer recently on some changes to their automated VM provisioning process (they’re not vRA customers… yet). He got stuck trying to get around a particular challenge with the automatic naming of network interfaces in certain Linux distributions.
The customer in question is using vRealize Orchestrator (vRO) to create (not clone) their Virtual Machines from a JSON structure that is supplied by an external system. In that structure there are definitions for the hardware, OS network identity (name, IP etc) and OS installation sources (ISO file for installation and floppy image for a ks.cfg (KickStart) file).
Once the JSON object is provided to the vRO workflow, the VM is created, booted and automatically starts to install and configure itself.
Customer’s Simple VM
Simple VMs have a number of disks defined (for root, opt, var, swap etc partitions) that are attached to a single ParaVirtual SCSI adapter. The VM is also equipped with a single VMXNET3 network adapter.
In this configuration, there is no problem. The installation of the OS runs through to completion and the VM is handed off to Puppet and eventually goes in to service.
Customer’s Complex VM
For the provision of Linux-based Oracle servers however, the customer wanted to be able to specify not only extra disks and partitions, but extra SCSI controllers too. Continue Reading →
A new vRA / vRO Extensibility course is scheduled to be held in the UK in February 2018. It will provide detailed information on how to leverage the power of vRealize Automation and vRealize Orchestrator.
I should point out that it’s a beta course, so it may not be 100% polished and pristine. However, the course is focussed on version 7.3 of both products (the latest at the time of writing) so it will be bang up-to-date and help you learn the “art of the possible”.
The course runs for a full week from Monday 19th February at VMware’s UK office in Staines. If you’re new to vRA and vRO, or you want to take your automation beyond simple virtual machine deployment then this course will likely benefit you. If you don’t manage to get on it, I’m sure there will be further opportunities throughout the year.
Extensibility Topics Covered
The topics covered by the course include:
The basics of vRO workflows
Design considerations for vRO workflows
Development of vRO workflows
Extending vRA using the Event Broker
Using vRO workflows with vRA’s Event Broker
Using vRO workflows to provide XaaS catalog items and resource actions
Working with REST APIs using vRO
You can register for the course via VMware’s myLearn website.
I thought I’d update my homelab’s primary vCenter to the latest and greatest (6.5 update 1d), when I encountered an issue with the root password. The update showed up ok in the appliance’s VAMI interface and I selected to install it but an error quickly showed up:
Not ready, huh? When I clicked on the “Show Details” button, I saw a message informing me that the root password had expired or expiring soon:
Well ok, I’ll go and reset it and turn off the expiry I thought. (That process is covered in the vCenter documentation.) But noooo, permission denied! The password couldn’t be set and the expiry settings could not be changed. Continue Reading →
VMware’s Office of the CTO (OCTO) runs an annual programme internally to appoint a limited number of outstanding individuals as CTO Ambassadors (CTOA). Broadly, the role of an ambassador is to help ensure a tight collaboration between VMware’s R&D and VMware’s customers.
CTO Ambassadors come from customer facing roles within VMware (such as SEs, PSO, TAMs and GSS). A good number of them are involved with, or are usually present at VMware’s customer focussed events (such as vForum, VMUGs and VMworld). With the new year comes a number of newly minted CTOAs. Whilst I can’t count myself amongst them, I’d just like to say a big, public “congratulations” to everyone that has been selected as a 2018 ambassador.
A lot of the projects that I work on have an element of automation to them and I’ve been asked a few times by customers if there is a training course available that will help them get started in understanding vRO and VMware’s PowerCLI cmdlets and how they can be used. Whilst there have been courses available in the past, there is a new one that reads a bit like “Doing my job 101”. It goes by the catchy title of “Data Center Automation with vRealize Orchestrator and vSphere PowerCLI“.
Looking at the outline, the important stuff is there.
Understanding, using and navigating the vSphere API (useful for both PowerCLI and vRO).
PowerCLI basics and more advanced uses.
vRO Basics and workflow creation / design.
So, if you’re looking to get started with vRO or PowerCLI and use one or both of them to add some automation to your datacenter, it might be worth trying this course out.