The pitfalls of treating vSphere Licensing as an “All You Can Eat Buffet.”

FacebookTwitterGoogle+LinkedIn

This is a story on vSphere License Management within vCenter and the chaos that admins endure on a daily basis.

A number of years ago, I worked as a Pre-Sales Sr. Systems Engineer at VMware. We often engaged our strategic customers to review their license usage prior to their renewing an Enterprise License Agreement (ELA). In the annual review process, it quickly came apparent that vSphere admins had no idea how to manage, or even account for their own license usage using the VMware Portal or managing licenses through multiple vCenters. The two processes were completely disjointed.

To make things even more problematic, users could log into the VMware portal and split licenses into multiple licenses to be applied in different vCenters. This often resulted in the same keys being misused or used multiple time within the organization. To add insult to injury, vSphere admins could apply the same key to multiple locations with unique vCenters and use more than their entitlement. Lastly, upgrading one’s keys to a new version would often mean the old versions of keys were still in production while the new keys were also being deployed. The end result was considerable over-deployment of license entitlement.

Let’s look at how this happens.

An organization buys 1000 CPU licenses of vSphere 5 in a new ELA that consolidates all of their existing vSphere 4 license and support into a single managed key. The environment previously had 800 CPUs of vSphere 4 Enterprise and had made the jump to vSphere 5 Enterprise. During the ELA renewal, the decision was made to replace old hosts with new hardware, so 250 CPUs of new server hardware was purchased and deployed across their three main campuses. This shiny new environment would be split with 500 CPUs in the main campus, 300 in the second campus, and 200 in the third campus. In concept, this was all great!

Fast-forward one year, when the organization decides that Enterprise Plus should have been their strategic direction, so they want to add an addendum to the ELA replacing all of the vSphere Enterprise Editions with Enterprise Plus. However, before they jump, they want to obtain their license summary details to determine if they need additional licenses. Since licenses were split, upgraded, and deployed against three campuses, the effort to report on all the licenses and their true entitlement was a daunting manual task. The My.Vmware.Com portal was of little use, since it did not take into account the older vSphere 4 licenses that were supposed to have been upgraded and the license splits across territories.

We started the manual process of extracting all the licenses from the vCenter and looking up their entitlement, upgrade, and split history in the VMware portal with the help of the VMware License Management Team. After three months of effort, we had a reply back that the organization had significant over-deployment of licenses—to the tune of over 100%!

How could this happen? A single top-level vSphere Enterprise Plus key was extracted and registered into each of the regional vCenters. The problem was that the top level key entitled 1000 CPUs of vSphere 5 Enterprise. Each regional office started the process of migrating old hardware from vSphere 4 to vSphere 5 and adding new hardware; however, they never took their old hardware out of production. Instead, these systems were used for non-critical work like development, file/print, and desktop pools. In the end, we found that the primary campus had almost 900 physical CPU sockets of vSphere deployed; the secondary campus was approaching 600; and the third campus had also spiked to 500 CPUs. In total, they had deployed and were actively using 2000 CPU sockets with only 1000 CPU sockets under licenses.

Panic quickly ran through the customer organization ranks: they worried that they needed to true-up to the full 2,000 CPU sockets and effectively double their ELA size. This was not in data center upgrade strategy, and most certainly not in the budget.

The process of auditing actual license usage by host, plus total licenses deployed across vCenters was not an easy task. Even harder was dealing with the process of tracking down license splits, upgrades, and replacements in the portal after the ELA. Had they had visibility into the total license deployed, editions, versions, and host details, they may have been a little more aware of their predicament.

I came to understand that this challenge is actually very common across VMware accounts, and I wanted to help with a solution. While we cannot look into the VMware portal and track down license splits and upgrades, we can see the licenses deployed across hosts and the license key they belong to. This means we can tell if a license is over-deployed across vCenters, and if the organization is using more licenses than it is entitled to.

Here are two examples we have recently seen:

This is an organization which is planning for growth and actively managing licenses.

While others end up in scenarios like this:

Note the vSphere Enterprise Plus 5.0 entitlement is significantly lower than the actual usage. A poorly managed set of vCenters and ESX hosts often leads to over-entitlement and the need to true-up licenses at the next renewal period.

This can be avoided, however, with visibility into your own license usage, taking old systems out of the environment when you intend to replace or renew its license to a new system, and managing across vCenters.

Take the time to review your VMware Host License Summary. It could save you some headaches when you start your talks about renewals and ELAs with VMware and the VMware partner community. Take full advantage of the Host License Summary Card within the CloudPhysics portal to get your license management back under control.

Rightsize Your Environment Today!