Intro
One of the most important parts in projects (and also most of the time neglected) is the assessment phase. Creating an upgrade path and executing it, is no different. Some upgrade paths are easy and can be done in a few days or even hours. Others however, can take months, or even up to almost a year. The assessment phase gives you a great insight which of the latter this is going to be.
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)
Assesment Phase – Start with the Why
A quote I nicely borrowed from “Johan van Amersfoort” and his awesome book the “VDI Design Guide” is “Start with the Why”. How does the “Why” fit in a vSphere upgrade path you may ask? Simple, ask yourself and especially the customer or your boss the following.
Why do you want to upgrade?
This may sound simple, because the answer looks simple right? It can be new Features, Support of the environment, Security, compatibility with other Vendors, etc.
Still it is a vital question to ask, because it can determine the path you choose.
Example: Why you should ask why?
For example, the customer wants to link multiple vCenters so it can have a single pane of glass. For this you’ll probably think immediately about the feature “Enhanced Link Mode”. However, if you come from version 5.1 it means that you have to redeploy your complete vSphere environment, and a simple upgrade is not enough. And depending if you go to version 6.5 or 6.7, your choice also makes a difference IF you can use “Enhanced Linked Mode”. Since version 6.5 only allows EHL with an external PSC. In 6.7, this is also possible with the embedded setup. However, if the vCenter that you want to link to, is already deployed with version 6.5 and has an embedded PSC, you also have to redeploy that vCenter with a new instance to make EHL work. Upgrading both vCenters to version 6.7 will (currently) not work since you have to join one vCenter to an existing site, and in this setup this is not possible.
Still, let’s go back to the simple question “why do you want to upgrade” and “what do you want to achieve”? The single pane of glass sounds cool, but in the end the customer most probably wants to use the feature to simplify operations. If you have to change and or redeploy so many things to get both vCenters aligned and make EHL work, you can ask yourself if you then have the desired effect of “simplified operations”.
Example 2: Why you should ask why?
Another example is the unmap feature in VMFS6. Some customers want to use that feature, but are not aware that their Storage and OS also have to support Unmap to make the feature work. Also, most customers are not even aware that for VMFS6, you have to create a NEW Datastore. You cannot upgrade the datastore from VMFS5 to VMFS6 directly. Most people that look into unmap for the first time, are most of the time also the people that are in a situation where they have storage space issues, and hence comes one of your challenges. What if the customer doesn’t have enough space left to move around vm’s and data to create a new VMFS6 datastore? You can count on the fact, that these kind of factors can make an upgrade much more complex than initially realized.
Now there are lots of examples that I can go through regarding Upgrade situations, but you get the point. Later these series, I will go more in-depth about “Technical Challenges & Decissions” regarding certain features or combinations, but for now I will continue.
Importance of Assessment Phase
With that being said, I cannot emphasize enough why the assessment phase is so important, and why it shouldn’t be neglected. A good assessment will help you to quickly define some challenging issues and it helps you setting up the right expectations. Both for you, as for the customer. In the end the most important thing that you want to know is “what do you want to solve or achieve?”. If you are focused on that outcome, and not immediately start jumping into technical features or solutions, I’m sure that you will find the right focus and ask the right questions. Most IT people (including me) like to jump straight ahead towards a solution, but if you read my previous example thoroughly. You’ll notice that the customer didn’t ask for “Enhanced Linked Mode”, but just wanted to simplify operations. Enhanced linked mode can be a solution for that but that doesn’t have to be the only solution. Marco van Baggum, another colleague of mine, always like to challenge me with the question “what is it that you want to achieve?”, and every time I start ranting about some sort of technical narrowed down solution, most of the time he will help me to go back to the basics and focus on the outcome. This way of thinking helps him into making better design decisions based on the real needs of the customer, and it helps me every time I’m in a project as well. So, I’ll ask you to do the same in this assessment phase even though the answer seems so clear and simple.
Besides the “Why does the customer want to upgrade”, there is one more question that is even more powerful in my opinion, and that is:
Why has the customer not upgraded his environment (yet)?
Finding the Reason why the customer hasn’t upgraded their environment
If you just have a minor version jump, this question can most likely be simple answered in the form of “Lack of resources” (Time, People), and your upgrade will most likely be simpler.
However, if you’re coming from (now unsupported) version 5.5 while version 6.7 is already out there, or are even running version 5.1, you can bet that the answer is more complicated then you’ll expect. Most likely, there is no Life Cycle Management process in place, otherwise the environment wouldn’t be that outdated. It will give you a big hint that the upgrade path can take lots of time, and that the customer maybe has a structural or organizational problem. Which can even block the perfect roadmap and technical solution if not solved. This can be dependencies of Hardware & Software Vendors that aren’t compatible with newer versions, or maybe also needs several upgrades to stay compatible. The upgrade then shifts from a simple vSphere upgrade, to an upgrade that will include upgrading all the other vendors that are depending on it. Another big reason that some vSphere environments haven’t been maintained in ages, is because of a fragmented organization with lots of different departments, that are not used to work together on a regular basis (and are maybe even fighting). Since a vSphere upgrade can touch more domains then only the VMware part, it is suffice to say, that these kind of situations are more difficult than just the technical challenges. Getting everyone aligned from different departments, requires more then only technical skills. More importantly, you also want to define a process that makes sure that after you’ve upgraded everything, the organization is not going to wait for another several years so that you can come back and experience the same “challenge” again. Maybe good for you as a consultant in billable hours, but not a great way to truly help your customer. And no, only implementing VUM is not enough for that 😉.
Questions for Assessment Phase
Alright let’s sum up a few questions that can help you with this phase.
- Why does the customer wants to Upgrade?
- Why has the customer not yet upgraded or what are the reasons?
- Does the customer has some sort of lifecycle management or a process in place?
- What does the customer want to achieve with this upgrade / project?
Rule of thumb, if the organization is still on version 5.1 or 5.5 on the time of this writing, you can bet that something will come up that makes it “fun”.
As you may notice, the above questions are quite general and not really that technical. That’s because these questions will help you to get a good first impression of what you are up against.
The more technical questions will be asked during the next phase, and that is “defining the IST”. The IST is your so called starting point or baseline, and it will help you in getting an overview of all that there is. Once you know your baseline and the dependencies, you can define your goal and future state, the so called SOLL. Once you know that, you can define the approach you need for achieving the goal. We will make use of a method called the “GAP-Analysis”, and it is a great way for creating a great overview and defining objectives were you want to end up. It is possible that you never heard of the “Ist” and “Soll”, which is understandable since those words are mostly being used with dutch projects. Funny enough, the words Ist & Soll are actually not even dutch words, but german. Ah well, translated it just means “Current State” & “Future State” so you can use those if you prefer 😉.
Alright, thanks for reading and I’ll see you in the next post, but for now:
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.
