Posted on

SovLabs vRealize Automation Optimization and Upgrade Analysis Tool

SovLabs has been busy developing a tool that is intended to analyse your vRealize Automation 7 environment and provide helpful feedback on areas where you can optimize.  The tool collects data on dozens of vRealize Automation 7 constructs such as number of blueprints, types of blueprints, number of business groups, network profiles, reservations, etc. and looks for key indicators to see if there is room for optimization.  It also goes a step further and looks for items that could create challenges when customers are looking to migrate to vRealize Automation 8.

The goal here is to optimize your vRealize Automation 7 environments before adopting vRealize Automation 8.  We all acknowledge that vRealize Automation 7 will be around for at least another 18-24 months –  if not longer. Even if you are making the move to vRealize Automation 8 today, you will likely still be maintaining your vRealize Automation 7 environments alongside for some time to come. By optimizing your vRealize Automation 7 environments you will be reducing the maintenance overhead required for your current environment while also making it easier to migrate and adopt your solution on vRealize Automation 8.  The more aligned the two instances are, the simpler it will be to maintain both environments side by side.

The best part is it’s free, yes that is correct I said free.  You simply register at https://www.sovlabs.com/vrealize-automation-optimization-assessment and, once registered, a member of the SovLabs team will reach out to assist you with the data collection.  The data is done using a vRO workflow that produces a JSON output. The data that is collected is non-identifying or sensitive so you don’t have to worry.  The data collected is also presented in plain text so you can review the data before you send it back to Sovlabs for analysis. If you have more than one vRealize Automation 7 environment you can run the collector for each environment and then zip all the files together for upload.

Once data collection is complete, you then head over to https://optimize.sovlabs.com/ and upload your results file.  From there the folks at SovLabs will take the result, run it through their analysis tool and produce a report detailing all the areas where you can optimize your vRealize Automation 7 environment(s).  A SovLabs technical representative will reach out to schedule a time to go over the report and send you a copy. Whether you are looking to Optimize your vRealize Automation 7 environment or gain some insight into your pending vRealize Automation 8 migration, the SovLabs Optimization and Upgrade Assessment provides great information and insights to help plan and prepare your automation path.

Posted on

vRealize Automation 8 – A First Look at the vRA8 Migration Assessment Tool — Part 1 of 2

vRealize Automation veterans may still remember the migrations from vRA 5.x to 6.x and 6.x to 7.x. However, for many enterprises utilizing vRealize Automation, the migration from vRA 7.x to vRA 8.x will be your first major vRA migration. In an ideal world these migrations would only take a few clicks of the mouse.  Migrating from vRA7.x to vRA8.x is going to be a lot like switching banks. Trying to figure out all the services that have your bank card on file for automatic billing and moving over automatic bill payments is tedious and time consuming. Which payments are monthly, quarterly, annually, and for how much? Wouldn’t it be nice if there were a simple tool to identify and update all the services that you have on auto-pay?

SIGN UP FOR THE VRA8 BLOG SERIES & WEBINAR

vRealize Automation is a lot like that.  Whether it’s frequently deployed common workloads, special purpose blueprints that are used a few times a month, quarterly, or a handful or fewer times a year, or software customizations specific to vRA, you have to identify everything that will require hand-holding when you begin the migration from vRA7 to vRA8. The good news is that, unlike your bank, VMware does offer a migration assessment tool to help you determine if your blueprints are ready to be migrated from vRA7 to vRA8. As of this writing, we have not yet learned if the migration assessment tool will determine if your customizations and workloads are ready for migration.

Read the full article here.

Posted on

How to Create vRealize Automation Global Properties with the SovLabs Property Toolkit

If you have not yet read my recent series Harness the Power of vRealize Automation (vRA) with the SovLabs Property Toolkit and Template Engine, I would encourage you to do so. This 3-part series will provide you with some interesting ways to get more out of vRealize Automation using the software solutions provided by SovLabs. In this article I will be coveringa topic closely related to my previous articles and showcasing even more value when you use the SovLabs Property Toolkit.

Global Properties

If I had a dollar for every time someone asked me, “Is there a place to define global properties in vRA?” throughout my career, I probably could have retired by now.  The unfortunate answer to this question has always been “it does not”, but there is a way to apply properties to every request. Keep reading.

The Old Way

The old way to define global properties in vRA was to add the properties you wanted applied globally to each and every endpoint you had configured in vRA.  So, if you had 25 endpoints and 20 properties you ended up have to enter 500 properties and 500 values. This method leads to inevitable typos, finger fatigue, and management overhead every time you need to update a value for any one of those properties or add a new property.

To see the new more efficient way read the rest of the article on the SovLabs blog site here.

Posted on

Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine – Part 1

Ever wish you were able to set more than one value from a single vRealize Automation (vRA) request input?  Have you ever wished you could make some aspects of vRA more dynamic and flexible? Wish you could simplify the vRA request form?  In this article I’m going to let the genie out of the bottle. All your wishes are about to come true. But before we summon our genie, let’s first dive into what it is that we are going to be wishing for.  My wish is to have a simple vRA request page with only three inputs that can drive the outcome of every aspect of my request. Sounds too good to be true doesn’t it? We will find out soon enough.

Finished Result
Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine 1
Determine the needed Inputs

Determining what our inputs are going to be.  For my scenario I need to the following three inputs:

  1. The Environment (Production, Development, or Test)
  2. The Application (WordPress or Microsoft SQL)
  3. Compliance Needs (SOX or Non-SOX)

In my example, these are the only three items I need to know from the requester to build a server in my environment.  The remaining info I can gather from the business group they belong to, what resources the workload is placed on, etc. I know every environment is different and many will require more than three inputs.  Once you have read this entire 3-Part series, you will realize the number of inputs doesn’t matter. It’s how we use them that’s key.

Determine the outcome

What outcomes do we need to drive based on these inputs?  Or, how will these help determine the outcome of the overall deployment?  Will they influence items such as the machine hostname, Active Directory OU placement, vCenter Folder placement, vSphere tagging, application installation, etc?

Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine 2

To read the full article please visit the SovLabs blog located here.

Posted on

Road to Automation with VMware vRA – vRA Design Part 1

GSS has decided on a number of design considerations for their vRA implementation.  GSS is currently using a consumption based model for their resource allocation.  They don’t pre-reserve any amount of resources for specific groups within the organization.  GSS feels their current consumption model allows them to more efficiently manage their resources.  It also prevents them from having pockets of idol resources that may never get used.  Based on this utilization model GSS will be implementing the following elements within vRA.

GSS  considered having a business group for each environment (Dev, Test, Stage, and Production).  To evaluate how they would like to proceed they asked to have 5 initial tenants created.  One for each of their environments and one to evaluate a collapsed model of all environments in one group.

Business Groups

  •  Development – All Developers across all groups within GSS
  • Test – All QA engineers within GSS
  • Stage – All production teams
  • Production – All Production teams
  • Gregarious – All Dev, QA, and Production teams

Continue reading “Road to Automation with VMware vRA – vRA Design Part 1”

Posted on

Road to Automation with VMware vRA – GSS Company Profile

In my previous article The Road to automation with VMware vRA I discussed I would be published a company profile for my fictitious company GSS.  In this article we will be digging into GSS to take a look at where it is today, its challenges, processes, systems, and automation use cases.

Company: (GSS) Gregarious Simulation Systems
Profile: Successful Video Game Manufacturer
Employees: 1200+
IT Staff: 80+
vSphere Sockets: 200+
Managed VMs: 3000+
Server Build Team: 12
Environments: Development, Test, Stage, Production

Continue reading “Road to Automation with VMware vRA – GSS Company Profile”

Posted on

The road to automation with VMware vRA

I think we need to take a few steps back and focus on vRA architecture and design.  I’ve had many questions, requests, and discussions with some of my readers on this topic.  Implementing vRA can lead to many rewarding outcomes, but as some have discovered it can also lead to aggravating outcomes if not designed properly upfront.

At first it can seem very straight forward. Create some endpoints, groups, reservations, and blueprints.  Sprinkle in some integrations for custom hostname, IPAM, DNS and AD and you are on your way to fully automating your workload deployments, right?  Not exactly.  You can certainly do this and at first it will seem amazing, but as you mature and start to scale out your new catalog of services the lack of up front design and planning will quickly start to reveal itself.

Continue reading “The road to automation with VMware vRA”

Posted on

My vRA Journey Continues

Many of you may have already heard after 6 years at VMware I decided to spread my wings and go back to the world from which I came.  I joined VMware when they acquired DynamicOps a little over 6 years ago, and after 6 great years at VMware I decided to move on to something new, but not so new.

If it doesn’t show from my blog I am very passionate about automation.   I’m even more passionate about helping organizations overcome all the challenges they face during their journey towards automation.  Having been working with vRA for over 10 years I’ve learned a lot.  I’ve learned the countless ways different organizations go about achieving the same end result.  I’ve learned the challenges with automation in the datacenter.  I’ve learned I could probably write endlessly about what I have learned Winking smile

Continue reading “My vRA Journey Continues”

Posted on

vRA 7.3 – Configuring SovLabs Custom Naming Module

Many of you have utilized the Custom Hostname module that has been made available by Tom Bonanno here on Dailyhypervisor.  Those that use have probably noticed that it is no longer maintained.  This is because there are supportable modules available like the one I’m writing about now by SovLabs.  The Sovlabs module offers more flexibility and is a supported product making it a best of breed solution for this task.  Whats even better is their is a common framework that exists within the SovLabs platform that greatly extends the capabilities of each module.  More of the framework to come.  For now let’s go ahead and configure the custom hostname module.

Within the SovLabs custom naming module hostnames are broken in to two parts.  A Naming Sequence and a Naming Standard.

Naming Sequences

Naming sequences are exactly exactly what they sound like.  They basically define how are we going to sequence the names that are created.  Sounds basic right?  Well SovLabs has taken sequencing to a whole new level.  Most of you are probably familiar with using a standard decimal based sequence that might look like host001, host002, and so on.  SovLabs has added the ability to use HexaDecimal, Octal, and Pattern based sequences for your naming needs.  Pattern based sequences are insanely powerful.   Pattern naming sequences can contain Decimal, HexaDecimal, Octal, Binary, and Alpha.  Below are an examples of what you can achieve with Pattern Based naming sequences:
Continue reading “vRA 7.3 – Configuring SovLabs Custom Naming Module”