Because of its new features and enhancements, many of your customers are likely anxious to start planning their vSphere 5 upgrade, and it’s important to know new caveats and issues before you let your customers dive right into it.

Solution providers can ensure a smooth transition to vSphere 5 by taking note of these important modifications and understanding what they mean to individual customer environments:

New licensing
Perhaps the biggest vSphere 5 deviation from previous versions is that your customers will need to deal with the new licensing model.

VSphere 4 licensing was fairly straightforward: as licenses were bought per CPU socket and you could run unlimited virtual machines (VMs) on the host. That model is no more with vSphere 5, and while licenses are still sold per CPU socket, each license comes with a fixed amount of virtual RAM (vRAM) that can be assigned to VMs. Depending on the environment, this could cause a customer to spend thousands of dollars in additional licenses to be compliant with new vSphere 5 licensing. The new model favors scale-out architectures that hold a greater amount of hosts that have smaller resource amounts.  This means less VMs running on each host, which results in less vRAM usage per host. When you try and scale up with hosts that have large amounts of RAM, the additional license costs to match the amount of that RAM in a host can get very costly.

As a result, you will want to analyze

vSphere 5 licensing’s financial impact for your customers before they commit to upgrading. You can install tools in a customer’s virtual environment that let them know if they’ll be compliant with the new licensing and what the costs will be to achieve compliance. In many cases, re-architecting or cleaning up their environment will help them stay within the vRAM allotments that their vSphere 5 licenses will provide. For a better understanding of the vSphere 5 licensing changes, check out VMware’s online whitepaper that explains it in detail.

Farewell, ESX
VMware has been saying for years that vSphere’s ESX hypervisor will eventually be retired and ESXi will be the only option left and it finally happened. If you want to upgrade to vSphere 5, it has to be with ESXi. Many customers still run ESX and never made the migration to ESXi, so they will need help with the transition, understanding the differences between them and adapting to the new ESXi architecture. At their core, ESX and ESXi are the same and the main differences between them are management, deployment and updating.

You should familiarize customers with the vSphere command line interface (CLI), vSphere Management Assistant (vMA), Tech Support Mode (TSM) and Direct Console User Interface (DCUI). It’s also crucial to walk them through the ESXi patching process, which is much simpler in comparison to ESX.

Virtual machine file system (VMFS)
Each new vSphere release includes an upgrade to VMware’s proprietary Virtual Machine File System (VMFS) that is used on datastores created on block storage.  VSphere 5 now has VMFS5 to keep the versioning consistent. VMFS 5 provides performance improvements, but the biggest change is with scalability. The 2 TB logical unit number (LUN) limit in vSphere 4 was finally increased to support LUN sizes up to 16 TB. VSphere 4 had multiple block sizes (1 MB/2 MB/4 MB/8 MB) that could be selected when creating a VMFS datastore. 

Each block size dictated the size limit for a single virtual disk: 1 MB = 256 GB, 2 MB = 512 GB, 4 MB = 1 TB and 8 MB = 2 TB. The default block size in vSphere 4 is 1 MB and once set, it cannot be changed without deleting a VMFS datastore and recreating it. This caused problems as many people used the 1MB block size and found that they couldn’t create virtual disks greater than 256 GB. With vSphere 5, there is only a single block size (1 MB) that can be used on VMFS volumes that supports virtual disks up to 2 TB.

One thing to be aware of is that while upgrading an existing VMFS3 datastore to VMFS5 is easy and non-destructive, it retains the previously configured block size. While the larger block sizes will work with VMFS5, certain vSphere APIs for Array Integration (VAAI) features such as copy-offload require datastores to be the same block size. Additionally, datastores that are upgraded from VMFS3 to VMFS5 do not benefit from other enhancements such as smaller sub-block allocation and increased file limits. This means it’s best to work with your customers to create a plan to move all VMs on a datastore to other datastores so you can create new VMFS5 volumes rather than upgrading existing ones.

There are obvious barriers that solution providers will encounter when helping customers perform a vSphere 5 upgrade. Keeping an eye on these potential issues will make this process easier for both you and customers. Part two of SearchSystemsChannel.com’s vSphere 5 upgrade series will delve into what vSphere 5 features mean to your customer’s environment.

About the expert
Eric Siebert is a 25-year IT veteran whose primary focus is VMware virtualization and Windows server administration. He is one of the 300 vExperts named by VMware Inc. for 2009. He is the author of the book VI3 Implementation and Administration and a frequent TechTarget contributor. In addition, he maintains vSphere-land.com, a VMware information site.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.