Recent changes to VMware’s vSphere 5 licensing have drawn significant criticism from users. While the backlash has quieted down somewhat, the changes remain a matter of concern and confusion for VMware customers.
I don’t want to rehash the arguments for or against the virtual RAM (vRAM) model; that’s been
Changes to the vSphere 5 licensing model
With the latest licensing scheme, VMware has increased the vRAM allocations across a range of vSphere 5 SKUs. Initially these vRAM allocations were set at 48/32/24 GB, and these have been increased to 96/64/32 GB, respectively.
This represents a doubling of the vRAM allocations in the SKUs at the top-end of the vSphere range -- precisely the SKUs that customers running high-density servers would normally opt for. Some users in the community feel these vRAM allocations are still on the low side -- especially at the top end of the spectrum -- and would have preferred to see the allocations for Enterprise Plus increased to ranges as high as 128 GB.
The other interesting change surrounds VMware’s free version of the ESXi or the “Free vSphere Hypervisor” as they call it. It was initially capped at 8 GB, making its production usage almost nil. However, recent changes in the vRAM model increased it to 32 GB. This puts it firmly back on the table for customers that just need a basic virtualisation platform.
At the product announcement and at VMworld 2011, much was made of the “monster VM” capabilities of vSphere 5 – the term used to describe extremely large VMs (up to 1 TB of vRAM) that might need to be created for large tier-1 applications. But the initial announcement of the increased capabilities of VMs was largely overshadowed by the cost of such VMs. To answer this, VMware capped the amount vRAM counted per VM at 96 GB. This way, anyone wanting to configure a monster VM would need nothing more than one vSphere Enterprise Plus license.
How vSphere 5 licensing changes affect VMware users
This licensing change was significant enough to impact vSphere 5’s general availability, and, currently, the licensing reporting system isn’t reporting correctly the change in the licensing policy. It will take an update to vSphere 5 to fix this.
It is not clear when an update to fix the licensing reporting will be shipped. In the meantime, I’d recommend using the scripts that VMware has provided as a guideline to how much vRAM licensing they might require.
Finally, VMware modified how vRAM values would be calculated. The company initially proposed calculating the value at the “high watermark”, or at peak vRAM usage. This approach would not have played well in environments that experience temporary spikes in usage, such as in test and development, end-of-quarter results or, for retailers, during periods in the year when they experience a predictable increase in transactions.
These examples are exactly the types of scenarios where cloud computing would come into its own: when a business needs a temporary burst in IT resources to absorb an activity. So it was hard to see how vRAM licensing would deliver on VMware’s commitment to the cloud because that would carry a licensing penalty when there wasn’t a peak in load.
Fortunately, VMware recognises this and is considering a 12-month average on consumed vRAM rather than the high-watermark approach. With the general availability of vSphere 5 a few weeks ago, there is now an official script that runs against your existing vSphere 4 environment. The script provides insight into your vRAM capacity and its usage in vSphere 4.1 environments as if they were upgraded to vSphere 5. The script shows each licensed edition and the vRAM usage and capacity for that edition.
Right now, the script isn’t vCenter linked mode aware, so you must run it against each vCenter individually and then add the “vRAM Capacity” and “vRAM Used” values together. This draws another interesting issue: vRAM allocations are pooled across linked mode vCenters. Currently, only the Windows version of vCenter supports linked mode; the new Linux-based virtual appliance does not yet support this feature. Some folks in the VMware community are citing this as one reason why the virtual appliance edition of vCenter might experience slower adoption in production environments than was originally anticipated.
The new vSphere 5 licensing arrangements will affect users who have planned for very high RAM allocations in an effort to get the highest consolidation ratios possible. This includes shops where they now fit out their servers with either 128 GB or 256 GB of physical RAM.
The actual price customers will pay varies, but typically such customers should expect to negotiate hard for pricing that offers a significant discount on the list price.
Although the worst penalties of vRAM affect a small subset of customers, the changes worry customers about their future commitment to increasing amounts of physical memory and greater virtual machine (VM) consolidation ratios.
The changes to vSphere 5 licensing feel very much like the situation when Enterprise Plus was released to howls of protest. Maybe VMware is hoping that once the heat has burnt out of the debate, customers will once again upgrade regardless of the cost.
Mike Laverick is a former VMware instructor with 17 years of experience in technologies such as Novell, Windows, Citrix and VMware. Since 2003, he has been involved with the VMware community. Laverick is a VMware forum moderator and member of the London VMware User Group. He is also the man behind the virtualisation website and blog RTFM Education, where he publishes free guides and utilities for VMware customers. Laverick received the VMware vExpert award in 2009, 2010 and 2011.
Since joining TechTarget as a contributor, Laverick has also found the time to run a weekly podcast called the Chinwag and the Vendorwag. He helped found the Irish and Scottish VMware user groups and now speaks regularly at larger regional events organised by the global VMware user group in North America, EMEA and APAC. Laverick published several books on VMware Virtual Infrastructure 3, vSphere4, Site Recovery Manager and View.
This was first published in September 2011