VMware: Why Customize?

Today I deployed a greenfield (enterprise speak for “brand new without needing to think about past deployments”) vCenter Server 6.0 deployment. Those words don’t mean too much to most people, however for those VMware admins out there they are like birds singing on a summer morning, with blue skies and a slightly warm breeze. Today was a good day. [Insert Ice Cube Meme here.]

Deployment day was supposed to be yesterday. My team and I kicked off the deployment on Wednesday. As we went through the external platform services controller (PSC) deployment, we made two conscious decisions: our SSO domain will be something that isn’t vsphere.local and we will use the NTP sources that we have set up in the environment to provide NTP. These things don’t seem like that big of a deal. NTP has been around for ages. It’s an essential service of any enterprise environment.In many cases, the SSO domain is a vanity domain that only exists in the vCenter environment. VMware’s guidance is just to ensure that it is not your LDAP/Active Directory domain name.

The first thing that we ran into was an error with the PSC deployment failing its firstboot scripts, complaining that DNS was not set up correctly. Spoiler alert: DNS for the PSC was set up properly. Upon further investigation, a team member stumbled across a blog post that pointed out that you should only use one NTP source. “Great, good, the technology just isn’t there to deploy with two NTP sources,” I said to the team as we all had a good laugh. We redeploy the PSC and all is well, or so we thought.

We ran the vCenter Server Appliance (VCSA) deployment wizard and blew through it with ease. We set it to large, gave it a name, punched in only one NTP source (as we assumed the VCSA also couldn’t handle more than one NTP source) and started the deploy. Like the PSC, it failed to run it’s firstboot scripts. Again, the VCSA was complaining about DNS. Again, DNS was not the issue. We tried three slightly different deployments thinking that there may be a gotcha in the deployment process that isn’t documented or an issue with deploying VCSA to a vCenter that is running 5.5 U3. Stumped and ready to leave for the day, my Canadian counterpart opened a ticket with VMware (which is still unresolved despite us getting it working this morning) and we called it a day.

Later that night, as I was checking my email to ensure that I didn’t need to Make Infrastructure Great Again before heading to bed (as I’m on my on-call rotation). I see a message from my Canadian counterpart. He found this fantastic blog post on why you shouldn’t change your SSO domain from the default, ‘vsphere.local.’ Posted almost one year ago, the article states “VMware Engineering are aware and will resolve this in a future release of vSphere 6.0.” I question this, as it still isn’t fixed. We also decided that we would change the NTP option from specifying NTP servers to the “use ESXi host’s time,” option. Our ESXi hosts are all set to use the same NTP sources, so it really didn’t seem to make that big of a change in deployment methodology.

We took all of this very valuable information and deployed a successful greenfield vCenter 6.0 environment this morning! The PSC and VCSA deployments all did what they were supposed to do in a very short amount of time. It’s nearly complete, as I think I only need to configure a handful of things tomorrow as I await a couple other components that are still in the provisioning cycle. Good times all around!

The morale of the story is this: don’t over complicate your VMware deployments unless absolutely necessary!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s