While VMware released vSphere 5.5 soon after the dust settled from VMworld 2013, many virtualization administrators...
are just now migrating their production environment from vSphere 4.1 to 5. The ESXi 5 upgrade process can be relatively painless, provided you follow VMware's best practices and heed some of these hard-earned tips I've picked up from the many upgrades I've performed.
Make backups -- and verify
Prior to any upgrade or change, make sure you have a good -- tested -- backup of everything. This includes guests, databases, vCenters and everything else. It is all too easy to hit the wrong button and wipe out your virtual environment!
Use VMware's upgrade tools
In certain versions of ESXi 5, namely 5.1, there is a big issue about supported domains.
Run the vCenter Host Agent Pre-Upgrade Checker that comes with the vSphere 5 install media. It provides an automated sanity check and ensures all hosts are communicating properly.
In addition to inspecting the status of the hosts and the connectivity, check the hosts you intend to upgrade against VMware's Hardware Compatibility List (HCL). Sometimes you will find the hosts fall short of the requirements of the HCL. Doing this review could save a lot of heartache later if you upgrade on unsupported hardware and then can't get support if something goes awry.
Tidy your domains
In certain versions of ESXi 5, namely 5.1, there is a big issue about supported domains. For reasons unknown to me and -- in my experience -- VMware support, you can support only one Active Directory (AD) domain to avoid issues. I suggest you do two things. First, which is a best practice, make sure the users of the vSphere infrastructure use management accounts and that all the management accounts reside in the same AD domain. Second, unless you have a compelling reason not to, I advise going to 5.5 due to its better single sign-on (SSO) setup routines and easier installation.
Split vCenter into VMs
As the functionality within vCenter has grown, so has the size of VMs. This change means vCenter is likely to expand to a very large VM, and the VMs will take up quite a bit more space. VCenter 5 and SSO was the first attempt to split the services across several VMs, which means exercises such as vMotion between hosts and restarts after failure take less time, and the services can be spread across multiple hosts.
Another compelling reason to split VMs: I'm seeing more signs that vCenter may disappear from the Windows platform. By separating the support VMs, such as the vSphere Update Manager (VUM) and SSO, admins will have an easier time with future upgrades.
Be careful how you split the VMs
It may run contrary to the previous advice, but not all services should be on separate VMs. To reduce overhead and keep network traffic at a minimum in the VM support infrastructure, it makes sense to bundle some services so the machine the VM needs to talk to is on the same host. I recommend the following consolidation:
- VCenter gets its own VM and contains the core vCenter infrastructure.
- Single sign-on and Web client are together for heavyweight authentication.
- VSphere Update Manager gets its own VM.
Be lazy and upgrade with VUM
Using VUM and a logical plan, you can execute the upgrade process very quickly. To upgrade using VUM is very easy. Create a host upgrade baseline with an appropriate ESXi image. After you have appropriate backups in place, deploy the upgrade and you're done.
Don't upgrade -- delete and recreate
Changing vSphere versions
Avoid costly problems during a vSphere upgrade
How to upgrade a server to ESXi 4.1
VMware Virtual Machine File System (VMFS) 5 delivers a number of new features including storage-based heartbeats. Be aware there are major differences between upgrading from VMFS 3 to VMFS 5 and reformatting the logical unit number (LUN). A new VMFS 5 data store has an efficient 1 MB block size. You can upgrade a VMFS 3 data store, but the legacy block sizes will remain. It is best to create the LUN using VMFS 5. Use vMotion to move the VMs onto alternate storage during this operation.
Before either upgrading or replacing, make sure your entire cluster is upgraded; otherwise, the remaining hosts still on version 4 will not see the version 5 data stores. This could cause you a whole lot of problems!
Understand VM hardware requirements
Most companies, regardless of size, still have some guests running on VM hardware version 4. Before you upgrade, make sure any guests running version 4 are upgraded to version 7. If you plan to do Secure Shell (SSH)-based virtual-to-virtual migrations between hosts in different vCenters, you can still fix this upgrade issue. Once the VM is copied and added to vCenter, it will show as unsupported. Right-click on the VM and select Guest, then Install/Upgrade VMware Tools; once that is complete, right-click on the VM and select Upgrade Virtual Hardware. The VM should indicate it has a supported configuration.
Be aware that if you chose hardware version 10, you will no longer be able to edit the VM using the Windows -- or C# -- vSphere client. You will need to use the vSphere Web Client instead, so be careful about which hardware version you use, especially with vCenter.
Forewarned is forearmed
As long as you plan ahead carefully, the upgrade process is easy. Reading and digesting the upgrade documentation and installation documentation available on the VMware website is never a waste of time and can avoid some of the potential pitfalls.