My six-year-old asked me to tell him a bedtime story and it went something like this.
Jimmy and Tommy are both vRA admins. Jimmy works for a large financial company and Tommy works for a large company that makes really cool stuff. Both Jimmy and Tommy made great decisions to use vRA to automate their private clouds. Jimmy decided his organization was going to build all their own integrations. Tommy decided to use the SovLabs plugin for all his organizations needs.
Four weeks after Tommy’s vRA deployment his company was using vRA to deploy 75% of their virtual deployments. Meanwhile after four weeks Jimmy is just getting started designing the first of many needed integrations. Fast forward a year and Tommy’s organization is now deploying 100% of their workloads. They have reduced management overhead by 45%, and are able to deploy new server requests in under an hour.
A year later Jimmy’s company is still working out bugs with their custom code. Their administrative overhead is up 55% and it still takes over two-weeks for new server requests to be fulfilled. Jimmy is working 80+ hours a week and perpetually stressed. Tommy on the other hand is working 30 hours a week, but don’t tell his boss. He is enjoying his job and has next to no stress.
I then ask my six-year-old who he would rather be Jimmy or Tommy? He responded neither daddy I would rather be you. I asked him why he said he wanted to be me. He responded, because daddy you helped Tommy only have to work 30 hours a week.
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.
Development – All Developers across all groups within GSS
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
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 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”
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.
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.
While I was away on vacation last week it seems VMware had another exciting round of releasing starting with the Release of vRA 7.2. Probably the most anticipated feature is the new Azure Endpoint. Although this is a very exciting feature there are some other very exciting enhancements as well. Enhancements to the API, container support, installation API, and one of my personal favorites Scale out/scale in.
GA date: 22 November 2016
The vRealize Automation 7.2 release includes resolved issues and the following changes:
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.