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.
Continue reading “vRealize Orchestrator – vRO 6.0.1 is now available!”
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!
Thank You all,
Sid and Tina Smith
Live Free and Ride Hard
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.
Continue reading “vRealize Automation – vCAC 6.1 – Ultimate Multi-Machine Blueprint Extension v1.0.2 – Updated”
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.
Release Notes can be found here.
Download can be found here.
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:
- Build Profiles
- Business Groups
- Property Dictionary
- Virtual Machines
- and more
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.
Continue reading “vRealize Automation – vCAC 6.1 – Building vCO workflows for Multi-Machine Blueprints”
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
Continue reading “vRealize Automation – vCAC 6.1 – Custom vCenter Folder Extension”
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”
What is the cloud client you ask? The CloudClient is a verb based command-line utility aimed at simplifying interactions with multiple product api’s. The CloudClient also provides common security, exception handling, json, & CVS support. Currently vRealize Automation (vRA)( Formerly vCAC), Site Recovery Manager (SRM), & vRealize Orchestrator (vRO)(Formerly vCO).
Continue reading “VMware vRealize Cloud Client 3.0 is GA”