This video shows how to use the VMware vSphere web client to configure shares, reservations, and limits in order to effectively distribute compute and memory resources among virtual machines using vSOM.
We would like to remind you that the End of General Support (EOGS) for vSphere 5.5 and vSAN 5.5 is September 19, 2018.
To maintain your full level of Support and Subscription Services, VMware recommends upgrading to vSphere 6.5 or 6.7. Note that by upgrading to vSphere 6.5 or 6.7 you not only get all the latest capabilities of vSphere but also the latest vSAN release and capabilities.
vCloud Suite 5 and vSphere with Operations Management (vSOM) customers running vSphere 5.5 are also recommended to upgrade to vSphere 6.5 or 6.7. For more information on the benefits of upgrading and how to upgrade, visit the VMware vSphere Upgrade Center.
For detailed technical guidance, visit vSphere Central and the vSphere 6.5 Topology and Upgrade Planning Tool. VMware has extended general support for vSphere 6.5 to a full five years from date of release, which will end on November 15, 2021. This same date applies to vSphere 6.7 end of general support as well.
If you require assistance upgrading to a newer version of vSphere, VMware’s vSphere Upgrade Service is available. This service delivers a comprehensive guide to upgrading your virtual infrastructure including recommendations for planning and testing the upgrade, the actual upgrade itself, validation guidance, and rollback procedures. For more information, contact your VMware account team, VMware Partner, or visit VMware Professional Services.
If you are unable to upgrade from vSphere 5.5 before EOGS and are active on Support and Subscription Services, you may purchase Extended Support in one-year increments for up to two years beyond the EOGS date. Visit VMware Extended Support for more information.
Technical Guidance for vSphere 5.5 is available until September 19, 2020 primarily through the self-help portal. During the Technical Guidance phase, VMware will not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes unless otherwise noted. For more information, visit VMware Lifecycle Support Phases.
Listed below are a number of additional actions which need to be taken, depending on your individual scenario:
vSphere with Operations Management (vSOM)
This bundle of vSphere and vRealize Operations allows you to upgrade the versions of individual components independent of each other. If you are using vSphere 5.5 as part of vSOM, you will need to upgrade your vSphere with Operations Management 5.5 license key, to be able to upgrade the vSphere component. You can reference the VMware Lifecycle Product Matrix to check for the EOGS date for the version of vRealize Operations you are using and the VMware Product Interoperability Matrices for the product version compatibility.
vCloud Suite 5
This bundle of vSphere and VMware’s management products will also require an upgrade of your license key to vCloud Suite 7 or later. Upgrading to vCloud Suite 2017 is encouraged to leverage the vRealize Suite 2017 multi-vendor hybrid cloud management platform. You can reference the VMware Lifecycle Product Matrix to check the EOGS date for each version of the products in the bundle and the VMware Product Interoperability Matrices for the product version compatibility.
This product is embedded in the vSphere 5.5 kernel and by upgrading vSphere you will also upgrade vSAN to a newer release. You will need to upgrade your vSAN 5.5 license key to a newer release license key. Please confirm hardware compatibility by referencing the vSAN Compatibility Guide and if necessary, make appropriate hardware upgrades as needed to maintain compatibility.
If you are using vSphere 5.5 or vCloud Suite 5, please contact your VMware account team or a VMware Partner with any questions and to begin an upgrade plan.
The VMware Team
About the Author
Himanshu Singh is Group Manager of Product Marketing for VMware’s Cloud Platform business. His extensive past experience in the technology industry includes driving cloud management solutions at VMware, growing the Azure public cloud business at Microsoft, as well as delivering and managing private clouds for large enterprise customers at IBM. Himanshu has been a frequent speaker at VMworld, Dell Technologies World, vForum, VMUG, Microsoft TechEd, and other industry conferences. He holds a B.Eng. (Hons.) degree from Nanyang Technological University, Singapore, and an MBA from Tuck School of Business at Dartmouth College. Follow him on twitter as @himanshuks.
This video shows how to use the VMware vSphere web client to configure resource pools within a DRS cluster and how to add virtual machines to the resource pools using vSOM.
VMware vCloud® Architecture Toolkit™ for Service Providers (vCAT-SP) is a set of reference documents that are designed to help VMware service provider partners within the VMware vCloud Air™ Network define, design, implement, and operate their VMware powered cloud platforms and services.
vCAT-SP is completely hardware vendor agnostic, although some vendors are mentioned in the implementation examples because the examples are based on implementations that VMware has performed with customers in the field.
The design guidelines and considerations highlighted in the vCAT-SP documentation are based on real world use cases and implementation experience gained from the field. The consumer (architect) will have the opportunity to choose design considerations that are important to the success of the cloud platform, and should consider interrelated design options holistically. For example, a requirement for higher performance might influence management and operations.
vCAT-SP has been developed so that each document can stand alone and provide guidance to the
architect on implementing a specific part of the solution. For example, the Architecting VMware NSX for Service Providers document can be used by a service provider who has already implemented a core cloud product based on VMware vSphere® or VMware vCloud Director®, understands how this component fits into a wider solution, and knows how to design based on required outcomes and use cases.
The vCAT-SP documentation is organized as follows:
• General documents – Document map and introduction on how to consume and leverage vCAT-SP.
• Service definition documents – Documents that enable the consumer to effectively define requirements for the cloud platform and determine what services to offer to their end users.
• Architecture documents – Documents that highlight the logical design and operational considerations within a specific architectural domain.
• Solution architecture example documents – Documents that provide solution architecture examples of a cloud platform.
• Solutions and services examples – Documents that provide architecture guidance and implementation blueprints for value-add services and solutions that can be added to the core cloud platform.
The following diagram highlights the key solution areas to consider across each cloud service model and
the VMware products that align to those areas.
Download a full Introduction to vCloud Architecture Toolkit for Service Providers Guide.
This video is fifth in a series of five covering the VMware Unified Access Gateway. This includes details on scaling, upgrading, authentication options, logs and some troubleshooting.
This video is fourth in a series of five covering the VMware Unified Access Gateway. It describes and demonstrates how to deploy using the PowerShell method.
This video is third in a series of five covering the VMware Unified Access Gateway. It describes and demonstrates how to deploy using the vSphere OVF method.
This video is second in a series of five covering the VMware Unified Access Gateway. It includes details on deployment requirements and options.
VMware Unified Access Gateway provides secure edge services to allow and access to defined resources that reside in the internal network. This allows authorized, external users to access internally located resources in a secure manner.
There are a few questions that come up quite often regarding vCenter Server upgrades and mixed-versions that we would like to address. In this blog post we will discuss and attempt to clarify the guidance in the vSphere Documentation for Upgrade or Migration Order and Mixed-Version Transitional Behavior for Multiple vCenter Server Instance Deployments. This doc breaks down what happens during the vCenter Server upgrade process and describes the impacts of having components – vCenter Server and Platform Services Controller (PSC), running at different versions during the upgrade window. For example, once you get some vCenter Server instances upgraded, say to 6.5 Update 1, you won’t be able to manage those upgraded instances from any 5.5 instances. While most of the functionality limitations manifest themselves when upgrading from 5.5 to 6.x, there could also be some quirks in environments running a mix of 6.0 and 6.5. There are a couple of additional questions that seem to arise from this doc so let’s see if we can address them.
The Upgrade Process
I’m not going to go through the entire process here, but it is important to understand the basics of how a vCenter Server upgrade works. Remember that there are two components to vCenter Server – the Platform Services Controller (PSC) which runs the vSphere (SSO) Domain and vCenter Server itself. For a vCenter Server upgrade, the vSphere Domain and all PSCs within it, must be upgraded first. Once that is complete, then the vCenter Servers can be upgraded. Obviously, if you have a standalone vCenter Server with an embedded PSC, this is a much simpler proposition. But, for those requiring external PSCs because of other requirements such as Enhanced Linked Mode, just remember the PSCs need to be upgraded first.
The other important point to make here is that upgrading by site is not supported. Looking at the above example, you can see there are two sites each with an external PSC and a vCenter Server. It is a common that a customer would like to upgrade an entire site, test, and then move onto the next site. Unfortunately, this is not supported and all PSCs within the vSphere Domain across all sites must be upgraded first.
Now, on to the questions mentioned earlier. The first question is, “Can I run vCenter Servers and Platform Services Controllers (PSCs) of different versions in my vSphere Domain?” The answer here is yes, but only during the time of an upgrade. VMware does not support running different versions of these components under normal operations within a vSphere Domain. The exact verbiage from the article is, “Mixed-version environments are not supported for production. Use these environments only during the period when an environment is in transition between vCenter Server versions.” So, do not plan on running different versions of vCenter Server and PSC in production on an ongoing basis.
The second question is then, “How long can I run in this mixed-version mode?” This question is a bit tougher to answer. There is no magic date or time bomb when things will just stop working. This is really more of a question of understanding the risks and knowing how problems may affect the environment should something go wrong while in this mixed-version state.
An example of one such risk would be if you were upgrading to vSphere 6.5 from 5.5. Let’s say you had your vSphere Domain (i.e. PSCs) and one vCenter Server already upgraded leaving you with 1 or more vCenter Server 5.5 instances. Imagine that something happens leaving a vCenter Server 5.5 completely wiped out. You could restore that vCenter Server 5.5 instance and be back in production as long as you have a good, current backup. If the backup you need to restore from was taken prior to the start of the vSphere Domain upgrade, you would not be able to use it to restore. The reason for this is that the vCenter Server instance that you would be restoring is expecting a 5.5 vSphere Domain and the communication between that restored vCenter Server instance and the 6.5 PSC would not work. An alternative to this would be to rollback the entire vSphere Domain and any other vCenter Servers that were upgraded.
Another risk would be if we are unable to restore that instance because the backups were bad (it does happen) or you couldn’t accept the outcome of losing the data since that backup was taken. The result here is that you would be forced to rebuild that vCenter Server instance and re-attach all the hosts. This may not be desirable because this new vCenter Server instance would have a new UUID and all of the hosts, VMs, and other objects would also have new moref IDs. This means that any backup tools or monitoring software would see these as all net new objects and you would lose continuity of backups or monitoring. You also would have to rebuild the vCenter Server instance as 6.5 which also may not be desirable because you may have an application or other constraint that requires a specific version of vCenter Server. If you rebuild the instance as 6.5 you may break that application.
Finally, let’s consider the possibility of having a PSC failure instead of losing a vCenter Server. What happens? Normally, you could easily repoint a vCenter Server instance to another external PSC within the same SSO Site. However, this would not be possible if the vCenter Server is not running the same version as the PSC you are attempting to repoint to. For example, if you had a vCenter Server 5.5 or 6.0 and they were pointing to a 6.5 PSC (because it has already been upgraded), if that PSC failed you would not be able to repoint that vCenter Server to another PSC. Remember that all PSCs must be upgraded first so all PSCs should be running 6.5 already. The only way to recover from this scenario is to restore or redeploy the failed PSC which may take longer than repointing.
So, give the above scenarios, what do we tell a customer who asks, “My upgrade plan spans multiple sites over multiple months. How should I plan my upgrade?” Here are our recommendations:
- 1. Minimize the upgrade window
2. Follow the upgrade documentation
3. Take full backups before, during, and after the upgrade
4. Check the interop matrices and test the upgrade first
The first recommendation is to minimize the upgrade window as much as possible. We understand that there’s only so much you can do here, but it is important to reduce the amount of time you’ll be running different versions of vCenter Server (and PSC) in the same vSphere Domain. The second recommendation is to, no matter how tempting to do otherwise, upgrade the entire vSphere Domain (SSO Instances and PSCs) first as is called out in the vSphere Documentation. It is not supported to upgrade everything in one site and then move onto the next. You must upgrade all SSO Instances and PSCs in the vSphere Domain, across ALL sites and locations, first. Third, make sure you have good backups every step of the way. While snapshots can be a path to a quick rollback, when dealing with SSO, PSCs, and vCenter Server they don’t always work. Taking a full backup ensures the ability to restore to a known clean state. Last, and certainly not least, do your interoperability testing and test the upgrade in a lab environment that represents your production environment as much as possible.
Emad has a great 3-part series on upgrades (Part 1, Part 2, Part 3) so be sure to check it out prior to testing and beginning your upgrade. Also know and understand the risks and impacts of problems during the upgrade process. Finally, know how the upgrade process is going to affect all of the yet-to-be-upgraded parts of your environment and have good rollback and mitigation plans if any issues come up.
About the Author
Adam Eckerle manages the vSphere Technical Marketing team in the Cloud Platform Business Unit at VMware. This team is responsible for vSphere launch, enablement, and ongoing content generation for the VMware field, Partners, and Customers. In addition, Adam’s team is also focused on preparing Customers and Partners for vSphere upgrades through workshops, VMUGs, and other events.