Aug 3 • Work Related • 15 Views
Earlier today I received an email from VMware regarding some new changes they’ve made to their new vSphere 5 licensing model.
As I’m sure you’re all aware, VMware created quite the stir in the enterprise market by announcing earlier last month that they would be changing the way vSphere 5 is licensed.
They are migrating to more of a service model license, which I personally don’t have a problem with. I would much rather IT departments take ownership of these systems, and charge internal company departments for usage. It’s a much more efficient way of deploying resources when HR, WEB, SALES, etc. don’t own physical pieces of equipment.
But alas I digress.
Previous to version vSphere 5, when most virtual infrastructures were being designed by companies, they would load hosts with as much memory as they possibly could afford at that time. Why?? Because VMware licensed vSphere 4 on a per CPU basis. While you were only allowed to have 12 cores per processor with an Enterprise Plus license, there was no restriction on how much RAM you could allocate to the host. And if you have any enterprise virtualization experience, you’ll know that RAM is the one resource that goes the quickest.
So in comes vSphere 5 with features everyone has been waiting for like Storage I/O control, up to 32 vCPU’s per VM, and more. But now there’s a catch. Instead of licensing only for each CPU, you now have to watch how much RAM you have assigned to powered on virtual machines. This is what’s reffered to as VRAM. Now, when you buy a socket license, there’s a certain amount of VRAM entitlement which is included with each license. If you have a server with 256GB of RAM, and wanted to use 100% of your available physical memory with virtual machines on that host, under the original VRAM entitlement numbers, you’d have to purchase 6 licenses when with vSphere 4 you would have only had to purchase 2. Now you see why the blogosphere was up in arms?
Well today, VMware has come out and made things a little easier to swallow.
Here is a table of new VRAM entitlements.
| vSphere edition |
Previous vRAM entitlement |
New vRAM entitlement |
| vSphere Enterprise+ |
48 GB |
96 GB |
| vSphere Enterprise |
32 GB |
64 GB |
| vSphere Standard |
24 GB |
32 GB |
| vSphere Essentials+ |
24 GB |
32 GB |
| vSphere Essentials |
24 GB |
32 GB |
They’ve also changed how VRAM is calculated.
• We’ve capped the amount of vRAM we count in any given VM, so that no VM, not even the “monster” 1TB vRAM VM, would cost more than one vSphere Enterprise Plus license. This change also aligns with our goal to make vSphere 5 the best platform for running Tier 1 applications.
• We’ve adjusted our model to be much more flexible around transient workloads, and short-term spikes that are typical in test & development environments for example. We will now calculate a 12-month average of consumed vRAM to rather than tracking the high water mark of vRAM.
Overall, I’m glad VMware was able to admit to their mistake, and try to make it right by their partners and customers by increasing entitlements for all editions.
I still don’t know where they got their initial figures for the VRAM entitlements, I can only guess that they pulled the available figures out of a hat. I mean really, 48GB per CPU socket is all you’re going to give me when I can purchase a Dell R910 with 1TB of RAM capacity and 4 CPU sockets? And as I mentioned before, it’s VRAM, not physical RAM. But a large number of my customers are using 80% or better of their current physcal RAM capacity. And without this most recent change, they were looking at pretty hefty license increases for vSphere 5.
If you have any questions feel free to post them in the comments!
Matt • No Comments
Read More
