Deploying a Nested Lab Environment with vRA - Part 4

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 this blog series. The first part covered the background for the project and the underlying environment as well as the initial vRA configuration. Part 2 covered the vRA blueprint and part 3 covered the vRO workflows that runs the extensibility. This fourth part will summarize, discuss a few bugs/quirks and describe some of the future plans.

I've listed the different blog posts on this page where I'll add any future posts about the project. All of the workflows and the Powershell scripts can be found on GitHub

A few bugs and quirks

In the current version of this project there are some bugs and quirks I need to sort out, or that's at least nice to know of for people following the series

• Deployment time is around 45 minutes for a three ESXi environment. There are a few things that could make it faster, i.e. instant clones, less EBS workflows etc, but we can live with this for the moment. If it becomes an issue we need to rethink, maybe have a predeployed environment ready to start up at request time (Hi vApp!)?
• The VCSA VM will not be part of the vRA deployment. I want to import the machine to vRA both for making the deployment there complete, but also as this will let vRA destroy the VCSA when the deployment is destroyed
• Referring to the previous point, as long as the VCSA is managed outside of vRA a destroy command on the deployment won't be able to finish as the VCSA will be running in the vApp and use the on-demand NAT network. This will be solved by adding the VCSA to the deployment or running a EBS workflow as part of the destroy process
• Currently I'm not allowing users to adjust the resources for the components through vRA
• The NSX-T on demand stuff is only visible in the "Advanced" section. This is because of the API vRA uses (Management API vs the Policy API). Might not be a problem, but something to be aware of
• The Powershell scripts and commands are "buried" in vRO workflows or script configurations and not very accessible. This is something I hope will be better when replicating this in vRA 8.x. I'm also very hopeful that the 8.1 version will be able to run some of the Powershell stuff without needing the Guest Script package
• User notification needs to be done somehow. This solution will (hopefully) used by quite a few people and I need to inform about status and the details for their environment. And I will try to solve this without using emails
• As I discussed briefly in part 1 the project is built with vRA 7.6 and with 8.1 released this week I think I now sooner rather than later need to migrate

Summary and next steps

This project has been a lot of work and a lot of fun. And it's not nearly finished!

I must say that some of the work was a bit harder than expected, i.e. getting the VCSA stuff run correctly via vRO and the network/NSX stuff. Hopefully some of that will be easier in vRA 8.1.

The future additions includes above all the ability to do customizations to the deployed environment:

• Adjust resources
• Scale resources
• Other vSphere versions
• Select additional deployment options like vSAN, NSX, vRealize suite, Active Directory etc
• Integrate with an existing Horizon environment, i.e. let the user have the Jump host available in Horizon/Workspace One which we have running

I suspect this list to grow going forward, and who knows, maybe it'll result in a continuation of this series.

Stay tuned and thanks for reading!