Updating vSphere 5.5 and Why I (still) choose 6.0
VMware vSphere 5.5 is now at end of support. September 19th is the ‘End of General Support’ date for the 5.5 vSphere series. It will still receive ‘Technical Guidance’ until 19.9.2020, but no patches. Sure, your systems will not magically stop running or something, but now is a good time to look at updates if you haven’t already done so. See the support matrix for VMware products here.
I’m a conservative updater when it comes to customer production environments. I’m also lucky enough to be maintaining dozens of systems, and my home lab plus a lab where I work, so I don’t have to adhere to the classic adage of “Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in.”
I also work in Finland, where environments, in general, are not extremely large. The mean size is probably 3 hosts, with 30-100 VMs, at least in the segment I manage.
This is a ramp up to my reasoning behind not going to vSphere 6.7 or even 6.5. “But Grelbar!”, you say. “6.0 is old as shit at this point! Why are you updating customers from one old system to another!”. Let me tell you. But I’ll start by listing some of the “Why you should update to 6.5 or 6.7” arguments.
Why go to 6.5?
The HTML 5 web client (Secure boot support) Proactive HA / Predictive DRS (vSAN, if this is something you are interested in) VM Encryption (VMware Cloud on AWS)* Higher Configuration Maximums. vVol stuff * Cold migration to AWS supported on 6.0 also.
Why go to 6.7?
Again, configuration maximums Performance enhancements Improvements in the H5 client Built in VCSA backup ESXi Single and Quick boot Support for new types of hardware
“These are some great enhancements Grelbar, whats your problem?”, I hear. Sit down. I’ll explain my reasoning.
All of these are valid. If your use case requires it, by all means, update to 6.5 or even 6.7. But consider that 6.7 is still very new. VMware has a history of releasing unfinished products, and GA versions are seldom production ready (I’ve been at this since 3.5, not forever, but a while). 6.5 can arguably be called mature, but I’ve run into such stupid issues using 6.5 that I can’t on good conscience tell people to upgrade to it, without careful consideration.
Updating has also become a quite painless process, if you compare for instance to the 5.0 -> 5.1 upgrade where they introduced SSO, and started bringing in the web client. I spent many a sleepless night doing those. Not so with 5.5 and 6.0.
Again, if your use case requires it, go to 6.5. It’s well supported, and can be argued is a mature product (Update 2 was released May 2018). I’ve simply seen too many issues and annoyances to do it. We’ve had issues with:
Yes, many of these were present in 6.5 U1. Yes, many if not all of these were fixed in subsequent updates. 6.5 U2 might be super great. But you get enough bad experiences…
On top of that, as I explained, the environments are not huge. We’re nowhere near the configuration maximums. I’m serious. We don’t have a need for 60 or 256 virtual iscsi targets! Or FT with 64 or 128GB VMs. Or CPUs with 576 or freaking 768 Logical CPUs per host. Or 12/16TB ESXi hosts. I’d like to see the use case for designing failure domains of that size. Granted, proactive HA/DRS can mitigate some of the negatives of running such failure domains (or I suppose, if you just have such large VMs that they’d run on a single host anyway; hard to split a VM..)
I’d say the largest environment I maintain is a sixth of those values? Maybe.
So my thinking is: If the product is still under support, and you still maintain the option to upgrade later (6.0 can be upgraded to 6.7 directly), and your environment is not monster sized with the latest NVDIMMs, extended to a VMware on AWS cluster, running NSX and vSAN, why rush?
As for the security features: They are a valid new thing in 6.5 and 6.7. If you’re reading this, and you’re using Encrypted VMs, or Secure Boot, please tell me about it, your use case(s), and how you’re getting along with those features. As for me, I do rely on the actual hardware being in a secure data center, and not transitioning any insecure networks. If there’s a breach, I certainly hope that encrypted VMs isn’t my last line of defense. Most storage systems are already running some form of encryption (if necessary), as well as backups and DR, so if you can access the running VMs in some way, you’re already quite far along. That’s not to say the concerns are invalid. There are always use-cases.
That being said, I’m really serious when I say: Get off 5.5, now at the latest. With the amount of security vulnerabilities lately, you do not want to be on an unsupported hypervisor which is the basis for, in many cases, your entire IT infrastructure or business!
On that note, the next post will be my journey from 5.5 to 6.0. There are many such posts out there, but this will be my story with my observations.
Sources:
https://www.altaro.com/vmware/new-in-vsphere-6-7/
http://vsphere-land.com/news/configuration-maximum-changes-in-vsphere-6-7.html
https://www.altaro.com/vmware/reset-esxi-root-password/
https://www.starwindsoftware.com/blog/why-upgrade-to-vmware-vsphere-6-5-or-why-not
All valid reasons and being burned by one or the other upgrade to 6.5/6.7 I totally get it. One feature that is really good imho on 6.7 that you didn’t touch is that VUM is included in 6.7 which makes updating easier. However not a feature strong enough to take you to 6.7 I suppose 😉