When it comes to managing a VMware vSphere environment, I tend to push the envelope a bit. Sure, I’m virtualizing like its 2013, but I realize that many others are not! With that in mind, I will be attending both VMworld events this year held annually in August – in San Francisco and Barcelona. One thing I always run into there is the reality that many VMware vSphere customers install vSphere and let it run. In fact, vSphere is really good at doing that. It just works. But, as many people check out new features at VMworld, attend an IT training event, or even dialogue with their peers; they’ll realize that a major upgrade is due. I’ve spoken to a number of people recently who are still using vSphere 4 or 4.1; and really don’t seem to have a pressing need to upgrade.
Well, at some point, an upgrade project will become a priority. There are plenty of reasons to upgrade to vSphere 5.1 or any other newer edition. VMFS-5 volumes can be larger than 2 TB, and that alone should spark your interest! Whatever the reason to upgrade is, there can never be too much preparation for a platform upgrade of something like vSphere. Before I go too far, make sure you check out Lauren Malhoit’s post on questions to answer before you upgrade. Lauren is a definite VMware and storage rock star, and she has some great points on this topic.
When upgrading vSphere, it’s a good time to address cosmetic and consistency issues that need cleaning up as well. The first example below is personally the most irritating to me — scattered names of objects. When it comes to networks and storage, it is very important to get names right! Nothing bugs me more than seeing names like “datastore”, “datastore (1)”, “datastore (2)” etc. How does an administrator know what is going on? Consider implementing some self-documenting names like Figure A:
With proper naming, it is easier to discern which datastore is a SAN (storage area network) volume and which volume is direct attached storage. Further, identifying the storage product, host, and volume are all pretty easy this way. When it comes to networks, roles, clusters and any other construct in vSphere; give some thought to a clear nomenclature.
The process of going through an upgrade of vSphere is a good time to tidy up, but you should also address some of the core issues. Here’s my list of five most practical things to accomplish as part of your vSphere upgrade:
#1 Upgrade vCenter first. This is really two tips in one. The first thing to do is read the release notes for a vSphere upgrade; it always says upgrade vCenter first. Reading the release notes will arm you with a lot of really critical information.
#2 Have a back-out plan. I wouldn’t offer this as advice if I hadn’t heard of real issues. Leverage things like a virtual lab, test environment, and adequate time to make sure you don’t get stuck.
#3 Use vSphere Update Manager. You (hopefully) put a lot of work into your vSphere environment. This can include host configuration, vCenter roles, networking and more. Don’t just re-install on the hosts and migrate them back; let vSphere do the work.
#4 Ensure VMs get upgraded. The vCenter Server and ESXi hosts are important, but so are the guests. Do what you can to get VMware Tools updated, and if possible, the virtual machine hardware version.
#5 Evacuate and reformat “old” storage. Storage can quickly become a mess out there. I’m curious if anyone has any SAN volume that has been around since ESXi 3? If that VMFS volume is way back to VMFS 3 at, say, VMFS 3.21, that volume surely has some garbage on it. Now would be a good time to migrate all VMs off of it, and reformat it as VMFS 5 if more storage changes aren’t on your horizon.
Hopefully one or more of these points become part of your checklist on your next vSphere upgrade. Paying attention to these five things will help you prepare for a successful project.
Do you have any pre-upgrade checks you have made part of your virtualization practice? If so, share them below. I’m sure others would benefit greatly.