Deploying a Nested Lab Environment with vRA - Part 2

Over the last weeks I've worked on building out a vRA blueprint with lots of vRO workflows that deploys a nested vSphere lab environment.

I'll go through the project in a this blog series. The first part describing the background for the project and covered the underlying environment and vRA configuration. This is part 2 and will cover the vRA blueprint, while the next part will cover the vRO workflows that runs the extensibility. Part 4 will summarize the status of the project, discuss a few bugs/quirks and describe some of the future plans

Building out the vRA blueprint

With the vRA resource and networking configuration done, which we discussed in the previous post, we can finally start building our blueprint!

Blueprint settings

First off, we need to configure the NSX settings on the blueprint. Specify the Transport zone to use, and which reservation to deploy the NSX management resources to. Note that you won't actually see the NSX edge component / T1 router in the vRA blueprint, but you can control some of the deployment properties in the Blueprint Properties tab if you need to.

More information about adding NSX-T components can be found in the vRA documentation

\

I'm adding a few custom properties to the blueprint which I'll use when customising components later on with vRO. I've predefined these as Property Definitions in the Property Dictionary.

\

Blueprint components

There will be 3 vSphere virtual machine components, two networks and a XaaS vApp component in the blueprint.

\

Windows VMs

Both the Jump and DNS machines will be built by cloning a Windows 2019 template, and I've specified a OS customization profile as well. I'm using an existing Win 2019 template and profile.

The Jump component have two NICs, one connected to the ext network and one to the labnat network. The DNS component will only be connected to the labnat network.

ESXi VMs

The ESXi component is built with the "ImportOvfWorkflow" as I'm using the Nested ESXi appliance created by William Lam. A huge thanks to him for sharing his work.

\

This needs to be configured so you'll have to have the OVA available on a network location, and paste the URL into the Build Information tab. After pasting your URL you go ahead and click configure and you can configure the OVA properties as you would if deploying directly to vCenter

\

All of the machine components have some Extensibility properties set and they have a custom property specifying the name prefix which will be used in vRO later on. One thing to be aware of is that by default the true/false values in the OVF configuration is all lower case, but I've found that it needs to start with a capital letter to work

vApp

The vApp is defined as an XaaS component and will be created with a custom vRO workflow. There is a builtin Orchestrator type for VirtualApps, but no builtin create/destroy workflows so I've built these myself.

\

In vRA we create a Custom Resource tied to the Orchestrator type

\

Then define the XaaS blueprint for creating the vApp by selecting the Create workflow

\

Tie the provisioned resource to the correct vRA resource type

\

And finally add the Delete workflow as the Destroy action so that vRA will be able to delete the vApp when destroying the environment

\

I also have workflows for moving VMs to and from a vApp which could be added as Resource actions, but they are not needed in vRA for this scenario (the Move to are run through an Event subscription)

Request form

I've configured a custom form for the blueprint. Currently there's not lot's of configurable parameters, but this will grow in the future. I'll discuss a few plans in part 4 of this series.

\

The form has some hidden fields that are bound to the user input fields

\

The NOLab.NumESXi binds to the count of ESXi hosts wanted and are used later on by the vRO workflows for adding DNS records and optionally add them to the deployed vCenter. The vApp name field is bound to the Environment Name (NOLab.EnvName) so the vApp will have the same name as the deployment.

Summary

So with the blueprint ready to go we will see how we can do some extensibility, namely configure the components and of course deploy our vCenter appliance.

As mentioned I'm doing the extensibility through vRO workflows running as Event subscriptions in vRA. Some of that could probably be solved by using Software components in vRA, and it might be somewhat easier, but I work mostly with vRO so I chose that route. Check out the vRO workflows in the next post in this series.

Thanks for reading!