Intro
You have done the interviews, gained a lot of insight through tools, documentation and whatsoever, and with that you’ve created your first draft of the so-called IST. During the assessment phase you’ve also learned how the environment is being used, what the applications landscape looks like, what kind of hardware and underlying infrastructure is being used and which software or application has been integrated or is depending on the vSphere environment. Time to list up all the dependencies that are present, and to create a compatibility list which will give you a clear overview of the situation and the Gap between the IST and Soll. The list will help you to define a Roadmap that will take into account: all the compatibility possibilities between all the different vSphere versions, vs the different Firmware / Software versions of the dependencies.
BlogPost Serie Overview:
✓ Phase 1: Kick-off
✓ Phase 2: Assessment
✓ Phase 3: Defining the IST (Current State)
⇒ Phase 4: Dependencies & Compatibility
⚬ Phase 5.1: Technical vSphere Challenges
⚬ Phase 5.2: Common vSphere Challenges
⚬ Phase 5.3: Solving vSphere Compatibility Challenges with VVD
⚬ Phase 6: Defining the Soll & Roadmap (Future State)
What should be considered as a dependency?
To be clear, a dependency in our context means that any form of Application, Software or Hardware (component), can be affected, when changing something in the vSphere Environment. This could be a change in version of the vCenter, ESXi host, or even the change from VMFS5 to VMFS6.
As long as vms and applications are not integrated or are depending on a certain vSphere version and thus effected by an upgrade in any kind of way, those vms, apps, software or hardware, are not considered to be part of the “Dependency & Compatibility List”.
That doesn’t mean that it isn’t important to list up the business-critical applications. That will come in handy later for your migration path. Most applications are depending on a working vSphere environment, but that is not what we mean with “dependency” in this context.
How to approach
First things first, since we do not yet know how we are going to proceed with the upgrade, we first going to list up the dependencies and check their compatibility between the different vSphere versions. In the excel template that I’ve shared in the previous posts, I’ve listed the following versions in the “Compatibility Roadmap Example” tab.
- Version 5.1;
- Version 5.5;
- Version 6.0;
- Version 6.5;
- Version 6.7;
If you didn’t have it already, I suggest you download it here:
vSAM.Pro Template - GAP Analysis for vSphere Upgrades - Technical v1.1
Considering you’re coming from version 5.1 (but let’s not hope so), this list will give you the best insight on how to proceed with your upgrade path and still stay compatible with all the dependencies. This doesn’t mean that you should upgrade 4 times, but it is good to know on which vSphere version, certain Software / Firmware versions your dependencies are compatible with. If your vSphere environment is already running on version 6.0 you can of course skip version 5.1 and 5.5 and only check the compatibility for 6.0, 6.5 and 6.7, or the next latest release. I hope that with that being said, and my template as an example, it becomes more clear how your upgrade or migration path, is going to look like. In the “Technical Challenges & Decisions” post, I will cover all the different and possible jumps and upgrade scenario’s. For now, we will focus on how we will gain the information and how to validate the compatibility.
Checking & Validating Compatibility
This is probably one of the most difficult and time-consuming parts of a vSphere Upgrade. Checking and validating the compatibility of all the different Hardware & Software Vendors. The first step is to check if the dependency is supported on the different vSphere versions. This can sometimes be found quickly. However, finding out which version of the Vendor Firmware / Software is supported on the different vSphere versions, is more difficult. The best and secure way to do this, is by contacting the vendor itself. Still, VMware has created a great tool called the “VMware Compatibility Guide”, which can help you a great way. It shows which Vendors and Hardware models are supported. You can also use the search bar to find interesting topics about compatibility of different features, components or setups. Just be prepared, the tool can be a little overwhelming, and getting the right output can take some time. Link to the official compatibility guide, can be found here:
https://www.vmware.com/resources/compatibility/search.php
As you see in the next screenshot, the results show the supported vSphere versions for the different Hardware Models. However, you can’t see which version from the vendor itself is supported, and even VMware suggest that for that information, the Vendor itself needs to be contacted.
Besides the compatibility guide of VMware, most vendors also keep a guide or reference on their site. It is therefor a good practice to check with VMware as well with 3th party Vendors, if the versions are supported or compatible. VMware also has another guide called “The Interoperability Guide” or “Interoperability Matrices”. Since I spend some time on that topic in the next phase “vSphere Challenges & Decissions”, I will not go more in depht, for now. Here is a Link that you could check out in the mean time.
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#upgrade&solution=2
Some Handy Compatibility Matrix Links
To make it a little easier, here are some handy links for matrixes I used in the past.
HPE Hardware Compatibility Matrix vs VMware
http://h17007.www1.hpe.com/us/en/enterprise/servers/supportmatrix/vmware.aspx#.
I do have to note that with HPE servers, it is also sometimes possible to build a customized VMware image. For one customer I build an ISO that would support both version ESXi 5.1 and 6.5. Still, I had it validated with HPE, since the site isn’t always clear which version certain firmware of servers or even components support a type of version. I therefor always suggest that this should be checked with the vendor directly.
Citrix compatibility matrix vs VMware
https://support.citrix.com/article/CTX131239
As you see, the website of Citrix is quite clear about which version of Citrix is compatible with a certain version of VMware.
Veeam compatibility matrix vs VMware
The website of Veeam is also quite clear about the compatibility with all the different versions.
VMware Lifecycle matrix
Besides the compatibility Matrixes, I also found a handy Lifecycle Matrix that shows the end dates for the “General Support” & “Technical Guidance” for all the different vCenter products and versions. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf
And for those who wanna know the difference between “General Support” & “Technical Guidance”, this next post explains it quite nicely.
https://blogs.vmware.com/vsphere/2018/09/end-of-general-support.html
VMware ESXi compatibility Checker
In my previous post, I already mentioned this tool. The ESXi Compatibility Checker is a python script that can validate VMware hardware compatibility and upgrade issues of ESXi. It is an awesome fling, that is worth checking.
https://labs.vmware.com/flings/esxi-compatibility-checker
Summary
Getting a clear understanding of the dependencies that are present in the environment, helps you to identify roadblocks and plan the upgrade. Like I said earlier, this is one of the most time-consuming parts, but if done well, it totally pays off. One important thing to note is that you should check if newer firmware / software of your dependencies works on all versions, and not assume that since it is newer, it probably also support the current vSphere version. This is not always the case, and some updates of software / firmware are not backwards compatible.
In my experience, software Vendors are more often backwards compatible with newer releases, then Hardware Vendors. Hardware Vendors seem to have a more difficult time with being backwards compatible. At the same time, I have noticed that because something isn’t officially supported, it doesn’t mean that it doesn’t work. These simple type of nuances, help you when planning the upgrade and should therefore be fully examined.
Once you know how much your dependencies are supported and backwards compatible with newer versions or in-between upgrades, you are ready to plan your steps. Which help you with the difficulty for choosing between several upgrades, or preparing and migrating.
In the next post we are going to talk about the Technical decisions that could lead to different jumps, steps, pitfall and etcetera.
Hope to see you there.
See ya.
Samir is the author of vSAM.Pro & a Life enthusiast who works as a consultant in the field of IT. With a great passion for Tech & Personal Development, he loves to help people with their problems, but also inspire them with a positive outlook on life.
Besides that, he is also a big Sport & Music junky that loves to spend a big chunk of his time on producing music or physically stretching himself.
