Many of you may have already seen the news, but I like to create a roll up to make it easy to see what’s been newly released. Yesterday Tuesday August 23rd 2016 VMware released a number of much awaited Management product updates. See below for a breakdown of the updates per product.
vRealize Automation 7.1
vRealize Automation 7.1 is optimized for growing clouds thanks to significant improvements in the automated installation experience.
vRealize Automation 7.1 continue simplifying the primarily and secondary setup process by adding ability to automate the setup process among similar deployments leveraging the new Silent Installer. Cloud Admins are now able to scale out existing vRealize deployment by adding more vRA components and manage them automatically though the new Command Line(CLI) interface.
vRA 7.1 release is also equipped with a brand new Migration tool which allows you to perform safe and sound side by side upgrade (migration) existing vRealize Automation systems 6.2.X to the latest and greatest release. During the migration process the source production environment remains intact which guarantees a minimum downtime of the production environment.
Continue reading “VMware round of Q2 releases including vRA 7.1, vROPs 6.3, vRCS 2.1, Cloud Client 4.2, vRB 7.1 and more”
vRA 7 introduced a number of new and very useful features such as unified blueprints, software components, event broker, and others. The event broker however has proven itself to be one of the most power new features we have seen in some time. How so you ask? Well if you have been working with vRA for any period of time you will remember the old way of triggering external workflow executions such as those run by vRO. If you have been using vRA for a really long time you will remember back before vRO when vRA wasn’t even vRA and run nothing but .Net workflows, but we won’t go back that far.
Continue reading “VMware vRealize Automation – vRA7 – The dawn of the vRealize Automation 7 Event Broker”
Looking to prepare a Windows template for use with vRA7? Want to utilize the vRA Guest Agent as well as Software Components? Great! The very talented Gary Coburn has built a package that will it all for you. If you have ever prepped an image for use with vRA 6 or even vRA 7 you know it’s sort of a pain especially if you are like me and don’t like to read the documentation line by line. The first time I prepared a guest I figured ah this is simple I’ll just go and do it. Well that didn’t turn out to well. I had anticipated putting together an article on how to do it when a co-working on my team at VMware Gary Coburn built an awesome script that just does it all for you.
Continue reading “VMware vRealize Automation – vRA7 – Easily prepare Windows Server 2012 R2 templates for use with vRA7”
OK not too much on this one. If you wan to upgrade vRA to 7.0.1 and you want to use the plug-in in vRO 7.0 or 7.0.1 you will need this. That’s basically it. Just don’t forget you need this if you are upgrading and if you are doing a fresh install and are using a non embedded vRO server.
This is for all you MacBook users out there. If you are like me and run a VM to use the VMRC console, well those days are over. VMware Remote Console 7.1 for mac was released yesterday!
Last October, VMware announced the release of the first standalone VMware Remote Console application for Windows. Yesterday, VMware went live with the first-ever VMware Remote Console (VMRC) for Mac OS. Until the end of last year, VMRC has been a plug-in component in the web clients of vSphere, vCloud Director, and vRealize Automation. Until this release of VMRC for Mac, customers on Mac clients were limited to using a basic HTML console and a plugin-based device control.
Google has scheduled the deprecation of the Netscape Plugin API (NPAPI) in Chrome browsers in September 2015, which will stop the legacy VMware Remote Console plug-in in web clients from functioning. VMware will continue to add VMRC support for different platforms so that customers will have plugin-independent access to VM console functionality and operations, as well as client device connections to VMs on remote ESXi hosts.
VMRC can be launched directly from vSphere web client versions 5.5u2b and 6.0, as well as URLs specifying ESXi host and VM information. The application supports Mac OS 10.8 and up.
You can find the VMware Remote Console (VMRC) for Mac Download here.
FIlter vRealize Automation 6.2 has been released. This release although not a Major Version packs a pretty powerful punch. It’s loaded with new features and enhancements that you are all going to want. This release aims to add some features that solve some basic challenges that have been seen by many of you running the product in your production environments. Here is a breakdown of what is new in this release:
- vCloud Air EndPoint with support for Proxy Servers with vCloud Air
- Configurable email tempaltes
- Calendar of Events
- Use IaaS custom properties within Application Services (Application Services)
- Support for CloudFoundry as a deployment target (Application Services)
- vRealize Operations Integration including health badges in vRA Portal.
- XenDesktop 7.x Support
- Support for OpenStack Havana
- Ability to edit Custom Properties during approval time
- Scheduler for reconfigure operations
- Ability to change lease times to indefinite
- Enhanced Event and Audit Logging
- Log Bundle tool
- VM Disk Support for up to 60 disks (Previously 15)
- Improved Rest API
- API for Reservation Management
- Better control for DB log rollover
- Swap Space Custom Property to account for swap space on disk
- Filter Catalog by Business Groups
- Enhanced installation for easier HA deployments
- UI Performance Improvements
Continue reading “vRealize Automation – vRA (vCAC) 6.2 – vRealize Automation 6.2 released”
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.
Continue reading “vRealize Automation – vCAC 6.1 – Building vCO workflows for Multi-Machine Blueprints”
The out of the box vCAC –> NSX integration requires the use of Multi-Machine blueprints. Multi-Machine blueprints are basically a blueprint that pulls together one of more single-machine blueprint. In order to create a three tier web application like the one I will be walking through we will need three standard blueprints to utilize within our Multi-Machine blueprint. In the below example will be configuring a Multi-Machine blueprint that will deploy an NSX Edge Gateway on to it’s own reservation and then deploy three different blueprints each onto a different network specific to it’s tier. Example below:
I will be walking through how to create a Multi-Machine blueprint that will build out the equivalent of the above diagrams Multi-Machine App.
Continue reading “vRealize Automation – vCAC 6.1 / NSX 6.1 – Creating a Multi-Machine Blueprint w/NSX Routed Gateway Support”
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.
Continue reading “VMware NSX 6.1 & vCAC 6.1 – Connecting NSX to vCAC”
Item 2 updated for vRA 7
vCO Endpoints are used by vCAC when vCAC needs to execute vCO workflows. These can be out of the box workflows such as the NSX workflows, or they can be workflows that you created and want vCAC to execute as part of a deployment state transitions such as during building machine, machine provisioned, machine destroyed or various other master workflow states. vCAC cannot execute these workflows without first having a vCO endpoint to which it can query and call to execute. vCAC can pass machine custom properties and other information through to vCO as part of the execution to parameterize the workflows.
Continue reading “vRealize Automation – vCAC 6.1 – Adding a vCO Endpoint”