In my previous article about the SovLabs plugin I covered some pre-requisites and sent you over to the SovLabs documentation to finish the installation. Once you have installed the vRO plugin using the vRO Control Center you will go to your vRO Client and see a new folder that has all the Sovlabs vRO modules.
If you haven’t read Part 1 of this article you will want to go back and read it before you proceed. In part 2 we will build on the installation that we performed in part 1. Let’s just dig right in and get started.
How this integration works
Configuring the integration to use native vRA authentication requires the user to login to ServiceNow and vRA both. When the user logs into ServiceNow they are redirected to the vRA Login page and was logged in they are then redirected back to ServiceNow. This allows requests the user makes to be passed to vRA as that user. The main difference between this and the SAML (ADFS) integration is the user only need to login to vRA the very first time they use it and never again as the user is auto-magically logged in to vRA in the background using the SAML token. This is a great option for testing the integration without having to touch your Identity Management configuration.
It seems like everyone these days wants to use ServiceNow as their catalog for vRA. It use to be that everyone just wanted to create or update CI records. Before I get into the weeds on how to get vRA and ServiceNow talking together I wanted to take a few minutes to discuss the integration, the pros, the cons, and it’s limitation.
There are lots of reasons to want to export and import blueprints from one vRA instance to another. My current motives are to move blueprints from my vRA 7.2 environment to my newly deployed vRA 7.3 environment. In vRA 7.3 their is a great new free feature available, the Code Stream Management Pack for IT Devops that is free. However if you are running a pre vRA 7.3 environment you may want to get that content from that environment backed up so you can use it in another instance. Cloud Client is a great option.
Some of you may have attended the vRA and ServiceNow presentation at VMworld 2017 yesterday. I regret not being able to attend and present it myself, however I’m certain that Chris Smith and Ian Smith did a fantastic job. Here I want to recap some of what was presented during that session.
It’s important to understand what options are available and what features they offer in order to understand what you really need when integrating with ServiceNow. To start do you need what is referred to as North/South integration, East/West Integration, or both. Below is a list of what capabilities fall under each classification.
|ServiceNow used as Catalog||vRA used as Catalog|
|VMware vRealize Automation handles automation and orchestration.||VMware vRealize Automation handles automation and orchestration.|
|Create or update CI records||Create or update CI records|
|Available via VMware ITSM plugin, AVNet Plugin, or Custom REST API integration.||Available via VMware ITSM plugin, SovLabs plugin, Avnet Plugin, or custom vRealize Orchestrator workflows.|
If you have been to the VMware Solutions Exchange you most certainly have seen the name SovLabs. Although their solutions are regularly called plug-ins, I assure you they offer more than just orchestrator-based plug-ins. I first started working with their solutions earlier this year and I was instantly hooked. Many of you have used vRO extensions that were made available by Tom Bonanno or myself posted here on Dailyhypervisor. One in particular is the custom hostname extension for vRA. While that extension has helped hundreds if not more of you, many of you quickly discovered the downside of using it. That downside being management overhead and lack of support. As much as we would have liked to offer support to those in need we simply don’t have the bandwidth to do so. Even upgrading the extension we put out for new versions of vRA in a timely manner had its challenges for us.
Still running vRA 6.x, then you will be happy to hear vRA 6.2.5 is now GA and boast some great performance improvements. See blow for more details.
Whew the last few days have been full of new releases and VMware is not done yet. I’m not going to spoil anything but I will tell you that the release of vRealize Orchestrator 6.0.5 is not the last announcement you will be seeing from me. I anticipate some other exciting news next week. FOr now check out what’s new in vRO and stay tuned.
vRealize Orchestrator 6.0.5 is a patch release that introduces a number of improvements and bug fixes.
- Enhanced workflow logging, including messages that mark the start and the end of the workflow run. In case of failure, the log captures the workflow ID, the request ID, and the exception.
- Added ability to run a Debugger in the Orchestrator client when the request is generated by an external system, such as vRealize Automation, the vCenter Web Client, or a REST endpoint.
- Introduced Spanish locale support for the Orchestrator plug-in for vSphere Web Client.
vRealize Orchestrator 6.0.5 also introduces Control Center, which delivers a more flexible configuring, monitoring, and troubleshooting experience. Control Center contains multiple built-in capabilities:
- Cancel workflow runs
- vRealize Orchestrator runtime dashboard
Unveiling Project Clarity – VMware CTO Blog
Today we’re ecstatic to announce Project Clarity, a design system that combines UX guidelines, patterns, and front-end code in one solution. Clarity is for the designer and developer in each of us.
It’s no secret that this is a feature that I’m very excited about. This feature although very useful on it’s own is going to open up the door for many new exciting capabilities with out VMware products in the future.
Resource contention is one of the most critical issues in any virtualized environment. When contention occurs, applications slow down and your users are affected. Up until now two different methodologies have been employed to mitigate the risk of contention, with varied results. But now I want to introduce you to the new “game changing” method available from VMware: Predictive DRS! But first a bit of a history lesson on the original two methods.
The first of these is the Reactive Method which focuses on resolving unexpected resource demand. The most widely used example of a reactive solution is VMware’s Distributed Resource Scheduler, or DRS. As the day progresses, workloads may need more resources, which can lead to contention on the host. The reactive method moves VMs around to ensure all workloads get the resources they need and applications remain healthy. Note this method needs only a minimal amount of VMs to be moved in order to be effective, which means minimal overhead. The reactive method only moves VMs when contention approaches, so it’s possible (however remote) for users to feel some effects of the contention before it’s resolved.
Learn more about the other methods available with predictive DRS in the original article on VMware Cloud Management blog site.