Extend vRA UI Login Timeout

Nothing frustrates me more than returning to the vRA UI, clicking something and then have it immediately log me out. This appears to be quite random a lot of the time and whilst I can appreciate that this is in the interest of security, I find it a little too aggressive. This can be changed by extending the life of the authentication cookie using the following procedure.

Log in to the vRA appliance using SSH (SSH will need to be enabled via the vRA Appliance VAMI interface if it is not already). Edit the following file:

Add the following line to the end of the file:

Where ‘28800’ is the number of seconds (8 hours) until the authentication cookie expires. Set this based on your own requirements.

Save the file and then restart the vcac-server service

It will take the usual 5 minutes or so for the server to fully start up and once complete the new settings will be applied.

Repeat this process for any remaining appliances in the cluster.

vRealize Orchestrator cluster nodes not in sync with embedded vRA Appliance

I have come across this issue a number of times where the secondary vRO cluster node is not in sync with the primary node (one thing to note is that the synchronisation status is relative to the node you are logged on to).

The option to synchronise the nodes is not available because I am using vRO that comes embedded with the vRA appliance. The reason this option is not available is because vRA “should” be managing the state of the cluster nodes, which is does from a vRO client prospective but not when you make changes via the Control Center (such as changing the Admins group).

To workaround this issue and unlock the hidden options you will need to append “?advanced” to the end of the URL. For example, if you are on the Orchestrator Cluster Management page add ?advanced to the end of the URL, which should look like this:

https://vro_server:8283/vco-controlcenter/#/control-app/ha?advanced

When the page refreshes you will notice that a new button has appeared on the bottom.

Clicking on this button will reveal two new options:

  • Push Configuration
  • Push Configuration and restart nodes

Select “Push Configuration and restart nodes”, which will push the configuration and automatically restart the vRO service on the secondary node.

A message will be displayed if this is successful.

It will take approx 10 minutes for the secondary node to start up completely so grab a coffee at this point.

Refresh and both nodes should now show as “Synchronized”.

Remove ‘Default Machine Prefix’ for a Business Group

When I was building vRA 7 and figuring everything out, at some point I set the ‘Default machine prefix‘ for the Business Groups. When you first create a Business Group, setting the default machine prefix is optional; However, if you do set this value then there is no way to unset it, which I find extremely annoying. As I don’t currently use specific prefixes for business groups, I was feeling a little OCD having to set this to some other prefix value.

defaultprefix

I was able to ignore this for a while until I installed the Custom Hostnaming Extension for vRA7 by Dailyypervisor. This extension is really awesome and has helped me massively overcome my requirement to create dynamically generated hostnames. The hostnames are based on our internal naming convention and I make good use of Custom Properties for this. For testing, I simply created a very basic custom hostname scheme ‘{LOC}-GSTEST{##}’, with {LOC} being set on one of the vSphere endpoints.

hostnamescheme

At first this appeared to work just fine, until randomly some machines would be provisioned using a different hostname. The other hostname was based on another machine prefix that I had created previously and was configured as the default for the Business Group, which was ‘ES-VWOI-MANA##’. The image below shows the results of 7 machines provisioned using the custom hostname extension.

machines

Clearly what is happening here is that on each provisioning attempt, it is randomly selecting a different machine prefix. What is also interesting is that both prefixes get incremented. In fact, that’s another issue with having a default one set for the business group (or even within the Blueprint), is that they are ‘allocated’ and incremented even before the EBS is used (which is when the custom hostnaming extension kicks in, at the requested stage, which is still AFTER the allocation). I have had a small look at the code for the workflow and can see that it’s identifying that the custom hostname scheme already exists, but I haven’t yet looked into why it’s setting the wrong one.

I figured the easiest workaround for now would be to simply remove the default machine prefix from the business group and make sure no one accidently sets it. But this is when I realised you can’t do that by simply editing the group via the IaaS interface. To cut a long story short, you have to manually remove this on the database, both the SQL database used by IaaS and the PostGres database used by vRA.

Read More

Top 5 vRealize Automation Resources to get you started

OK, so everyone loves a top 5 so here is a list of my top 5 resources for learning and deploying vRealize Automation.

1. VMware Hands on Labs.

Take ‘HOL-SDC-1633 vRealize Automation 7: What’s New‘. – Despite the name this is a really in depth tutorial and you will want to complete the entire lab. This will give you a good feel about what vRA is capable of and how you can extend the platform. There are some really good examples of how the event broker is used to integrate with ITSM CMDB software for change control (iTop is used). The lab also dives into vRO and gives you a taste of just how powerful this product really is.

Next, take ‘HOL-SDC-1632 vRealize Automation Advanced: Integration and Extensibility‘. – Yes, this lab is based on vRA 6.2 so is a little older but most of the fundamentals are there and again provides some good examples of how the platform can be extended with vRO. Examples of extensibility with Infoblox IPAM, Puppet Enterprise and NSX (although slightly depreciated) are used.

2. vRealize Automation Reference Architecture

Once you have had some experience and insight from doing the hands on Labs you will be eager to begin planning and designing your new vRA platform. This document will provide you with a lot of details such as all of the components that are involved and how best to deploy and scale these. Also included are firewall and load balancing requirements. I cannot emphasis enough the importance of planning your vRA deployment properly from the get go as this will ultimately determine the success of the project.

3. Open902.com

I am really happy that I discovered this site before starting my vRA 7 implementation. Michael Rudloff has done a fantastic job of documenting the enterprise installation and configuring the IaaS platform so that you get some decent functionality out of it. These guides really took away a lot of the pain during the installation and covers topics such as replacing certificates, configuring an endpoint, approval policies, business groups, fabric groups, etc and has an awesome guide on Custom Property Relationships. I also like how has turned his private archive public and reminds me a lot of my private Confluence site.

Read More

What vRealize Automation is trying to solve

Before purchasing or installing the software one of the first things you need to understand is what vRA is trying to solve. Unlike what VMware has released previously, vRA is a very different and tries to solve the problems related to managing multiple cloud platforms and the end to end delivery of IT services. Yes, there are a lot of tools out there that can help in the delivery of these services but it very quickly starts to turn into a complex mismash of applications and processes. It’s also important to point out that vRA is not exclusive to vSphere but is designed to be platform agnostic. Think of vRA operating as the management plane in your data centre that plugs into all the services around it.

So when I talk about ‘end to end delivery of IT services’ what exactly am I referring to? Well, consider the example process below of bringing a new virtual server into service:

  • End user requests new virtual server, provides details and submits request to IT support services;
  • A change is raised on the ITSM CMDB platform;
  • Wait for change to be approved before provisioning starts (alternatively the request could be rejected and process cancelled);
  • When approved, begin the provisioning process;
    • Get the next available hostname (i.e. using a prefix and the next available number increment);
    • Request and reserve the next available IP address from the IPAM software and update the record to reflect the new server being provisioned;
    • Provision the virtual server with specific hardware configuration;
    • Add/update DNS records;
    • Add server to the Active Directory domain and place into the correct Organization Unit;
    • Update OS with latest security patches;
    • Add to existing firewall rules;
    • Generate SSL certificates;
    • Install software such as Anti-Virus and applications;
    • Add new Configuration Item with server details;
    • Update server inventory;
    • Add to monitoring system;
    • Mark change as complete;
  • Email End user that requested the virtual server that it is now ready;

You’ll agree, that this is a lot of steps for provisioning something like a virtual server and will involve multiple different teams (and think about doing this on many different cloud platforms). Most of the time, a lot of these steps are performed manually using run books but are sometimes overlooked and can cause delays in fulfilling the request or lead to problems later, like outdated information. We have tools like Puppet which help us with deployments, software installations, etc. but most of these are very Linux focused. They also do not address the other steps, or at least not in a very friendly way.

Finally, and more interestingly, think about when the virtual server is taken out of service or decommissioned. This is almost always where things get messy. I have seen really well laid out and robust commissioning procedures but nothing to support the decommissioning. Often, it’s a case of ‘best effort’ and items get missed and are usually discovered later, often after they have caused a problem or identified with routine audits of DNS or firewalls. In some cases this could even pose a security risk. When we think of all of this what we are actually referring to is ComplianceGovernance and Life Cycle Management.

My advise here is that even before you touch vRA, you need to think about how IT services are being provisioned within your organisation. This will involve engaging with the various operations or development teams and weed out every single process that is involved, how services are delivered, maintained, monitored and secured. You will need to fully understand the manual process and any automation that exists. Secondly, you will need to understand all of the applications that are being used to support these teams and how you will potentially interface with these during automated deployments.

vRealize Automation is designed to solve all of these problems. it is a fully extensible platform that allows Administrators to create policy driven processes for the provisioning of IT services. It does this whilst providing a catalog of available services that end users can simply request by providing some details and a couple of clicks of a button. Administrators are armed with a powerful Advanced Service Designer tool that allows items such as Virtual Servers or Software Components to be drag and dropped onto the design canvas and later submitted to the catalog. These ‘designs’ are what vRA refers to as blueprints.

Read More

A Virtualization Engineer’s Journey into the World of DevOps with vRealize Automation

Before I start this post I want to put it into perspective. Up until now I have been working in infrastructure roles for a number of years, specialising in virtualization (mostly VMware), servers, storage and networking. A lot has changed recently and we can’t go a day without hearing or reading about “DevOps”. I don’t want to get into what DevOps is and isn’t as there is plenty on Google for that but what is clear is that the role of the system admin / virtual engineer / [insert infrastructure role here] is changing and fast.

I had actually planned for this to be just two paragraphs long and the post was meant to have a slightly different focus. However, that didn’t quite go as planned, so happy reading!

We are now at the age of ‘Cloud Computing’ and the need for applications that are cloud native and can be moved around cloud providers with ease. As we’re in a state of transition and it may take some time to get there but until then everything is moving towards a ‘hybrid’ cloud model. As part of this, as infrastructure engineers, we need to be able to deliver infrastructure and services quickly and efficiently. Doing things manually, following a run book or similar is no longer desirable and we need to find a way to automate the end to end delivery of these services. As engineers we need to bridge the gap between operations and development. I’m not suggesting that we need to be developers but we need to be more closely aligned and have a much better understanding of the development life cycle and delivery model.

The Virtualization model allowed us to deliver Infrastructure as a Service (Iaas), Platform as a Service (PaaS), Software as a Service (SaaS) and so on. In the cloud model this has been extended to Everything as a Service (XaaS) and even serverless architectures! Now, the possibilities are endless and we need to start delivering hybrid IT services under this new model. Here are some examples (and no where near limited to):

  • Database as a Service;
  • Email as a Service;
  • Security as a Service;
  • Docker as a Service;
  • Operation services (user creation, mailbox creation, 3rd party application authorisation);
  • Enhancing IaaS and PaaS delivery with tighter integration into IPAM software (i.e. SolarWinds IPAM), ITSM CMDB (i.e. ServiceNow) and monitoring systems;

There are also a lot of tools out there today, typically referred to as ‘Continuous Delivery’ applications that can help us on our journey, such as (again not limited to):

  • Puppet
  • Chef
  • Ansible
  • Salt

These applications allow us to treat our infrastructure as code and automate the delivery of IT infrastructure with a touch of a button. Whilst these applications are extremely powerful and useful they do not by themselves solve all the problems of delivering hybrid IT services.

Read More

vRealize Automation 7 – Error – Unable to get metadata

So today my heart sunk when I tried to log into the vRA 7 IaaS portal and was presented with this lovely message:

vra_error1

Now, I had just recently attempted an upgrade of vRA 7.0.1 to 7.1 and failed miserably (more on that in a later post) so I had to roll back all of my changes (reverting snapshots, etc.) and brought all the services back. All seemed fine until I tried to log into the IaaS portal.

One of the first things I checked was the services registration on the vRA VAMI interface (Services tab). I thought perhaps the order of events of the rollback had skewed something. I observed the following:

vra_error3

So clearly something was afoot. I did a little digging and came across the following KB article:

Logging in to tenant fails after adding authenticated proxy config in VAMI in VMware vRealize Automation 7.0.x (2144067)

The interesting thing here, is that just a few hours before, I added a proxy server to the VAMI configuration in order to get the updates I needed from https://vapp-updates.vmware.com. As per the KB article I inspected the following log file:

Read More