Yesterdays vSphere 5 product launch was certainly slick and impressive, with the headline features being right on the money… but one of the more interesting points, the already infamous move to a ‘vRAM’ licensing model, has potentially serious implications for the SME customers currently running on Essentials.
The new model is simple enough – it adds the RAM allocated to running VMs in to the licensing mix. But the limits vmware have set are already outdated, and therefore give the product no shelf life at all.
Take an Essentials Plus customer with three two-socket hosts, each with a fairly standard 96GB RAM, running well utilised. Factor in Veeam Essentials for backup and perhaps replication, the latter being to a second Essentials cluster, and today under vSphere 4, the license cost would be:
- vSphere Essentials Plus, for primary site – $4,495
- vSphere Essentials, for secondary site – $495
- Veeam Essentials – $2,000
- Total $6,990
Fast-forward to vSphere 5, which seems to offer SME customers very little new functionality, and the cost will rocket because of the RAM being used in this example. The Essentials kits cannot be extended past 24GB per CPU (and it has been reported that this will be an enforced limit in the Essentials kits), so the customer would need to look to Standard editions. But this affects the Veeam licensing too.
Assuming Essentials (144GB total vRAM) would be enough for a limited functionality DR site, the license cost will rise thus:
- vSphere Standard Acceleration Kit, for primary site – $10,000
- vSphere Standard Additional CPU License due to vRAM limits – $995
- vSphere Essentials, for secondary site – $495
- Veeam Management Suite – 6 sockets – $7,200
- Total $18,690
In an instant, the hypervisor layer licensing cost rose over 2.5x, with barely any new features to show for it.
And this is today – we all know that RAM requirements increase over time with Moore’s law – it’s been that way since the 1960′s. This is quite different to the CPU licensing we’ve seen before, where increasingly power and core count has reduced the CPU count needed over time. Which, I guess is vmware’s reasoning.
But unless the licensed vRAM amounts are continually adjusted, vmware might just find their customers leaving at rates following Moore’s law too.
[...] the lower scale this hurts most seeing that they are probably utilizing alot more RAM then what the bottom licensing covers (24 GB is pathetic even 48 [...]
Well put, James.
I’m in a fairly similar situation. We’re a small company with 3 virtualization servers in the datacenter (as well as some ‘physical’, mostly database related) and one virtualized DEV server at the office.
Essentials Plus seemed like a nobrainer for our virtualization servers at the datacenter. Even with the new licensing rules, we can make it, but just barely. It doesn’t provide us with a whole lot of room to grow however. And this obviously bothers me a lot. I will start looking for alternatives, as the step up from Essentials Plus to Standard for a similar environment easily means a more than threefold cost increase.
The DEV server here at the office started as an old ESX 3.5. With the advent of ESXi, we dropped our support contract and simply went for the free ESXi 4.0 (and later 4.1). The hardware is slowly getting outdated and we had a purchase of a new server (2x QuadCore Xeons & 36GB RAM) planned this summer on which we hoped to put vSphere Hypervisor (the new name for what is essentially the free ESXi 5.0). As we use vSphere at the datacenter (PROD & QA), it makes complete sense to have a similar but simpler environment in DEV.
As it turns out, the vSphere Hypervisor now only supports 8 GB vRAM (that is the total configured RAM for all running machines combined). This obviously blows all previous planning out of the water. The VMWare options here are suddenly limited to just keeping ESXi 4.1 and not planning on upgrading to 5.0 in the coming 2-3 years. This would be unfortunate.
But this is where the competition comes in… Xen & Hyper-V can both be had at virutally no cost for our company (we have the Windows licenses already to support this and the free Xen version are enough for our uses). Previously I would have laughed this option away as I quite love VMWare’s vSphere platform. Now however, it is becoming a business requirement to explore the alternatives.
And this is where VMWare will be hurting itself most. For a lot of companies, chosing VMWare’s solutions was a no-brainer. The competition was never really investigated as continuing to consolidate on VMWare technology had all kinds of advantages (unified management, experience, know how, best of breed system, etc). But now, VMWare is practically inviting their clients to investigate and test the alternatives, and who knows, maybe the clients will find it to their liking…
Hi Gerrit, thanks for taking the time to post this in detail. It is irritating indeed! Maybe in this case, the dev server could use an Essentials license (<$500) – 48GB vRAM entitlement for the dual-socket server.
Unless things have changed or that I’m gravely mistaken (or rather our supplier is mistaken), licensing terms stipulate that you can only have one Essentials (or E+) kit per organization. Thus we can only use Essentials Plus at the datacenter, and we cannot have another extra license locally in the office.
Buying Essentials would also put me 500 euros over-budget on this particular project (which was already approved & budgetted for ) and means that I’d have to accomodate the management server somewhere as well.
These are trivial issues, but I’d rather not deal with that if I don’t have to. It’s unfortunate that VMWare puts us in this position.
Hi Gerrit, I can’t see a restriction on the number of Essentials (Plus) bundles an entity can own and operate, although there is a limit to one bundle per physical building under the Retail and Branch Office kit – have a look at the ESX(i) master EULA, and the 4.1u1 ESX(i) EULA.
I’ve already asked for clarification from our VMWare partner, but have yet to receive any feedback. Their expert suspected our interpretation was however correct (or used to be, if the terms have changes), but wanted to doublecheck.
I’ll give you an update when I receive feedback.
Thanks. Actually I just received a reply from Veeam on their licensing, which is that they are looking to relax their terms so that their Essentials bundles are available for customers with no more than six sockets of vSphere (5).
In a way that might give vmware even more of a headache, as it suggests Veeam aren’t looking to follow suit – at this stage anyway.
Seperately in talking to vmware, there isn’t a problem with multiple Essentials bundles, these can even be bought via the online store in quantities.
Hi James,
A little update from my side:
The Essentials kits CANNOT be bought in quantities as you suggest. The Licensing Support desk has clearly replied to my query that Essentials kits are restricted to one per legal entity AND location. So if you have Company A, which has offices in X, Y & Z, you can own 3 Essentials kits (AX, AY & AZ). Your data center (if it’s in a remote location) can be used as a ‘location’ in this context, IF you can be billed at the physical address of the data center (basically the data center would forward your stuff to your actual address).
(The feedback I received from Dell as our secondary VMWare licensing contact was that Essentials could only be licensed at one per legal entity, unless using ROBO kits, but VMWare’s own licensing desk clearly overrules this)
Further feedback from VMWare was also that it was highly likely that Hypervisor vRAM would change to something more sane, but that it was unlikely that the vRAM would rise above the current 32 GB vRAM for 4 pCPUs. What they meant by this is that the 8 GB vRAM restriction per pCPU was likely to be changed, but that the total vRAM max capacity would likely remain enforced. I hope this means that 1 or 2 pCPU can also have access to the full 32 GB vRAM. I can see that as a sane testing environment from my POV.
The 32GB rumour for the free license is indeed welcome news.
But I don’t know why vmware have told you that, since this doesn’t reflect either the EULA nor the information I have received from them on the same!
More fuel to the SME nightmare: A lil’ birdy told me that pricing for Essentials Plus is set to be adjusted on 22/08 (I suspect all prices will be adjusted at the release of vSphere 5.0) and that orders for old pricing have to be in by 15/08.
In my country, it will cost more than 5000 euros (excl VAT) to buy Essentials Plus with 1 (one) year of Production Support.
This is MORE than the current 4650 euros (excl VAT) for Essentials Plus with 3 (three) years of Production support.
That’s one hell of a price increase… Since for my own project I will not be able to convince management to pay 4650 up front, the cost across 3 years just went up 2000 euros from licensing alone.
Essentials & Essentials Plus vRAM pools are now 192GB vRAM (32 GB / CPU) and Hypervisor is now at 32 GB vRAM/pRAM regardless of pCPU count.
http://blogs.vmware.com/rethinkit/2011/08/changes-to-the-vram-licensing-model-introduced-on-july-12-2011.html#_edn2
Not bad, but two issues remain as far as I am concerned:
1) Moore’s Law: When planning my purchases, I look into the future and want to AT LEAST plan 3 years ahead. This means Moore’s Law is always in the back of my mind. Even if I don’t buy all the RAM now, I leave slots free to be able to replenish as my requirements grow and keep pace with Moore’s Law (in the past 5 years, they have & I expect them to keep pace in the future as well).
2) Grandfather old licensing: While this recent change is sufficient to fit most people’s current and near-future needs, there are still some people getting hurt over this. These people are forced to buy licenses, stay on 4.1 or migrate, regardless of their SnS agreement. VMWare should “grandfather” their licenses, and give them the licenses needed to match their current resources at the very least. If not, VMWare should entirely refund their SnS fees for the past 3 years.
Among Hyper-V and XenServer, review Proxmox as an excellent alternative.