Using the new Azure endpoint in vRA 7.2: My experiences

One of the improvements in VMware’s vRealize Automation 7.2, is the support for Microsoft Azure. Azure provides a lot of different IaaS and PaaS services. The Azure integration that’s included in vRealize Automation is focussed on virtual machine deployment, and thus a way to provide Azure IaaS services in vRA’s self-service portal.

Some details on the vRealize Automation endpoint

The Azure endpoint in vRA 7.2 is available out-of-the-box. This new endpoint is a little different when compared to existing endpoints. All existing endpoints in vRA were provided through the Windows infrastructure server: the ‘legacy part’ of vRealize Automation and the heritage of the DynamicOps acquisition.

The Azure endpoint is provided through vRealize Orchestrator, and requires a different approach. After the successful configuration of the endpoint, vRA operations is more or less the same when compared to the traditional endpoints: you can create a blueprint and then drag and drop Azure VMs to the canvas of the converged blueprint designer. After publishing the portal, Azure virtual machines can be requested and deployed via the self-service portal. After an Azure VM is deployed, it will appear in the items tab of vRealize Automation.

The new Azure endpoint is configured as an orchestrator XaaS endpoint. The endpoint has to be configured in the tenant that will consume Azure resources.

A lot of vRA deployments leverage the concept of a resource tenant: in this case endpoints are configured in the default (resource) tenant and consumed by separate customer tenants. More details on this configuration are provided in figure on the right.

Because the Azure endpoint is a vRealize Orchestrator endpoint, you should configure the endpoint in the customer tenant and not in the resource tenant. It’s currently not possible to provide resources from a vRO endpoint to another (customer) tenant.

Configure the Azure endpoint

Because the endpoint is a vRealize Orchestrator endpoint, you will find the configuration under Administration->vRO Configuration->Endpoints in the vRA interface.

Add an Azure endpoint and enter the following information:

• Connection name – The name of the connection, just think of a descriptive name;
• Azure subscription id – ID of your Azure subscription (more on this later);
• Azure service URI – Just leave the default: https://management.azure.com/;
• Tenant id – The ID of your tenant (more on this later);
• Client id – ID of the client (user) that is allowed to connect to Azure;
• Client secret – Secret key to authenticate the client;
• Login URL – Just leave the default: https://login.windows.net/.

The Azure subscription id and tenant id can be retrieved through the Azure x-pat CLI. The x-pat CLI is available for Windows, Linux and Mac.

First connect to Azure:

azure login

The next step is to retrieve your Azure account details:

azure account show

This command will display the subscription- and tenant id.

At vaficionado.com you will find a detailed step-by-step guide of the configuration of the endpoint. This guide will also provide some information on how to create the client id and corresponding secret.

Creating an Azure reservation

After a successful creation of the Azure endpoint you can create a reservation. Notice that you should be a fabric admin to be able to create the reservation.

An Azure reservation is bit different when compared to a vSphere or vCloud Air reservation. An Azure reservation in vRA is linked to a Azure subscription, resource group, storage account and some network settings. Unfortunately, you cannot set any limits on the amount of resources that are consumed by the reservation. This means that a user can consume unlimited resources, unless you implement some other mechanism like an approval workflow. It’s currently also not possible to link any custom properties to this new reservation.

I also noticed that no information is provided on the consumed resources in the Azure reservation. After deploying a virtual machine to Azure, all counters remain empty:

In case you want to know: the concept of a Compute Resource is not implemented for an Azure endpoint.

Create and deploy a blueprint

After the creation of an endpoint and reservation, you can create a blueprint and add Azure virtual machines to the blueprint. An Azure VM, that is part of a blueprint, contains a lot of Azure specific settings, such as:

• Location – Which Azure region is used;
• Image – Azure image to be used;
• Authentication – Authentication for the newly created VM;
• Instance size – You have to use the Azure t-shirt sizes and select pre-defined size, such as A0, D1, etc.
• Resource group – The resource group to be used;
• Storage account – The storage account to be used;
• Network settings – You can provide a lot of different network settings, including some load balancer settings.

After the configuration of the blueprint, you can publish the blueprint to the self-service portal of vRA. The request form shows that you’re actually doing an XaaS (anything-as-a-service) deployment. This is true, the Azure endpoint is heavily relying on vRealize Orchestrator.

After a successful deployment the Azure VM will appear in the items list of vRA. Unfortunately the VM will not appear in the machines list, but only as part of a deployment. Apparently only VMs deployed by the infrastructure server will be included in this list. Currently there are only three day 2 operations available, that are: start, stop and delete.

Azure endpoint: behind the scenes

The Azure endpoint is a vRO endpoint and the XaaS functionality of vRA is used to deploy, start, stop and remove Azure virtual machines. You might ask yourself now, how are things managed in vRO? Well, let’s have a look at vRO and investigate the available Azure workflows.

The vRO plugin adds an Azure folder to the vRO library, but more important some vRA specific workflows are added as well. Let’s have a look at the System->vRealize Automation->Endpoint->Azure folder:

All available actions in vRA are represented by their respective workflows in vRO. Just browse through the available workflows yourself to get an idea of what’s going on.

It’s also interesting to have a look at the Azure vRO plugin, you will get an overview of your Azure hierarchy. Deployed VMs are diplayed here as well, and you can retrieve some additional details on the virtual machines.

I hope this was helpful and you have an idea of the new Azure integration that’s part of vRealize Automation 7.2. If you have any questions, feel free to leave a comment below.