After a rocky two days on the blogosphere, the forums, Twitter, and practically everywhere else, I would like to add in my 2 cents. My apologies if this turns out to be a long post.
Firstly let me say - the release announcements made on Tuesday - are amazing!! The amount of new features, improvements, the scalability - are amazing. Congratulations on the great work and all the new additional features.
But all of this has been overshadowed by Licensing. Twitter, this thread, numerous amounts of articles on the blogosphere (more than 30% of the articles published on Planet V12N in the last two days) - with examples of how this is good or how this is bad, Power CLI scripts here and here which will help you check what your current status is and how this will effect you.
The official Whitepaper is available here.
There are two parts to this - and unfortunately almost everyone is only focusing on the first - but they are missing out on the second.
- License entitlement when I upgrade.
- Adapting to a new licensing scheme - which is more aligned to a per-vm model.
I would actually like to start with the second, and then get to the first.
Yesterday it dawned on me. VMware has (intentionally or not) moved to a per VM pricing model when licensing your ESX hypervisor. This started a while back with some vCloud, CapacityIQ and a number of other products as well.
Let me explain in more detail what I mean. vRAM Entitlements are defined per License Level. You get a license to power on X number of virtual machines with allocated memory as per the limits below:
- Essentials - 24GB per socket (max 144GB)
- Standard - 24GB per socket (no max)
- Enterprise - 32GB per socket
- Enterprise Plus - 48GB per socket
Let me explain with an theoretical example. I have a cluster with 3 dual 6-core servers with 96GB RAM in each server. License level is Enterprise Plus.
That comes out to 48GB * 2(sockets) * 4(hosts) = 288GB vRAM Entitlement
My environment is standardized. I have 2 types of VM's (disk is not really relevant to this discussion)
- Type1 - 1vCPU, 2GB RAM
- Type2 - 2vCPU, 4GB RAM
Let's assume that I would like to allocate 100% of my RAM. This will still leave me with additional spare Physical memory to to back the VM's in the case of failure, because some of the VM's will be sharing common memory.
I could in this case have:
- 144 * Type1 = 288GB allocated RAM
- 72 * Type2 = 288GB allocated RAM
- 50 * Type1 + 47 * Type2 = 288GB allocated RAM
- Any other number of options apply.
So how is this connected to per-vm licensing? Very simple. If I now know I can run a defined number of virtual machines according to my entitlement.
- 144 Type1 / 6 licenses = 24 VM's per License
- 72 Type2 / 6 Licenses = 12 VM's per License
Using this calculation - I can now assign a cost to every VM that is in-use. Granted this is not the only parameter to to be taken into account. Disk usage, CPU, ESX hardware and a large number of other factors. But I can definitely attest to the fact that a every 1GB of RAM that a powered-on VM has allocated to it is definitely 1/<entitlement>, either 1/24, 1/32, or 1/48 - and each license has a cost.
Up until now, it was not so simple to estimate how much virtual memory costs. You have over allocation, page sharing, and other factors. Now it is a clear-cut calculation.
So if we take my previous cluster scenario (using list price) each GB of RAM allocated costs $3,495 / 48 = $72 / per GB.
So how does this help you as an a consultant, an architect, an admin? This actually makes your job a whole lot easier. Now have a definite number to grasp. This will provide you the option to present the cost (and if need be - charge for it) for every single VM that is created.
Is this the be-all and end all of the equation? Not by a long shot.This does not take into account how long the VM was active. This does not take into account CPU usage, Network usage, Hardware costs, SnS, Storage tier and consumed space. This does simplify and give a definitive number to start to work with.
Gone are the days where you can cram as many VM's as you want, overcommit like crazy and hope for the best. VMware have in fact enforced a best practice and a proper design element into your vSphere environment.
Get with it. Pricing is has moved to per-vm. But not just a simple per-vm price - this is smarter. VM's that have 512MB are not equal to those that have 16GB of ram allocated to them, at least not in this round. Some of VMware's other products, this is not so, a vm is a VM, not matter what the resources it has allocated to it.
Now back to the first point. The sizes of vRAM Entitlement blocks. This is what is causing the biggest uproar.
Customers are not happy. VMware has forever being pushing over-commitment of RAM on a host as a feature, that was a unique feature of VMware's until not so long ago. Microsoft were sweating blood with Hyper-V to get their version of this out the door as soon as they could.
The way I see it there are two main areas that are going to be hit by this and hit very, very hard.
- Customers with Essentials Bundles
- Customers with 2-way servers with more than 96GB RAM per server and those with 4-way servers with over 192GB of RAM.
Why Essentials customers? A year / two ago VMware released the Essentials Bundle. This included:
- 3 * 2 socket servers.
Never mind that the transition path from the this package to an full-blown vCenter with STD. and upwards licensing was a royal PITA, but many small organizations saw this as an investment
I will invest in the Essentials bundle, invest in a Central storage array of some sort, and buy 3 ESX hosts and pack them with as much RAM as I can - 64/128/256. That way I am sure that my needs will be more than covered for the next few years. My machines don't use that much CPU anyway, the thing that everyone is telling me is that I will hit a RAM constraint much quicker, so the investment in the extra RAM will be well worth my while.
In comes vSphere 5.0 with vRAM entitlements. and instead now you are telling me that in order to use all the RAM I will have to invest a whole lot of money to update or keep my environment relevant.
And why the high density servers? Well that is pretty obvious. Anything above the 2 * vRAM Entitlement will entail additional charge. This is something that large organizations have built themselves upon and have managed to build high very high consolidation ratios. This of course has been all in accordance with VMware's vision.
But even more so - all the hardware vendors have been going the same way. More RAM slots on each server, blade. IBM and Dell even went as far as to invent their own RAM expansion device - to cram even more RAM into the same rack space in your datacenter - now they have been left out to dry.
I think that VMware will come round on the limits, I think they will most probably double - at least for the higher-end licenses. The same thing happened the last time around with vSphere 4.0 and the retirement of Enterprise plus. VMware originally announced that they would remove the Enterprise edition - but negated on that move. Because of the bad publicity that produced.
The lack of official response from VMware regarding this licensing uproar has been too quiet. The attempt to move the focus of attention to the benefits of the new features and away from licensing - is not working. People are vocal - and even more vocal when it touches where it really hurts - their pockets. Many threats of moving away from VMware to other platforms are becoming more and more visible. But that move is not so simple.
The strategy is changing - VMware is coming out with the official tools to help you assess how this will affect you. More information about licensing changes (or lack of) in View licensing. more and more data. But I think this should have all been ready from day 1.
One last thought - and 3 pieces of advice to all of you out there.
- Take a deep breath….
- Take another one.
- Do the math - and then do it again. Review exactly what you have, what you need and most importantly how this will affect you in the future.
I am sorry that this raised the percentage of posts that are related to licensing and not to the great new features available.
More on that another time.
Your comments and feedback would be highly appreciated.