Last week we had our “TechSummit” and VMware and as part of the event their was a hackathon where team or individuals could sign-up and enter a cool integration into the competition. In the true spirit of a hackathon Tom Bonanno and I decided to do something cool. That something we named vRealize Voice Automation.
To be able to utilize the Amazon Echo to create, destroy, power on, & off workloads in vRealize Automation
Using the Amazon Alexa skills API we were able to create a new Alexa skill with three intents:
These intents combined with what Amazon calls Utterances allow us to take the speech input and determine variables within the speak for items like “blueprint” or “hostname”. That we then could use. The input taken from the Alexa API is then sent to some node.js code that is hosted on Amazon Lambda where we looked at the intent that was called and the variable values associated with and we then make a Rest API call to VMware vRealize Orchestrator invoke a workflow and pass the parameters to it as inputs. From there vRO talks to vRA and success.
It is certainly a cool solution, but remember the Alexa doesn’t always hear what you want it to hear and that can be catastrophic if your performing a destroy operation as you will see in the following videos.
Below are two videos. One is a commercial that was made for our hackathon entry and the other is a demonstration of the integration in action and a bit more on how we did it.
Yesterday VMware was very busy announcing the release of over 2 dozen product which included two new products to the market these two new additions to the VMware portfolio are:
VMware Integrated Openstack – That’s right it’s out and it’s available now for you to download. VMware Software Manager 1.0 – This probably not as exciting as VIO, but it will come in handy for finding, selecting, and downloading the content needed to install or upgrade a VMware Suite.
Below is a list of all the products released yesterday including links to their downloads, documentation, and release notes for your convenience.
vRealize Orchestrator 6.0.1 is now available. This is exciting especially of your are running vRA 6.2 and would like to deploy an external vRO server. That of course is just one of the benefits of the new vRO 6.0,1 release. Below is additional new features with this release:
With this release vRealize Orchestrator introduces a more flexible content delivery mechanism due to increased workflow development efficiency and a new troubleshooting experience. Workflow developers benefit from a more programming-free design experience provided by the new control flow activities and error handling mechanism. Workflow execution and monitoring is easier when using the new administrative interface. vRealize Orchestrator 6.0.1 introduces better configuration options for vSphere 6.0, by using a unified page for configuring vCenter Single Sign-On authentication, licensing, and vCenter component registry. The stability of the vCenter Server plug-in has been improved by resolving major issues based on customer feedback.
vRealize Orchestrator 6.0.1 has an updated model for installing the vSphere Web Client plug-in for vRealize Orchestrator. vRealize Orchestrator 6.0.1 supports the vSphere Web Client integration and context execution of vRealize Orchestrator workflows as part of vSphere Web Client 6.0.
For those of you who are fortunate enough to be able to get a trial for Code Stream this article will walk you through the installation and initial configuration of the product. Code stream as the name suggest is part of the vRealize product line and shares the same identity appliance and virtual appliance as vRealize Automation. Because of this I will be referring to articles I have already written for portions of the installation in an effort to not re-invent the wheel.
*Note – The instructions in the above referenced article may vary slightly from the vRCS Virtual Appliance, however it should be close enough that you should not have any issues following along.
On step 21 input the Code Stream License Key instead of the vRA license key, or both if you like.
3. For instructions on how to setup Tenants in vRealize Code Stream please see Adding Tenants in vRealize Autoamtion 6.x.
On step 7 you will not be able to add a user to the “Infrastructure Administrator” role as that is a construct of vRealize Automation. If you are running code stream and vRealize Automation on the same virtual appliance you can add users/groups to this role.
This release of vCenter Orchestrator fixes a number of issue from the previous release. Mainly a maintenance release, so when you can find the time I would recommend getting it installed and putting some of these issues in the past. If for no other reason you will want to get this installed to resolve the issue where nested workflow don’t resume properly when rebooting the vCO server. Issues resolved in this release:
Active Directory account gets locked when connecting to Microsoft SQL database If you set up a connection to a Microsoft SQL database with a Windows Active Directory account, the account gets locked from the domain.
vCenter Server inventory disappears from the Orchestrator client If there is an outage of the connectivity to vCenter Server, the vCenter Server inventory disappears from the Orchestrator client and cannot be accessed until you restart the vCenter Orchestrator server.
Purging operations might cause a Microsoft SQL database deadlock Orchestrator’s purging operations for events might cause a deadlock in a Microsoft SQL database.
VcAuthorizationRole.roleId does not provide the correct role ID and always returns 0 When you use the vCenter Server plug-in VcAuthorizationRole.roleId attribute, the correct role ID is not provided. Instead, the role ID of every object is displayed as 0.
Nested workflows not resuming properly when rebooting If there are nested workflows still running when you reboot an Orchestrator server, the nested workflows do not resume from the last workflow element that was running at the time of reboot. After the Orchestrator server starts again, the nested workflows resume from the begining.
Import Package dialog responding slowly The Import Package dialog might respond slowly when importing a package with content that is already available in Orchestrator.
Problematic releasing of locks If you create a lock with LockingSystem.lockAndWait(lockName,””) and try to release it by running the Release all locks workflow, the LockingSystem.unlockAll() method does not release all locks.
For those of you who have not seen this yet, it is a must have for anyone writing vCO workflows for vCAC. VMware’s own Dan Linsey build a set of pre-built workflows to help aid you in your own development efforts. The toolkit includes workflows for performing Create, Read, Update, & Delete Operations for vCAC custom properties for more than just virtual machine objects. IT includes support for the following:
Top check out this incredibly useful toolkit head over to the VMware Communities and download it.
It seem that there is a bit of confusion around using vCO workflows with multi-machine blueprints. Before I discuss how to build vCO workflows for multi-machine blueprints I want to discuss the differences between single machine and multi-machine blueprints and how they relate to each other.
Single Machine Blueprints
Single machine blueprints are pretty straight forward. When a custom property is defined on a single machine blueprint it only affects that machine. Makes sense right? When we trigger a vCO workflow to run during a state transition of a single machine it interacts with only that machine. It is important to be mind full of the vCO workflows that are assigned to single machine blueprints that may be used as a component machine of a multi-machine blueprint.
Multi-Machine blueprints are extremely versatile allowing single machine blueprints to be grouped together for and requested in a single deployment. They are so versatile that you can add single machine blueprints of different types that are possible deployed to different types of Endpoint and across geographies. This however also makes them somewhat complex requiring you to be careful and thoughtful as to how you structure custom properties and the vCO workflows that you may choose to run on them.
Custom properties that are defined at the Multi-Machine blueprint are passed down to the component virtual machines that are a part of them. This can be very useful, but can also be a bit dangerous. Take the hostname property. If we define a hostname using this property at the Multi-Machine level it will cause chaos during the deployment and cause the deployment to fail because all machine will inherit the property and the value and ultimately have the same name.
This is the case with any different properties when used at the multi-machine level. You also need to be mindful of the effect of that property across different platform, provisioning types as well as geographies. This becomes even more complicated when executing state transition workflows that run vCO workflows. If you attach a workflow to the multi-machine it will in turn become attached to every component machine as well. This can be very useful if you want to execute the workflow on every component machine, however if that workflow is utilizing an entity that doesn’t exists at the parent multi-machine level it will again cause chaos for your deployment. The good news is it doesn’t have to as long as the vCO workflows are built to support the intended result.
In the following walk-through I will be using the Custom vCenter Folders Extension to demonstrate what you can do to account for the Multi-Machine and Single Machine aspects of vCO workflows.
vCAC by default will place all provisioned machines into a vCenter folder named VRM. You can override this using the custom property VMware.VirtualCenter.Folder to tell vCAC where to place the provisioned machine. While this is great that you can tell vCAC where to place the provisioned machine it isn’t very flexible. I built the Custom vCenter Folder Extension to fix that and make folder placement as flexible as you need it to be. VM folder placement is just about organizing virtual machines. It provides a way to control access to these machines through vCenter as well. Many organizations control permissions to these environments using these folders and need to be able to place any machine where they need for these purposes.
Multi-Machine blueprints is another area where this extension adds value. You can control placement of virtual machines by defining the VMware.VirtualCenter.Folder property on a Multi-Machine blueprint folder, but all VM’s for all Multi-Machine apps are placed in the same folder creating confusion as to which VM’s belong to which Multi-Machine application. Now if you add NSX into the mix and you have Multi-Machine components spread all over the place with no way to easily determine which VM’s as well as NSX Edges go to which application.
When used with Multi-Machine blueprints the Custom vCEnter Folder Extension can place all component Virtual Machines as well as Deployed NSX Edge appliances in a folder named after the Multi-Machine application if you desire making it easy to identify related components of an application. This also allows you to easily permission vCenter access to the components of the application if necessary.
Dynamic Folder Names based on custom naming scheme
Multi-Machine folder placement including NSX Edge applince
Automatic Multi-Machine folder removal when Multi-Machine app is destroyed
Now that we have installed and configured NSX I think it’s time we connected it to vCAC. In version 6.1 there are some changes to the integration with NSX and vCAC. When I say changes I should say there are some great new changes. The integration now utilizes a vCO Plug-in that handles all the interactions between NSX and vCAC.
Benefits of vCO plug-in for NSX to vCAC integration
The benefits of the vCO plug-in are huge. These workflows that now exist in vCO are there for you to use in your own customization giving you the ability to interact with NSX in a custom way without having to code against it’s api. Personally I await the day for all integrations to be this way.
As most of you know the vCAC appliance has vCO built in and the built in vCO server already has the NSX plug-in installed for. If you want to use an external vCO you will have to deploy the plug-in to that appliance before trying to connect vCAC to NSX.