Month: January 2020

Home Lab for the Ramblings

There are many blogs and resources available providing very good help on setting up a home lab. This post is not one of those. There are also some amazing home labs out there. Check out the #homelabking and yes – @MarcHubbert is the King. This is not about one of those awesome home labs either. I’m just sharing my home lab setup I built on the cheap to support my vRA addiction and just a bit on how to automate it.

Home Lab

The lab details.

  • Intel NUC8i5BEH, 64GB Ram, 1TB Samsung NVMe SSD
  • iMac (27-inch, Late 2009) 2.8 GHz Core i7, 12 GB Ram
  • Two Raspberry PI 3b+
  • Ubiquiti EdgeRouter X
  • Ubiquiti Access Point
  • Artillery Sidewinder X1 3d printer
  • AWS Account

That’s it. I can do everything I want to do with this setup. I will be expanding in the future to dive into the VMware PKS stack, but for now it suits my needs.

The lab consists of a single Intel NUC running ESXI 6.7u3 booting from a USB drive. The internal 1TB SSD is all used as a single datastore. It is running as simple as possible of a ESXI configuration with a single network, no DRS, no vMotion, no vSAN, etc. This host supports vRA, vRO, vIDM, vRLCM, and a Bitnami gitlab server. It is also utilized for on-premise workload deployments from vRA. AWS is my primary compute datacenter for vRA deployments as it is pretty easy to melt the NUC running the vRealize stack.

ESXI Usage

The brain of the lab is a 10 year old iMac running High Sierra which is also my primary home computer. I would so like to upgrade but this thing just keeps on running. The iMac is running a vCenter Server Appliance as a VM under VMware Fusion 8.5. It is also used for running vRO client, PowerShell scripts, and writing this blog post.

First Raspberry Pi runs Pi-hole network add blocking, Unifi networking controller software, and a lab only Citadel mail server. Second Pi is dedicated to OctoPrint software controlling an Artillery Sidewinder X1 3d printer. This Pi and printer are not really core pieces of the home lab, but I do plan to experiment what the OctoPrint API and see if I can deliver 3DPaaS (3D Printing as a Service) from the vRA catalog.

I am severely internet challenged and wireless LTE is the only service currently available. Running a Ubiquiti EdgeRouter X connected to the wireless modem and a Ubiquiti Access point for wifi provides single private /24 network for the home lab and house.

Now for some Automation..

The networking equipment and the Pi-hole are the only lab infrastructure running 24×7. I only start up the lab when I am actively working on a project. Since I am an automation guy… Of course i had to automate the start/stop and it gave me a good excuse to dive into some PowerShell scripting. Running vCenter external to my ESXI host really makes this easy to do with PowerCLI. I only suspend all of my lab VM’s at shutdown since waiting 10+ minutes for vRA 8 to start up gets old quickly.

The procedure to start lab is run PowerUpLab.ps1 script and hit the power button on the NUC. (Hope to remove the hit power on NUC step but wake-on-lan is not working). Lab startup takes about 3 minutes from zero to login into vRA. The majority of time is waiting for Fusion to resume the vCenter appliance. I really need a new Mac. The procedure to shutdown the lab is to run PowerDownLab.ps1 script which will cleanly shutdown the lab in about a minute.

PowerUpLab.ps1 script:

  • Launch VMware Fusion
  • Resume VCSA VM
  • Take ESXI host out of maintenance mode
  • Resume vRA, VIDM, and gitlab VM’s

PowerDownLab.ps1 script:

  • Suspend all VM’s on the ESXI host
  • Put ESXI host in maintenance mode
  • Power off the ESXI host
  • Suspend VCSA VM in Fusion
  • Shut down Fusion

This is my current home lab and automation controlling it which is continuously evolving. Here are a few home lab resources I have found very helpful to get his running.

I really need a good Bob Ross style sign-off message for every blog post… I’ll keep working on that lab addition.

How about we peek under the covers of the vRA 8 Event Broker for a bit.

Those of you familiar with vRealize Automation (vRA) 7.x may have had the pleasure (or head ache) of working with the Event Broker Subscriptions (EBS). The good news is the EBS in vRA 8 is much simpler to add individual events, can run good old vRO workflows or new ABX actions, and has added a recovery runnable item.  It has lost the publish/draft capability allowing you to disable an event without deleting and the ability to subscribe to all events in a category with one configuration.  At this time the EBS is not available as a public API, but possible by reverse engineering the UI with your browser. Hopefully the API will be made officially public soon. I’m really tired of having to recreate all of these subscriptions every time I deploy a new vRA appliance.


What is really important to know is what events are available, when do they fire, and what property payloads are available to the workflows. To accomplish this I have subscribed all the events that run during provisioning to a single workflow – EBS Events.

Event Subscriptions

I setup a basic blueprint to deploy into a vCenter to trigger the events.  The blueprint is nothing fancy.  It contains 4 photon VMs, attached to a pre-existing network, and one disk attached.


Here is the EBS Event workflow.  As you can see from the view of the workflow runs, all we know is a lot of event have fired. Not very useful until you drill into each of the execution logs to see what is really going on. 

EBS Events

This is where things start to get exciting if you are into this kind of thing like I am. The EBS Events workflow pulls information from the system context metadata, sets the __tokenName, and passes it to a nested workflow, __token EBS Events. This makes it much easier to see what order the EBS subscriptions fire and how many times for various different resources. 

__Token EBS Events

Now this view actually gives you some very useful information just from looking at the the workflow runs. You can see all the events that fired, the order, per deployment or resource, and who requested the blueprint deployment. The user bit of who is very handy for a production system with many requests to weed through for trouble shooting.  Just watching the vRO runs during the deployment gives you a good idea on the progression of a deployment as well. Similarly the events for the destroy of the deployment. 

Destroy Events

Now let’s dive into some individual event logs to see what vRA passes to the workflows. The Disk Allocation Pre event runs early in the provisioning and you can start get the feel for the data that is available to vRO either as the inputProperties or in the _metadata context. The disk allocation only runs once corresponding to the single disk added in the blueprint, but 4 disks are allocated in vSphere cooresponding to the 4 VMs deployed.


The Network Configure runs once for the to the single network on the blueprint — I see a pattern forming. The properties during networking get a bit more interesting. The event contains all the information for the network configuration of the 4 VMs from the deployment such as custom properties, network profiles ids, and network subnet selection ids. I’ve been playing in this event quite a bit to understand this schema of multi-level arrays for selection and to see what can be modified, but that is for a future post. Hopefully the anticipation and sneak peak of whats to come that will keep you coming back for more.


One of the more straightforward payloads is for the Deployment Resource Request Pre. There is a bundle of information available to drive customized workflows and this event fires for every resource on the deployment.


Hopefully this gives a little bit of understanding to what  events are available and what data can be used for customization workflows during vRA deployment.  I will be doing future deep dives into many of these events topics to see just what can be modified.

Here is a vRO package with the EBS Events workflows so you can start to explore EBS events and payload properties in your environment.

vRO 8 Web Interface and Legacy Swing Usage

vRealize Orchestrator 8.0 comes with a new web only interface and other changes you can view in the official release notes. The new interface is the first release by VMware to modernize vRO and abandon the legacy Java Swing technology. The web interface has a some nice features such as limited native git integration, operations dashboards, and the all new HTML editor interface.

One of the most annoying “features” of the web interface is you can no longer use folders to manage workflows. Workflows are grouped by tags. Don’t get me wrong, I like tags. But coming from a world where workflow sorting/grouping are directory based (including all of the built-in vRO 8 Library), transitioning to one big flat folder for all new custom workflows just doesn’t fit how I currently work. Existing folder infrastructure is represented as tags and all newly created workflow get a default “webroot”tag.

Now I have never been a huge fan of the JAVA Swing client — but it is still better than the new web interface. Ok maybe not better and I am probably just “Get off my lawn!!!!” old and don’t like change. But lucky for me the vRO 7.6 Swing client is still mostly functional with vRO 8 server.

You need to deploy a 7.6 vRO appliance to get the client running. I installed the 7.6 vRO Workflow Designer locally and nuked the 7.6 appliance. In the login enter the URL of your vRO or vRA 8.0 appliance. The client will show a server mismatch version, but just ignore this and plow forward and the client will launch.

The other big gotcha is if you edit a workflow via the web interface it can no longer be edited, deleted, moved, or copied from the swing client. You can view it and look at the logs. Also any workflow created in with the web interface is dumped into one folder “web-root” which will become a big pile of what does this workflow do quickly without a good tagging/naming scheme.

Not quite all rainbows and unicorns unfortunately. Packages will not import and you must go back to web interface for import.

I’m guessing the Swing client will cease to function in future 8.x or 9 release. Hopefully by then the vRO product team extends the functionality of the web interface to fill the bring back the folder structure as part of the HTML interface. Hint for the Product Manager on the VMware Orchestrator team if they are reading this.

And I must have a standard disclaimer: Use the SWING client at your own risk and I’m pretty sure it is not endorsed or supported by VMware. I’m going to keep using it and will post any updates to enhancements to the HTML interface… Or when SWING is officially broken.