vSphere 4.1 to 5.1 lessons learned

For the last two years, I’ve been behind the curve with VMware vSphere. My deployment has continued to run at vSphere 4.1 while the rest of the world ticked along with 5.0 and 5.1. We were stuck because we relied on VMware’s Update Manager product to handle guest OS patching in our environment and we needed to find and implement a replacement for this product.

After many months of evaluations, we ultimately decided up on VMware’s vCenter Protect product for patch management and upon implementing it earlier this year, we were finally free to upgrade to the latest and greatest vSphere.

At the same time, my last official VMware training class was with version 3.5 — and that class was only an update class.  A lot has changed.  I read blogs online and also buy books to try and keep up, but its hard to get well versed with you aren’t hand-on.  So, there were a number of things in this upgrade that I learned – some through reading – some through experience.

What I Learned

The jump from 4.1 to 5.1 is not a trivial one.  We ran good ‘ole ESX in our 4.1 environment and so the move to 5.1 meant the disappearance of the service console.  Fortunately, we did not use any specific agents or plug-ins inside of ESX, but we were quite used to the service console for troubleshooting.

Lesson 1: Get familiar with PowerCLI and ESX-CLI before moving from ESX to ESXi.

Troubleshooting and configuration is all handled remotely now from either PowerCLI, ESX-CLI or from the vSphere Management Appliance.  It is imperative that you get familiar with these tools before the move.  The great news is that you can use any of these tools against ESX installs the same as ESXi installs.  I spent about 6 months with PowerCLI getting very familiar with it and spending some time on ESX-CLI before our transition.  It was time VERY well spent.

Another major change with ESXi is the footprint of the actual hypervisor installation.  Frankly, its small.  There is really no need to have local spinning disks for accommodate the hypervisor installation and many of my peers have chosen to go with local USB Flash or SD storage instead.  Several years ago, when VMware first announced ESXi, this was one of their big features touted for the version – a smaller footprint and the ability to install it on USB Flash storage.  It holds true today, although I found that the ESXi 5.1 installer does not create a location for logs and persistent host data on the USB or SD.

Lesson 2: If you install ESXi to USB or SD, you also need to setup a place to store logs and crash dumps on shared storage elsewhere.

Quickly after installing ESXi for the first time on USB, my hosts alerted me that I needed to establish a shared storage location for logs and crash dumps.  A bit of searching on the VMware Knowledge Base, I found the following:

Due to the I/O sensitivity of USB and SD devices, the installer does not create a scratch partition on these devices. As such, there is no tangible benefit to using large USB/SD devices as ESXi uses only the first 1GB. When installing on USB or SD devices, the installer attempts to allocate a scratch region on an available local disk or datastore. If no local disk or datastore is found, /scratch is placed on the ramdisk. You should reconfigure /scratch to use a persistent datastore following the installation.

Basically, you need a VMFS datastore on which to save your persistent host data and a single datastore can work for all hosts in a cluster.  Once the USB or SD card is used for boot, it does very few write operations back to the disk – instead choosing a medium more suited to handling log data.

Each hardware vendor seems to create a customized distribution of ESXi that is available directly from VMware – whether you have Dell, HP or IBM hardware.  The custom image includes agents and drivers baked into the distribution for your specific hardware.

Lesson 3: Its worth using the vendor specific ESXi distribution because it helps light up CIM information in vCenter.

vCenter does a good job of keeping alarms and alerts front and center for the administrator.  With the OEM specific ESXi distributions or by adding the OEM specific packages to a standard ESXi installation, you will enable CIM agents to report on hardware issues and environmental conditions through a familiar interface.

On the topic of familiar interface, vSphere 5.1 marks the first version with the vSphere Web Client.  The Web Client is the destination for all the latest features and functionality  including enabling version 9 virtual hardware, shared-nothing storage vMotion, and version 5.1 Distributed Virtual Switches among other features.

Lesson 4: If its a new feature to 5.1, look for it in the Web Client.  And get to know the vSphere Web Client – it is the future.

VMware, as a company, has been very straight forward when it makes decisions – like eliminating ESX in favor of ESXi.  It gives its customers the information and then slowly weens them away from the old way towards its new direction.  The vSphere Web Client is the next in the list of these.  It is obvious that VMware is seeking to unify its client away from different interfaces and functionality towards a unified web portal for all its products and management.  The vSphere Web Client today already has the core vCenter and vCenter Orchestrator functionality packaged into the web client.  Unfortunately, administrators will have to run both the Win32 and Web Client to get the total picture.  VMware Update Manager only exists in the Win32 client today – so patching and upgrading your hosts and VMware Tools will need to be done there.  As of VMworld last August, VMware committed to moving the Update Manager functionality into the Web Client soon.  Search in the vSphere Web Client seems particularly powerful for locating both VM objects, infrastructure objects and settings.

There was a time when vCenter did all the heavy lifting for a vSphere deployment.  Increasingly, there are a number of additional solutions that most shops need to deploy along with vCenter.  One of the additions for 5.1 is the vSphere SSO Server – used for centralized authentication.  The SSO Server opens a number of new possibilities as the eco-system continues to grow.  It is a necessary part of the 5.1 deployment and should not be ignore; frankly, it cannot be ignored.  It is required.  As the eco-system continues to grow, interoperability becomes a bigger concern for administrators.

Lesson 5: Use the VMware Product Interoperability Matrix.  Check your database interoperability   Check version interoperability of all your other VMware ecosystem components.

Whether you’re using vCenter Server Heartbeat, vCenter Operations, Update Manager, Converter or any other component, the interoperability matrix will give you the information you need to ensure your components work together.  In general, vCenter Server 5.1 and ESXi 5.1 will require all the other components to be at version 5.1, but there are some components like vCenter Server Heartbeat that follow a different version numbering, so that matrix is a great resource to ensure you’re where you need to be.

Additional Links for 4.1 to 5.1 upgrade

• Installing or upgrading to ESXi 5.1 best practices (2032756) – VMware Knowledge Base
• Booting ESXi off USB/SD – Kyle Gleed, VMware vSphere Blog (Great advice for those considering USB/SD boot for ESXi)
• Installing ESXi 5.x on a supported USB flash drive or SD flash card (2004784) – VMware Knowledge Base
• Upgrading to vCenter Server 5.1 best practices (2021193) – VMware Knowledge Base
• vCenter 5.1 Upgrade Planned? Verify SSL Certificate Checking – Chris Wahl, WahlNetwork.com