vSphere 5.5 End of Life: Now what?
It has been called out for about a year but the final date is really getting close: ESXi 5.5 is End of Life. Or as VMware puts it: The general end of support for vSphere 5.5. Version 5.5 may be the most installed version of vSphere to date. It was, back in 2013, the most stable, fast and reliable hypervisor around. But all good things must come to an end. There are new heroes in town; vSphere 6.5 and 6.7.
If this End of Life thing is news to you, we hope you do not have a very large environment to manage. But if you do, it’s not too late to start planning your migration.
What does End of General Support mean?
Whenever VMware releases a product, it also releases the lifecycle for that product. In general, a product has a 5 year lifecycle from release to end of general support. When vSphere 5.5 was released, 19 September 2013, its end of support date was also published. When you look at the vSphere lifecyle, you will see the life of a VMware product has a few stages (not counting development:
- General Availability (or GA)
- End of General Support
- End of Technical Guidance / End of Supported Life
The General Support phase begins on the date of general availability (GA) of a major release and lasts for a fixed duration. During the General Support phase, for customers who have purchased VMware support, VMware offers maintenance updates and upgrades, bug and security fixes, and technical assistance.
End of General Support is the date, generally 5 years after GA, from which VMware will no longer support the product actively. The product is now in a phase called “Technical Guidance”. Technical Guidance is available primarily through the self-help portal, no telephone support is provided. Customers can also open a support request online to receive support and workarounds for low-severity issues, on supported configurations only. During the Technical Guidance phase, VMware does not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes unless otherwise announced. The technical guidance phase for vSphere 5.5 lasts 1 year.
End of Supported Life means that it is no longer generally supported by VMware. You can no longer count on any support from VMware on that specific product.
For vSphere 5.5, these are the dates you should actually already know if you are still running 5.5:
- End of General Support: 19 Sept 2018
- End of Technical Guidance: 19 Sept 2019
What does it all mean for me?
Simply put, if you have a cluster on vSphere 5.5 and you run into trouble after the 19th of September and you call VMware, you will be shown to the Knowledgebase door. The support desk will not accept your call. When you reach that point, you have 3 choices:
- Do nothing (probably not the best but always an option)
- Upgrade to vSphere 6.x (we’ll get back to that part later)
- Buy yourself another year to think about things (also known as Extended Support)
Starting with the third option, you can buy yourself another year of time. If you are concerned that you will need to run vSphere 5.5 past the EoGS date, you can buy an Extended Support option from VMware. It may be your only option to extend your time and still receive support, but it probably will not come cheap. If you want to know the cost, contact your VMware representative.
The first option is always a choice you have. vSphere 5.5 will not stop working past any date. If you’re fine with the fact that it will no longer be supported and if you never purchased a support contract to begin with, why bother with an upgrade? Well, there are a lot of benefits in newer versions, obviously, but if you do not have the money or don’t want to spend the time, this may be a valid choice.
The way one would normally go, is option two: upgrade to a supported version of vSphere. How would you go about that? Let’s dive into upgrading in the next part.
Upgrading choices from vSphere 5.5
So, the sane way would be to upgrade. What do you need to know? Well there are a few significant changes compared to the current running versions of vSphere. But first things out of the way first. As you just ran into an End of Support issue, you would not want to run into that again any time soon. With that in mind, here’s the list of currently supported ESX/vSphere versions that have a longer future:
- vSphere 6.0:
- End of General Support: 12 March 2020
- End of Technical Guidance: 12 March 2022
- vSphere 6.5:
- End of General Support: 15 November 2021
- End of Technical Guidance: 15 November 2023
- vSphere 6.7:
- End of General Support: 15 November 2021
- End of Technical Guidance: 15 November 2023
No, we’re not making a mistake, vSphere 6.5 and 6.7 have the same end dates. Last year VMware decided to extend the support for vSphere 6.5 with another year, as it was to be expected that a lot of companies who run vSphere 5.5, would upgrade to vSphere 6.5. Those companies would have the benefit of an extra year of support. And maybe also because there is no direct way of upgrading from 5.5 to 6.7, but we’ll get to that in a minute.
So, from a time perspective, there is no difference in upgrading to either 6.5 or 6.7. But that is not all that is new. When you ran vSphere 5.5, you also had a vCenter running on Windows. And if you haven’t upgraded your vCenter in the mean time, you still are. The world of vSphere has changed a bit since then. vCenter Server Appliance is the way to go and it’s a fine way. It will relieve you of having to maintain Windows and SQL just for vSphere. Also, it introduces the Web client. No more running Windows with the VMware client to manage your virtual environment. Just open a browser and you’re in business. With vSphere 6.7, the HTML5 version is almost completely on par with the flash based client.
But there is more:
- HA for vCenter
- File based backup for vCenter
- VM encryption
- Secure boot for ESXi and VMs
- Better logging in vCenter
- Integrated Update Manager
- VSAN
And vSphere 6.7 brings you even more innovation. One warning message here. You cannot upgrade directly from vSphere 5.5 to vSphere 6.7. You need to do this in a two stage process. Also, vCenter 6.7 cannot manage ESXi 5.5 hosts. So upgrading to vSphere 6.5 would be your first stop. And that is where we will focus on next.
Upgrading from vSphere 5.5
If you are not routined in upgrading, and a lot of you out there probably aren’t, it is imperative that you first check before you start. The last thing you want is to run into a situation where you loose control over your environment or worse. So here is a short list to check if you are good to go:
- Check if your hardware is compatible. This might actually already be a showstopper. If your cluster is as old as vSphere 5.5 is, then chances are that they are not compatible with vSphere 6.5 or newer. But it may. You can check if your system is on the list at VMware’s Compatibility Guide. This will tell you if you are on the safe side. Having said that, it is very well possible that ESXi will run on your host, supported or not. But if your hardware is not on the Hardware Compatibility List (HCL), VMware support may still not help you if you have issues that are hardware related.
- Check neighbouring systems. If you have an integrated backup system, monitoring software or other appliances or applications that tie into ESX or vCenter, you may need to update those as well. A lot has changed since v5.5 and other software may stop working once you’ve upgraded. Check in your current vCenter for plugins and extensions to make sure you do not forget anything. Also, check your storage for compatibility.
- Make sure you have enough resources. If check 1 and 2 are both green, make sure you have enough storage space and hosts available to do your upgrade. Migrating will mean that during the upgrade of vCenter, you will temporarily run 2 vCenters side by side. When upgrading your ESXi hosts, you will need to put them in maintenance mode. If they cannot move their workload to other hosts, they will not be able to go into maintenance mode and you cannot upgrade them.
- Pick the correct ESXi installation media. This sounds like a no-brainer but it is not. Depending on your hardware vendor, you might want to use a ‘flavoured’ ESXi installation disk from that vendor like HPE, Dell or Lenovo instead of the ‘vanilla’ VMware image. There are several vendors who release their flavoured version of vSphere. Those installation disks contain the right drivers for hardware, management chips and more. You will find the official “flavoured” ISO’s on the My VMware download page. If you do not have a ‘standardized’ system, you may need to prep your own installationdisk by injecting drivers you need into the installation disk. If you need to do so, you can use the ESXi-Customizer from v-front.de. Also, make sure you have downloaded vCenter Server appliance as this would be the first medium you need.
vCenter Upgrade
Once all your checks are green and you are sure you are good to go, you can now start with your actual upgrade. And the first part of your environment is the vCenter Server. Upgrading vCenter used to be a big pain. But with the vCenter Server Appliance (VCSA), a lot has changed. When you start the ISO up on your system, it will offer you the vCenter Migration Assistant. The Migration Assistant will help you to move all data, or a selected portion of it, to your shiny new vCenter Server Appliance.
When you had separated roles in your 5.5 environment, like Single SignOn (SSO), Update Manager, and more, you cannot change that configuration during migration. With a separate SSO server, you will need to start your migration there with the migration assistant and it will create a configuration for you with an external Platform Services Controller (PSC) and a separate vCenter Server. If you just have Update Manager (VUM) running separately, there are two things you can do. Either you start migrating at VUM, or you disable and remove VUM completely and reconfigure it after the migration is done. The last option will save you time and effort, unless you have a really extended VUM configuration.
The Migration Assistant will make sure that the digital identity of vCenter is migrated. It will produce a VCSA with the same uid, IP address and database as the old vCenter. During the migration you will have the opportunity to either migrate only the configuration information, migrate the configuration and historical data like events and tasks or migrate the configuration, historical data and all performance related data and statistics. During the migration, the assistant will show you how much data that really is and will give you an estimate on how much time the migration will take. From there it’s just following the assistant until the finish.
If, for some reason, your migration should fail and your VCSA is just a pile of rubble, your roll back scenario is quite simple, because the migration does not alter your v5.5 vCenter in any way. It just shuts it down after pulling all the data. To roll back, you just shutdown and remove your VCSA and power up your v5.5 vCenter and you are back in business. The only thing that you may need to do is bind the v5.5 vCenter to your MS Active Directory if you had that before.
Host Upgrade
If all went well, the previous steps resulted in the login screen of your new VCSA. You can now move on to migrating your hosts. Obviously they are compatible with vSphere 6.5 because you have checked this in the preparation for the migration. So we’re moving on to upgrading. You can do this in one of two ways. Either you upgrade them via VUM, or you boot them with the new ISO you previously downloaded or created and migrate to ESXi v6.5 on the console. I’m sure you are all familiar with the console upgrade. It simply means booting the ISO either by burning it to a disk and booting from it or using some form of IPMI/ILO/iDRAC or other remote console where you can mount and boot from an ISO image.
Using VUM however is quite the elegant way of upgrading and as VUM is already integrated in your VCSA which you now have, you can easily leverage that functionality. Then you log into VCSA and you pick Update Manager from the pull down menu, you can import the ISO you previously downloaded or prepared or you can prepare it here. Once ready, you can create an upgrade policy and attach that policy to the hosts you wish to upgrade. You can now choose to remediate a host and it will be upgraded to ESXi 6.5. If you want to see how to do this step by step, take a look at this website by HyperVMwareCloud. Here the whole process of importing the ISO and creating the policies is explained in detail with clear screenshots.
Wrapping up
If all went well, you now have your brand new VCSA managing you upgraded hosts and all your VM’s are running like they did before. But wait, there is more to do. That is, if you wish to upgrade to 6.7, you will need to make sure some maintenace is competed.
First there is the hardware version of the VMs and the version of VMtools. If you have not already upgraded the hardware version of the VM’s earlier this year with the Spectre and Meltdown publication, this is your chance to do so. To be safe for those Speculative Execution vulnerabilities, you need to make sure the hardware level of your VM’s is at least version 11. But when you are upgrading anyway, you might as well go for the highest available version, which should be 13. Upgrading virtual hardware should not affect the operating system running in it. It just gives the VM new abilities. After that you also need to update the VMtools in your VM’s. Once updated to the latest versions, you should be good to go from that perspective.
If you use distributed virtual switches (VDS), you should make sure they are upgraded to a minimum version 6.0 or newer. If you want to upgrade to vSphere 6.7, you can not have a VDS with version 5.5 in your environment. And last but not least, if you run vSphere with VMFS volumes, you should make sure you upgrade them to v5 or newer. Upgrading should be easy. When you navigate to the Storage tab and select the VMFS3 volume, you should see the upgrade option in the VCSA screen.
vSphere 6.7
If you chose to push for the latest release, you can now repeat the steps above to upgrade to v6.7. The migration process will be a bit shorter but all the preparation steps and migration steps remain the same. There are reasons to go for v6.7 and not stay at v6.5. Take a look at the What’s New in vSphere 6.7 whitepaper by VMware or go and visit the vSphere 6.7 roadshow.
In Conclusion
As you can see, upgrading to a new version of vSphere does not have to be a pain. It does require proper preparation but every migration does. VMware hands you a proper set of tools to make you succesful in migrating to a supported version. Now let’s see you be succesful!
Tags In
Related Posts
5 Comments
Leave a Reply Cancel reply
You must be logged in to post a comment.
Hi Alex, great article, however, eogs does not mean VMware support will not accept call. VMware still accept call, but only for S2~S4
That is true. Although official policy states different, VMware global support will probably always try to help you no matter what, but when it either takes too much time or requires engagement of other departments, they will have to say “we can’t assist you any further”.
vSphere v6.5 = no c# Client and not fully functional html client = really not good.
This is a first reason why most of customers (and admins) not upgrade to 6.x.
Second reason, in especially big environments with lot of plugins and additional software connected to Vmware it’s really complex (and expensive) to make such upgrade, and can’t guarantee final stable end in acceptable period of time, and this is a second big problem.
Third reason is as you mentioned v5.5 is very stable version while v6.5 is not so stable (checked in really lot of colleagues envs in 3 companies and 7 big customers that force admins to upgrade to v6.5 – really much less problems we have in v5.5 than guys with v6.5).
p.s. – we are discussing and testing upgrade scenarios with VMware from 6-8 months… and still it’s not fully working and most probably we will have to create env from (almost) scratch (which will be faster, easier and with bigger chances for working).
Dave, I do not agree with your points.
First point: You also have the flex client that *is* 100% functional. It does require Flash components but it will work for you. Also, you can always install the HTML5 version from the Flings page that will give you more functionality than the embedded one.
Second point: I already pointed this out in the article. It should not be an issue if you have done proper lifecycle management over the rest of your environment. If you have not, then you have your work cut out for you but on the other hand there will be multiple reasons to upgrade, not just from a VMware perspective.
Third point: I would say that is in the eye of the beholder. I personally think it’s a rubbish argument. I have not seen PSOD’s in my 6.5 Environment, other than ones caused by hardware failure. From my point of view, 6.5 has no more or less problems than 5.5 has had over the course of the last 5 years. I see hospitals running critical apps on v6.5 without any downtime or hickups.
You probably know this as well as I do: Every major change brings challenges to your environment. Whether it is upgrading from Windows 2003/2008 to 2012 or 2016, upgrading your Linux VM’s or upgrading your hypervisor. And if you hate change, there’s always the choice to do nothing. It’s not a good one because it will be a matter of time before you will find yourself in dire straits, but it’s always a choice. From a vSphere prespective, if you have done lifecycle management, you would not be in this situation. But most environments where I see 5.5 still running are disinclined to changes. When you then suddenly have to move, the leaps are much bigger (and so is the impact) than if you would have stayed updated througout the years.
Hi Alex, great article and thanks for sharing. We are planning to upgrade our from vsphere 5.5 u3 to v6.5 u1, i have read some forums that during the migration you will need to disable the DRS in the cluster but disabling the cluster will remove the Resource Pools. can you please share your technical knowledge if this is the case. my vcenter lives in the cluster.