Intro
VMware its product portfolio has grown immensely in the last several years. Most VMware products are designed to integrate & enhance each other but also to be compatible with one and another. However, it has become difficult to keep track of which versions of all the products are compatible and supported with each other. With a staggering list of products like: NSX-V, NSX-T, vRO, vRA, vROps, vRLI, vSAN and many, many more, it is understandable that lots of administrators have a difficult time to managing the Sphere environment, let alone upgrading it. That’s why VMware introduced “VMware Validated Designs” which will be the focus of this blogpost.
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)
VMware Validated Designs (VVD)
VMware Validated Designs or VVD, is simply said a framework that helps organizations to deploy and manage complex vSphere environments in an easier and clear way. The VVD considers all the vSphere products and present it with an architecture framework that has generates a clear overview of supported versions and compatibility between all the different products within the vSphere realm. Now do note that the VVD is not a feature or button that will automatically take care of the deployment & upgrade. It should be seen as a reference architecture that VMware has heavily tested and validated as working and best practices. VMware does have a tool that follows the VVD design and that will take care of the deployment and upgrades in an automatic way, which is called vCF. Still, vCF is still heavily being developed and is at the time of this writing not really perfect, but it looks really promising.
However, the cool thing is that VVD also helps with design decisions and it can help you to find out which version numbers of vSphere products are compatible with each other. The VVD documents also have a version number. Each version number has a different reference architecture and different versions of supported vSphere applications. Let’s have a few examples.
VVD 4.3
The VVD 4.3 is a collection of vSphere products based on vCenter 6.5u2 & ESXi 6.5u2, the reference architecture in that version is also focused on the external PSCs instead of embedded. VVD 4.3 also focus itself on NSX-V with version 6.4.1. All other applications that exists in the vSphere realm are sort of based on these versions and are all supported, validated & compatible with each other.
VVD 5.0
Now when you look towards VVD 5.0 you see that this is a collection of vSphere products based on vCenter 6.7u1 & ESXi 6.7u1, the reference architecture in that version is still focused on the external PSCs instead of embedded. VVD 5.0 is also still focused on NSX-V but this time with version 6.4.4. All other applications that exists in the vSphere realm are based on these versions and are all supported, validated & compatible with each other.
VVD 5.0.1
After VVD 5.0 there was a minor update that included a supported version of the new
NSX-T. VVD 5.0.1 still contains external PSCs. However, we see that in update 6.7u2 the focus seems to move towards embedded PSCs. Still, at the time of this writing (26-06-2019), the latest VVD version has not included vSphere 6.7u2. You can however, bet that the new VVD will move towards embedded PSCs when it includes 6.7u2.
Update Sequence & Order
When moving one vSphere version to another, you need to be followed an update sequence to stay compatible, and this can very with each version. Let’s discuss the different methods that we can use for finding the right Update & Version Sequence.
Update Sequence & Order with VVD
When going from one VVD version to another, you need to upgrade different components to stay compatible. Luckily for us, VMware has clearly described what the update sequence for all the different vSphere components should be. Following a VVD upgrade works best when an environment stays as close as possible within its original framework and the versions that were delivered and designed for that. Creating too much deviations from the original framework and you might not be able to follow the upgrade for each product step by step. It is even possible that you will face (blocking) problems when trying to upgrade towards a higher VVD, or you may have created an unsupported or incompatible product line within the vSphere environment for a future framework. Simply said, the closer you stay within the original framework, the easier the upgrade towards a higher VVD framework becomes.
At the same time, creating deviations doesn’t mean directly some products are not supported or even incompatible. It is possible that a deviation is supported with all the other vSphere products. Support between vSphere products or alignment with the VVD framework are 2 separate things. A VVD just clearly defines a Validated Framework with all the vSphere products at the moment of time that it is delivered, and it assures you that a supported upgrade path for the next framework and updates will be delivered as well. You can change or update some products without following the VVD and still be supported, but you are not guaranteed that the upgrade towards a higher set of product versions is supported for the future as well. I hope that this makes the difference clear.
Best thing to do, is to try to stay as close as possible within the original framework of the used VVD, and to try to avoid deviations as much as possible.
Update Sequence & Order with a slimmed down VVD
Slimmed Down VVD? Yes, a slimmed down VVD, or that is how I like to call it. I stated earlier that it is best practice to stay as close as possible towards the original VVD Framework and to avoid deviations where can. However, there is a difference with the types of deviation that we have.
If you choice to use a VVD 4.3 framework where NSX-V is the standard, but you want to deploy NSX-T or a complete different version then is suggested, that type of deviation can be difficult later along the line. In this case, you literally changed something and that can impact you when upgrading towards a higher VVD.
However, when you decide to use the VVD 4.3 but just not some of the products and just left them out, that type of deviation will have a far lesser effect when using the framework, and probably has no effect. For example, if you chose to not use vRLI & vROps, the only thing you have to do is, is to skip them when you are following the sequence order towards a higher VVD. It is that simple.
Update Sequence & Order without VVD
Besides following the VVD framework, VMware has also described a general update sequence for all the different components within vSphere. This can be different depending on the general vSphere (vCenter & ESXi) versions you are on. It doesn’t necessarily describe to which version the products should be upgraded like the VVD does, but it does define your upgrade order. With the interoperability Matrix this can still be sorted out, but it takes a little bit more time. However, the template shared earlier in these BlogPost Series can help you creating that grant overview.
A fun thing to note is that the sequence order of upgrading the different versions within the vSphere environment has changed several times between the Major updates. Normally, I would think that in every case, the vCenter would be the first component to be upgraded. However, when you will check out the following links, you will see that the vCenter is actually the 12th product in order to be upgraded if you would use all the VMware products. Which is something I didn’t expect. This is since vSphere version 6.5.
- Sequence Order based on vSphere 6.0
- Sequence Order based on vSphere 6.5
- Sequence Order based on vSphere 6.7
When you look in the sequence table, the vCenter shows number 8 not 12. That is because multiple products share the same sequence number. This means that two products with sequence number 6 should always be upgraded after the product with sequence number 5. Once the product with sequence number 5 is upgraded, it doesn’t matter in which order the products with the same sequence number (6) are upgraded. Also, when you don’t use some of the products listed in the table, you just simply skip it and continue with the next sequence number. Just like I explained with the “slimmed down VVD” setup.
One last pro tip from me
Whether you’re choosing to follow a VVD framework or not, it is always handy to check out the VVD documentation. It can definitely help you with the process of creating a Roadmap for upgrades or help you for designing a new deployment. Do note that the VVD does not consider any specific type of Hardware. It is purely focused on the VMware Portfolio. VxRail of Dell is one of the few that also integrates the Hardware part with the VVD, but that is a different topic for maybe a future blogpost.
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.
