This will be the final blog centering around planning and executing a VMware Cloud Foundation Management Domain deployment with repurposed nodes. For us, this exercise was learning how to prep and utilize the lab we have been graciously loaned by Lenovo. This also allowed us to learn Lenovo XClarity Administrator, which was invaluable in recovering nodes that we did not have root credentials to. You can use the same lessons learned and real-world solutions to deploy your own VCF lab/test environment or production domains. Future blogs will focus on using VCF to address specialized workload domains for applications or solutions such as VMware Horizon. The last several blogs documented all the challenges and solutions needed to properly scrub nodes and setup the required network backing. Now…its finally Friday!! Let's get this sucker deployed.

Cloud Builder

Once you have deployed the Cloud Builder OVA (which was outlined in a previous blog), you will need to complete the deployment parameter worksheet. First, login to your Cloud Builder instance.

Accept the EULA.

Choose your deployment type (basically non-VxRail or VxRail).

The Pre-Req Worksheet

Review and acknowledge the prerequisite worksheet. Read through this carefully!! Many things that may trip you up in the validation can avoided by double-checking here.

Completing the Deployment Workbook

Download and complete the deployment workbook. The next step is to upload, but we need to go through some important entries on the tabs.

The note in yellow states this is a complex document that will require input from several teams. This is no joke. If you are doing your maiden voyage into VCF as a lab/POC with other members of your data center team, you will all benefit by figuring this out for yourselves the first time around. Then, when doing it for real, you know exactly who you need to talk to and specifically what information you need.

The first tab is another checklist. It is more straight-forward than the checklist shown above. We started with this, then followed up with the other checklist.

The most important things on the Management Workloads tab are the licenses. You cannot deploy without licenses. We would suggest just using the default host names for components when deploying for a lab/POC. Once you get comfortable, you can do subsequent deployments (whether test or production) with the "correct" ones. The resource calculator automatically calculates the resources required. You can edit fields here to reflect the exact numbers of your nodes.

The Users and Groups tab is pretty straight-forward. Just note these are the account values you will need later.

The Hosts and Networks tab is where the real work starts.

Starting with the Management and Domain networks section, the VLAN column must be completed with the backing VLANs you created. Obviously, the same goes for subnet and gateway entries. These networks are checked during the validation and used in the actual deployment. Keep the MTU column as is - these are expected values and standard for most any deployment today.

Be careful on the Host Section. These are the current IPs of your prepped hosts and the IP ranges for vMotion and vSAN vmk ports. Typos here will cause the validation to fail.

You will notice 2 things here that have alternate answers. The default network configuration is for one VDS. If you populate the name field for a second VDS, you must choose a different profile.

Profile-1 is the default for one VDS. Profile-2 splits the traffic up…

while Profile-3 isolates vSAN traffic.

Changing the ESXi host security thumbprints to "yes" allows you to enter those values.

The Deployment Parameters tab is by far the most detailed. Check each entry carefully. Once again, first time out, just use the default hostnames. DNS needs to be configured at minimum with the names and IPs of the hosts, Cloud Builder, vCenter, NSX, and SDDC Manager.

You will note that the Application Virtual Networks (AVN) setting is set to yes by default. For production deployments, this is the recommended practice and a good idea (see our previous post: When Plan A Doesn't Work). However, if you don't have the capability to support all the backing networks required (or maybe need some help and haven't gotten it yet), you can set this to "No" and all but the Management, vMotion, vSAN and Host Overlay (which is not required) will gray out. This again makes your maiden voyage a little easier and you can work your way up to full network scale on the next go-around.

Upload into Cloud Builder

Once you have the spreadsheet completed, upload.

You are now ready to run the deployment validation. If (let's be real…when) you get failures, investigate, fix, retry.

There is an option to acknowledge failures and deploy, but beware…if this results in complete failure, your recovery option is to start over.

The best case for deployment failure recovery:

1. Note what you thought didn't matter (but now realize it did). Fix that this time.
2. Power off Cloud Builder and Delete from Disk
3. Scrub the nodes
4. Install a fresh ESXi image (don't forget the few required base settings - SSH/NTP)
5. Deploy a new Cloud Builder
6. Run the deployment validation again and deploy if ready

The key here is to fix all the issues before actually deploying. That saves you from steps 1-6 above. But we all are impatient and have ADD (it's an IT requirement) - that's why I noted it here. You will need it.

Deployed!

Eventually - you will see a successful deployment and be able to login to SDDC Manager.

All the marketing says "in 4 hours" (more or less). In our lab on loan from Lenovo, it routinely takes us about 30 minutes to redeploy hosts, deploy Cloud Builder and get all the default settings sorted. Another 10 minutes for the deployment validation and from there about 65 minutes to deploy the management domain. Your mileage may vary, but for us, with Lenovo XClarity Administrator's help, we are way less than the marketed value. We'll take it AND the early Friday.