Chances are that unless you are an organisation new to vSphere or want an installation in the lab, you will be upgrading your existing vSphere infrastructure to the new vSphere 6.0 at some point in the future. As there are some design changes in this version, there are decision points that must be considered before embarking on an upgrade journey. Also, your upgrade path and topology will most likely depend on your existing version and deployment topology. Covering all of them will probably be difficult in this post but I will definitely try to cover some of the most important ones:

Update 1 (or not!):

This is the “classic” administrator’s dilemma on upgrades and there’s good reason for it. Battle-hardened administrators always want others to feel the pain first and learn from the horror stories, before attempting to upgrade their own systems. There is good reason for it as it typically means any obvious bugs in the release version are fixed. It is, of course, risky to jump into an upgrade right from the start so many administrators shy away from going into an upgrade early.

That said, as is the case for every new version, this is the most tested version released to date and has been in beta for quite a while now. This fact should provide some confidence that with appropriate planning, the upgrade should be relatively painless. Of course, if you have a complex environment then caution is necessary. However, even if you can’t see yourself upgrading now (and you weren’t part of the beta/RC), I would highly recommended getting it installed in the lab and start testing/planning the upgrade. It will likely turn out to be completely smooth and painless but if nothing else, you’ll become accustomed to the new mechanisms and features.

Ecosystem Releases:

You may have other VMware products installed that rely directly on vSphere for their operation and most will be “integrated” into vSphere. Any instability in those products due to incompatibility will have serious impact on your operations. VMware typically releases updated versions of those products at the same time as the vSphere ones so chances are that you’ll be ready to upgrade the ecosystem products at the same time as vSphere. That said, be sure to check VMware’s Product Interoperability Matrixes page to ensure compatibility. This is also important because it will take you a few days/weeks to fully upgrade and you’d definitely want those ecosystem products to keep working until upgraded to their newer counterparts.

Existing vSphere Version:

Depending on your existing version, your upgrade options might be different. I’ll give a quick summary on them:

vSphere 5.5/5.1

Upgrading from both these versions is almost identical in terms of process or topology. I would imagine the ideal situation in this case would be to have vSphere 5.5, simply because it will be the most tested version (as development start from maximum compatibility with the latest version) and also because the new SSO is very similar to SSO in 5.5. That said, the internal processes should deal with both and as long as you have the right information to feed, upgrade should not be an issue.

There will be this consideration about topology of Platform Services Controller (PSC) – more on that below. If you have a “Simple” vSphere install running i.e. all components on the same box, your in-place upgrade will result in vCenter with “Embedded” PSC. Similarly, if you previously scaled-out your deployment into a 2 VM (SSO + vCenter) or 4 VM (SSO + Inventory + Web Client + vCenter) setup, the upgrade will result in vCenter with “External” PSC. That said, you will have the opportunity to collapse your latter three VMs into one, ending up with 2 VMs. What you can’t do in this case is to collapse into a single vCenter with embedded PSC.

vSphere 5.0

As this is an older version, I would expect the least testing to have done with 5.0. However, it seems that upgrading from 5.0 is going to be surprisingly easy. This is due to the absence of one component which has been the cause of severe headaches to many administrators: SSO. Not having SSO in 5.0 has the benefit of reduced complexity while upgrading and people can go directly from having no SSO to SSO 2.0.

Another benefit of having no SSO means that the option is open to go to vCenter with either embedded or external PSC. However, this might be a moot point if you already have a mixed 5.x environment, in which case, you will have already decided on that anyway.

vSphere 4.x

As you would expect, VMware would like you to upgrade to 5.0 first. However after that, you can go directly to 6.0, as per the explanation for 5.0 in the previous point.

Platform Services Controller Topology (PSC):

There has been an architectural change in vSphere, resulting in the birth of the security controller called “Platform Services Controller (PSC)”. I’ve covered it “in another article” so won’t be too detailed here but this decision is about your strategy for the deployment of PSCs: Embedded, External or Hybrid. Functionally, they’re identical. The difference is whether it’s deployed on the same server as vCenter, separately or a mix. All of them are valid implementations but you would want yours to be the most efficient and resilient as possible, balanced with ease of management.

Another important consideration will be whether or not, you’re going to implement SSO in a HA configuration. There is a change from Active/Active to Active/Passive but the implementation methods should remain the same. Recipes will probably have minor differences due to the load-balancer configuration from different vendors but that’s normal and I am sure documentation on those will come out soon.

The decision has to be made before the upgrade starts as the question is asked during the install and whichever option is chosen, it cannot be changed afterwards. It will require a reinstall for it to be changed so be careful!

VMware Certificate Authority (VMCA):

A major cause of serious discomfort for a vSphere admin is the mention of certificates and/or the need to replace them. Again, I’ve covered it in a bit more detail “in another article” but in summary, VMware has created its own mechanism called “VMware Certificate Authority (VMCA)” to generate, distribute and manage the lifecycle of certificates related to vCenter and its ecosystem. The decision here is to choose from four different certificate authority models possible:

  • VMCA as root CA
  • VMCA as subordinate CA
  • External CA
  • Hybrid CA i.e. VMCA with External CA

All of them come with their pros and cons but chances are that one will be suitable for you. Think about it before embarking on an upgrade as this will be the right time to make that decision and work out what will need doing to implement that model. If the type of CA is decided and implemented right from the start, adding components subsequently will be far easier and shouldn’t require many certificate updates. Get this right and your vSphere admin will be forever grateful.

Conclusion:

There are many new features to take advantage of in the new version but most don’t require a decision at upgrade time.  I am sure there are many more things that one will have to consider before taking on a major version upgrade but I believe these are the main ones that one must think about and decide on before an upgrade to vSphere 6. Hopefully, this post will help in kick-starting that thought process.