This is just a quick post that is more for personal reference more than anything.

:rotating_light: I need to point out that this is probably not supported by VMware so please don’t carry out the steps below unless you fully accept that you could cause irreversible damage to your environment.

I needed to move my original test design around a bit and this involved installing new highly available DEM Ochestrators and removing the old one.

Uninstalling the old DEM Orchestrator instance wasn’t a problem, however, I noticed that it was still listed in Distributed Execution Status as offline.

Here are the steps that I took to fully remove the old DEM Orchestrator from my environment:

• Snapshot, snapshot, snapshot!
• Install the two new DEM Orchestrator instances
• Uninstall the old DEM Orchestrator instance
• Back up your IAAS database!
• Remove the old DEM Orchestrator entry from the IAAS database

I needed to migrate quite a few vRealize Automation machine prefixes over to a new instance of vRealize Automation and found myself wondering if I could automate it. I was quite surprised to find that you can’t do this with the public API at the moment, so decided to give cloudclient a try.

It turns out that you can export a list of machine prefixes to a file, formatted in either JSON or CSV. However, importing still looks like a manual job.

Here is a quick(ha) post outlining how semi automated the process with Python and PowerShell examples.

So it looks like this post has accidentally become part two of a two post series. I would recommend going through the first post before this one as it will probably fill in some gaps.

• Creating a vRealize Automation Reservation with vRAAPIClient
• Creating a vRealize Automation Reservation with vRAAPIClient - Part 2: Jinja2 Templating

Resources for this post can be found in examples/reservation/createReservationJinja2.

This post extends the idea of reusable reservation templates by adding Jinja2 in to the mix.

Jinja2 allows us to adapt our existing reservationTemplate.json file so it can be used to create multiple reservations without having to play with the file every time we need to make a change. In my opinion, there is nothing worse than debugging json, so if you can get it right once and never have to touch it again, bonus points!

The following example is pretty basic and we will only be working with name and subtenantId but hopefully by the end of the post you will get the idea.

Automating things that you work with is cool

For those that know me in the IT world, you will know that I like to automate things.. well everything I can get my hands on. And with the impending career change I can only imagine that the things I get to automate are going to get even more interesting.

For a while now I’ve been working with vRealize Automation, and naturally it’s API. As an exercise to try and understand a bit more about how the API works I decided to start vRAAPIClient.

With the addition of the reservation-service I thought it would be good to try and understand how it ticks and in turn add it to the project.

I’ve found that the best way to automate reservation creation and in fact a few other areas of vRA is to work from a template. In the following post we will create a reusable json payload that will allow us to quickly create new reservations.

There will be two parts to this post:

• Creating a vRealize Automation Reservation with vRAAPIClient
• Creating a vRealize Automation Reservation with vRAAPIClient - Part 2: Jinja2 Templating

⚠️ Disclaimer: The vRAAPIClient project is provided as is! Please don’t run it in production without testing first

To cut a long story short, I needed to customise the email body for the Lease About To Expire scenario. The content was very basic and it the short date it contained was in the wrong format (for my environment).

vRA email templates are split between the virtual appliance, which uses Apache Velocity templates and the IAAS host which currently uses XSLT stylesheets.