VMware Lab Constructor (VLC) is a scripted method to auto deploy a nested VMware VCF implementation of 1:many vSphere hosts. Its meant to be deployed on non-production (can also be unsupported) hardware. I went through the process to deploy it on a single Dell PowerEdge R630 and documented it below. If you have any questions, comment below and I’ll reach out as soon as possible.
As a word of caution, that is also called out in the installation guide, do not reach out to GSS regarding any part of this application. It is not supported by VMware.
That being said, this post won’t encompass a ‘how-to’ tutorial as that can be derived from the install guide that is available with the materials to deploy VLC. This will be a general guide with my experience intertwined. For the first run, I wanted the entire deployment to be as automated as possible. For two reasons, one, I wanted to see how smooth the deployment could be. Two, before tweaking any settings, I wanted to make sure that the deployment completely worked as described. That way when I do start changing settings, if something goes FUBAR I can’t blame the script.
- VLC – Single Host Required Hardware Specs version 4 rev 1
- Able to run vSphere 6.7
- Min. 128GB of RAM – my recommendation is 192GB
- Min. 800GB SDD – my recommendation is 2TB
- Min. 2 sockets w/ 6 cores each
- PowerEdge 630 specs:
- vSphere 6.7.0 Build 16075168
- RAM = 192GB
- Disk = 2x 1TB SSD; 3x 128GB SSD
- CPU = 2x Intel Xeon E5-2609 v3 6 cores @ 1.9GHz
Deployment of VLC is broken up into 3 Layers.
Consists of the physical Host (PowerEdge R630) that is running ESXi 6.7. This ideally can be a single host which is the case in my scenario or a cluster of hosts.
These would be are ESXi VMs that are created along with Cloud Builder and the Jump Host. Basically the vSphere hosts that are used for the VCF components of the initial WLD.
There are the VCF components deployed onto the ESXi hosts from Layer 2. In my deployment scenario, the only way to access these VMs will be from the Windows Jump Hosts. Since they’re on a separate IP scheme not available from my network. Other routing virtual appliances could be deployed within the Layer 2 environment to facilitate the IP connections used.
Installing the initial host was relatively simple. The same way you would deploy any other ESXi host which I’m assuming you’ve done multiple times otherwise you wouldn’t come to a VCF Lab blog post. If you haven’t, well this post is going to be REALLY confusing. 🙂
This Host will have a Windows VM that is used to access the rest of the nested layers. It has 2x NICs, one on my local LAN to RDP to and the other to reach Cloud Builder that will also reside in Layer 1 but deploy the VCF components to Layer 3.
- Jump Host Software
- Cloud Builder
v 22.214.171.124 Build 15345960
- v 126.96.36.199 Build 16008466
- VMware OVFTool 4.4
- PowerShell 5.1
- PowerCLI 12.0
- .NET Framework 4.8
- Cloud Builder
- Deployment Decisions
- Not using AVN deployment
- Using Full Automated deployment
- Did not use an External Gateway for the CB appliance. I have 2 NICs on the Jump Host.
- Created a separate user within my home lab vCenter to distinguish activities done by VLC.
- Requested VLC to do the Bringup
After configuring the Jump Host and placing the contents of VLC on the root of C:\, I added my licenses inside the ‘No AVN’ JSON file. Opened PowerShell and ran the VLC GUI script. I was immediately presented with the GUI window shown below. Selected the proper Cloud Builder OVA & ‘No AVN’ JSON. I entered my vCenter credentials for Layer 1and clicked ‘Connect’.
During the VLC initial connection, I was warned that my vSwitch security settings did not comply with VLC. Each Port Group’s security settings had to specifically call out being marked for ‘Override’ and set to ‘Accept’ inside its security settings. This is needed in order to have the vSwitch show up in the console below.
Once VLC connected to my vCenter, I selected the proper Cluster, Network (port group), and Datastore to deploy the VCF components onto. I hit Validate (which verified my options), then Construct to begin the deployment. The nested VCF environment was off to the races deploying the environment. Within the Install Guide, it mentions that this process can take 3-4 hours, my total runtime was 3:28:34 when all was said and done.
That was all there was to it. Outside of the couple issues I ran into, the deployment was seamless.
After VLC deployed the Cloud Builder it had made some configuration changes and rebooted it. After CB came back up, it had lost all its networking. The VLC scripts were stuck in a perpetual ‘Waiting for CloudBuilder Network to be available…’ messages while constantly trying to ping the appliance.
I logged into the Cloud Builder appliance and attempted to manually re-add the IP configuration VLC was expecting. Although I was presented with multiple errors regarding bringing eth0 down.
Since I was early in the deployment phase and no other VMs were deployed, I decided instead of wasting time troubleshooting that I would stop the deployment and try again. If I would get the same errors, I would dive into what’s actually happening. Which it did.
Within the Windows Jump Host, you have to add VLAN 10 to the NIC that is communicating with the VCF environment. While that wasn’t mentioned in the documentation, after discussing my issue in the support Slack page it was added to the next version. Once I made the change and re-ran the deployment script it continued past where it was stuck.
Oddly enough, I did get a warning that the Uplink group was being treated as a port group and it had its Security Settings invalid. It’s clearly not a port group and since I’m not referencing that Uplink Group with a VM, I didn’t pay this error any attention and continued with the deployment.
I later came to a point after the Layer 2 ESXi hosts were deployed, the script was at a point where its waiting for a response from CloudBuilder on port 22. The PowerShell screen keeps refreshing but not progressing any further. This lasted for roughly an hour before I scrapped the deployment. I was confident that no other deployments were being deployed. Keep in mind, I was able to ping the CloudBuilder just fine and resolve NSLookup to it.
After discussing the issue on the support Slack group and working with the author (shoutout to Ben Sier!) through a Zoom troubleshooting effort, it turns out that the version of Cloud Builder I was using (v 188.8.131.52 Build 15345960 which was the most recent through VMUG Advantage at the time) was an older version then what VLC was expecting. Which was pretty clear after connecting to the Cloud Builder UI and attempting to manually import the JSONs and being presented with an error that the un-modified JSON was not the right format. The correct Cloud Builder version was uploaded to VMUG Advantage the following week v 184.108.40.206 Build 16008466.
Next posts will dive deeper into making configuration changes to the environment and deploying additional VI WLDs. Ping me with any questions!