Not long ago, I tore down my homelab (more of a test/dev environment for work, really) to focus on another project. It’s time to start the homelab fresh and play with some VSAN stuff.

I’ve installed ESXi 6.0 Update 2 and I’m ready to deploy my VCSA. I go through all installation dialogues and leave the system to churn. I return a little while later to a failed deployment.

The VCSA is powered-on. The storage appears to have been provisioned properly. I reboot to see if the error was a fluke, yet I continue to get a “firstboot error” which indicates that services have failed to start.

Having deployed several VCSAs for test/dev, I wasn’t too positive what I could have done wrong. I start the entire process over and the deployment fails again. This time, I’m paying attention as the VCSA boots. I can’t quite figure out where or why it’s failing.

Tip of the week: Click the Show All button to get more information about errors (including why your deployment failed). In this instance, it answered 100% of my questions without the need to even view the log file.

As I ran through this deployment for the third time, I realized that I was referencing a FQDN which didn’t even exist yet. I’ve deployed the VCSA so many times that I was entering the FQDN that I WANTED the machine to have. That’s a deployment-killer.

The simple solution here is to create a DNS record in advance or to just use the IP address. Creating a DNS record saw this final deployment as successful with a useable VCSA. This issue is actually called out in the Release Notes for vCenter Server 6.0 as well as in this KB.