VMware vSphere 5 Licensing Updated (or “Me Too!”)
Most everyone by now has posted on and/or is aware of the recent vSphere 5 licensing changes, but I felt obligated to post on this to provide links as well as to follow up on my previous “vRAM” posts.
I’m not going to rehash all the details here, but I will provide links and comment on a few points…
Summary of New Changes
vRAM entitlements have been largely doubled from the previous numbers, such that Enterprise Plus now provides 96GB of vRAM per CPU socket. In addition to the vRAM increase, the most vRAM a single VM can consume has been capped at 96GB (I think this is very significant as I will discuss in a bit.
The details of the latest changes are available at the official VMware links below — which includes a handy tool for evaluating the licensing impact against your current environment:
- Announcement of licensing changes (August 3, 2011)
- vSphere Licensing Whitepaper (PDF)
- vSphere Licensing Advisor (tool)
Why Change the Model At All?
This is a question I’ve heard a few time and it’s a valid one. Some are wondering why we even need a vRAM component. I discussed this in a previous post and I’ll share my thoughts again here:
From an economic perspective, measuring consumption (via RAM allocation) will be a more accurate measure of resource valuation than measuring physically provisioned resources (CPU/Memory/etc.). This has significant implications for chargeback both within the IT organization and for cloud computing.
Within the IT organization it forces application owners to consider the resources they are demanding as opposed to demanding a pool of infrastructure. For many reasons I’m a big believer in accurately tracking the value of resource consumption and charging it back to those who request it. Not only are there budget considerations but often times resources are used more effectively under a chargeback model.
Now lets look towards the cloud. In the future I believe that it will be increasingly commonplace to see workloads migrated from private datacenters to service providers or even between service providers. As the public cloud evolves, wouldn’t it be nice for software licenses to be aligned with consumption, rather than a physical paradigm which may be different from one environment to the next? This is what VMware is doing and what I suspect – over time – more and more vendors will be forced to move into a similar consumption model that is not tied to physical hardware.
I can’t put it better than Wikibon’s Stuart Miniman who stated “if VMware’s licensing change becomes a forcing function for chargeback, that’s a #cloud silver lining” Chargeback is ultimately a good thing and enables a better alignment with the economics of the cloud.
In closing, I think VMware has some very good reasons for moving in this direction. Change is disruptive and we (and our processes) don’t usually like change, but aligning software costs with actual consumption rather than a less perfect physical server measure is a good thing in the long run and more vendors will likely consider a move in this direction at some point.
The Monster In the Room
One of the changes getting the least attention may be one of the most important. With vSphere 5 it is now possible to support a “Monster VM” of up to 1TB of RAM and 32 vCPUs. Now add a few more considerations:
Proprietary platforms like AIX/P-Series and HP/UX, etc. are great platforms for the database tier but their cost structure can be…well…profound. It has been suggested that the “Monster VM” model for the DB Tier can achieve budgetary savings over this expensive proprietary hardware even with the original vRAM model. Well on the cost side of the balance sheet, caping the vRAM cost at 96GB per vRAM just substantially reduced the licensing costs for that monster VM with 1TB of RAM. And that’s before we consider some of the intangibles of providing cloud-like OPEX and Agility benefits to the database tier (replication, DR, recovery, hardware agnosticism, portability, etc.).
Is vSphere 5 the release that takes on the DB tier and we see workloads moved from “big iron” RISC hardware? It could be. When you can run SAP at 94% of native and gain all the CAPEX, OPEX and Agility benefits I have to think that IT shops will be wanting to pilot this and explore the potential benefits and savings in more detail.
Now Can We Talk About What vSphere 5 Can Do?
Yes! It’s a shame that so much of the focus of the vSphere 5 launch was focused on licensing rather than the amazing new capabilities. Many have been blogging extensively about the new vSphere 5 features and their value and I hope to be joining their ranks soon as there is much to talk about! vSphere 5 — especially when combined with the complimentary cloud products (vCloud Director, vShield and more) — has so much to offer for not just the IT professional but for the organization looking to capture the CAPEX, OPEX and Agility benefits of the cloud computing model.