VCSA: Deployed with no external DNS?

External DNS is a documented requirement for vCenter in a supported deployment model [read the documentation.] However, are there are times when you want to set up vCenter without any DNS?
When on earth would you want that?

  • Small lab or POC
  • Tiny Environments for an initial standup prior to providing DNS
  • DR scenarios when services (including DNS) are down you may need to manage multiple hosts and simply get recovery VM’s running (this can be avoided through good design, but it can happen.)
  • Home Labs, of course

When do you NOT want vCenter without DNS?

  • Anytime you need to count on VCSA long-term. Just don’t.
  • Any deployment of vCSA with an external PSC or any of the extended features like Linked Mode/Enhanced Linked Mode, Stretched Clusters, etc.
  • Also, don’t expect to get LDAP integration working.

So you still want to deploy vCSA and don’t want to depend on DNS forward/reverse lookups? Read on… it’s pretty easy.

The Key Thing…

The bottom line here is that there are a few configuration points you have to diverge from. It’s simplest to explain this from the scripted installer configuration because these variables are clearly laid out. (William Lam writes up the whole process over at Virtually Ghetto. )

It’s also a good bit easier to deploy with the scripted installer if your skills permit it. Again, see William Lam’s posts for a primer.

The JSON looks like this and we’re after the network settings.

If you read carefully you will notice a few things that are unusual.

  • The DNS server (only one) is the same as the system IP
  • The System Name is also using this same address

Both these are deliberate and required for a no-external-DNS VCSA.

What’s happening here? This is declaring that VCSA is going to be it’s own DNS server, and that seems to work just fine.

UI Installer

Stage 1 of the installer is straightforward. In my screenshots I’m deploying an embedded PSC model and the only critical piece that’s unusual here is to keep the System Name, IP address, and DNS Servers all at the same address you’re deploying vCSA to.






Once you’ve deployed stage 1, Stage 2 is straightforward, but Stage 2 WILL NOT proceed without a functioning network. So if you blew it in Stage 1, you’ll know it right at the start of Stage 2.

In this example I’ve deployed VCSA 6.7, the lastest-greatest at the time of writing. However, I’ve done this with success all the way back to VCSA 6.0.


Don’t deploy a no-dns VCSA if you expect it to scale or you want to grow the environment.

Don’t deploy a no-dns VCSA if you expect it to be supported. VMware will point you to the documentation and likely leave you alone with your problems.

But do you want to stand up a VCSA for a nested ESXi or other lab use with minimal effort? Give this a spin and reach out on twitter if you have trouble–I’d be interested to hear.


Upgrading vSphere 5.5: what version should I settle with?

In April, VMware blogs posted an article for those who need to upgrade from 5.5 before end of support (documented: September 19, 2018). The article pushed users to consider:

Should I upgrade to 6.5 or 6.7?

The VMware blog article says this: consider the features and value of 6.7–do you need the new gadgets or should you stick with a more time-tested release in 6.5? (those are my words.)

What else to consider?

There’s a good bit more to consider than just features and value. Those are great starting points and will help initiate the project, but there are constraints that administrators had better consider before the upgrade. The cost of up-fitting for these constraints could push the upgrade to a lower version than the latest, shiniest 6.7.


Do we even need to say this? If you haven’t kept up with the major changes, it could be a surprise that there are several changes in 6.7 that may not even be compatible in your infrastructure:

  • The Release notes give us a list of CPU’s you cannot use with 6.7 found under the ominous heading “Upgrades and Installations Disallowed for Unsupported CPUs
    (see another article on CPU compatibility)
  • There are similar CPU lists for vSphere 6.5, so awareness of hardware compatibility is key. You could need to only upgrade to 6.0 while you figure out your hardware plan.
  • There are many storage changes in vSphere 6.7. I’m seeing that while hardware may be compatible it can require updated firmware. Storage controllers are particularly likely to need an updated firmware. vSAN makes storage controller firmware updates easy for a lot of storage controllers, but if you’re not using vSAN it may be more of an effort.

Other VMware Products

  • VMware Horizon 7.4 is incompatible with vSphere 6.7. Using Horizon 7.4 or earlier? Stick with vSphere 6.5. The upgrade to Horizon 7.5 warrants it’s own writeup.
  • VMware NSX for vSphere 6.4 is also incompatible with vSphere 6.7. The HCL makes this clear. The Product Interpretability Matrices help here.


How about your Backup/DR/Replication solution? Many don’t support vSphere 6.7 yet and who wants to be the one who upgraded, but now has no current backups?

For backups, the variety of solutions is worth considering. This is where a solution that runs on the Hypervisor typically has to be updated when the hypervisor gets a major release. On the other hand, a solution that runs within the virtual environment guest operating system using an agent or other mechanism can typically receive updates outside the hypervisor update cycle.

Other constraints:

There’s more to consider than just what’s here, and that’s close to the point: a thorough review of hardware, firmware, other VMware solutions and third-party solutions needs to go in prior to upgrading 5.5, and upgrading to 6.0x may be a path forward depending on your environment.

Plan and Strategize

Another strategy worth considering: it is normal to have ESXi and vCenter versions out of sync as part of a larger effort. Most of the constraints above are related to ESXi, not vCenter. Horizon and NSX can be exceptions, of course, depending on the versions.

If you’re moving from vCenter on Windows 5.5x and are making the jump to vCSA, then there’s paths forward, and you can usually bump vCenter up to your latest version before touching ESXi. In any case, vCenter always gets the upgrade before ESXi.

Here’s a simple example. You could have ESXi 5.5 / vCenter 5.5 and hardware that is–without some overhaul–incompatible with vSphere 6.5. You could plan your upgrade to run roughly this way:

  1. Upgrade vCenter to 6.5U2
  2. Upgrade ESXi to 6.0U3a.
  3. Plan your hardware upgrades to achieve compatibility to ESXi 6.5.

This would get you off 5.5 and could have you moving forward quickly.

Again, spend some quality time with the VMware Product Interoperability Matrices to validate where you want to go and your best path may make itself clear.

The growing list of unsupported CPU’s

VMware has disgruntled some customers by releasing ESXi versions that no longer support some previously-supported CPU’s. I think this is an inevitable change: if the Hypervisor is going to change in some ways then it’s going to have to stop supporting old CPU’s with limited features at some point. Some may argue this is too soon, but you can’t please everyone.

One thing to be clear about is that this is a change for ESXi as a part of vSphere. That is the hypervisor. Not vCenter. vCenter is generally the first thing you upgrade in an environment and you can run an updated vCenter server with backwards compatibility for older versions of ESXi. There are all sorts of reasons you might not upgrade ESXi but you might go ahead and upgrade vCenter, especially with the benefits of the UI upgrades we’ve been seeing of late.

VMware’s language from the release notes is striking and makes me smile a little. Here’s the ominous heading:
Upgrades and Installations Disallowed for Unsupported CPUs 

Under that heading there is a list of unsupported CPU’s right in the release notes, parallel to what you find in the HCL. (VMware is clearly trying to be upfront.) Here are the lists for vSphere 6.5 and 6.7:

vSphere 6.7 (release notes) – CPU’s newly unsupported since 6.5

  • AMD Opteron 13xx Series
  • AMD Opteron 23xx Series
  • AMD Opteron 24xx Series
  • AMD Opteron 41xx Series
  • AMD Opteron 61xx Series
  • AMD Opteron 83xx Series
  • AMD Opteron 84xx Series
  • Intel Core i7-620LE Processor
  • Intel i3/i5 Clarkdale Series
  • Intel Xeon 31xx Series
  • Intel Xeon 33xx Series
  • Intel Xeon 34xx Clarkdale Series
  • Intel Xeon 34xx Lynnfield Series
  • Intel Xeon 35xx Series
  • Intel Xeon 36xx Series
  • Intel Xeon 52xx Series
  • Intel Xeon 54xx Series
  • Intel Xeon 55xx Series
  • Intel Xeon 56xx Series
  • Intel Xeon 65xx Series
  • Intel Xeon 74xx Series
  • Intel Xeon 75xx Series

vSphere 6.5 (release notes) – CPU’s newly unsupported since 6.0

  • Intel Xeon 51xx series
  • Intel Xeon 30xx series
  • Intel core 2 duo 6xxx series
  • Intel Xeon 32xx series
  • Intel core 2 quad 6xxx series
  • Intel Xeon 53xx series
  • Intel Xeon 72xx/73xx series

vSphere 6.0 does not define a list, but points to the age-old hardware compatibility list (HCL). Look up your CPU’s and validate.

The HCL should always be consulted, in every case. If you’re using VMware then you value a resilient infrastructure. Take the time to check your hardware and make sure it’s compatible before you upgrade your hypervisor.