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.
Don’t forget to stop by the Hands On Labs and check out some of this years awesome labs that are available. Last night we had the lab burn in and they are open to day. There are labs for just about everything you can imagine. Not sure what lab is right for you, that’s fine stop by and chat with some subject matter experts that will help you determine which lab is the right fit for you. There are roughly 350 terminals in the HOL this year along with a customer connect area where you can BYOD to connect. If that was not enough there are 4 expert led breakout rooms where you can reserve a spot and attend expert led sessions on the various technologies.
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.
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!
Have you ever needed more control over what custom properties get assigned to specific component machines of a multi-machine blueprint, or want to use the same component blueprints for all component machine of a multi-machine blueprint? The Ultimate Multi-Machine Blueprint Extension aims to help with that.
The Ultimate Multi-Machine Blueprint Extension allows you to utilize the same source component blueprint for multiple component machines while at the same time controlling which custom propertied get assigned to each of the components. This allows you customize each of them differently during deployment.
This extension works well with the Custom Hostname and the Custom vCenter Folders extension to round out the use of Multi-Machine Blueprints.
Example Use Cases:
Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and customize the name of each component.
Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and customize the guest agent actions of each component machine.
Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and override the template for each component to deploy from a different source vCenter template for each component.
The goal of this extension is to limit blueprint sprawl and leverage the multi-machine construct to customize the component machines and rely less on customizing the single machine blueprints making them more re-usable.
This extension was designed and built as a collective effort by Tom Bonanno and Sid Smith. If you have any feedback please let us know.
Define which component machines to apply custom properties to in a multi-machine blueprint.
Utilize a singular blueprint for all component machines in a multi-machine blueprint.
Fixed bug that caused properties with Multiple periods not to be processed properly.
Remember we have performed a large amount of testing, but this is a v1.0 extension so please test and let us know if you find any issues.
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