vSphere 5 Licensing

[SuperSpike]

I took a minute to read the licensing guide for vSphere 5 and I'm still trying to pull my jaw off the floor. VMware has completely screwed their customers this time. Why?

What I used to be able to do with 2 CPU licenses now takes 4. Incredible.

Today

BL460c G7 with 2 sockets and 192G of memory = 2 vSphere Enterprise Plus licenses
DL585 G7 with 4 sockets and 256G of memory = 4 vSphere Enterprise Plus licenses

Tomorrow

BL460c G7 with 2 sockets and 192G of memory = 4 vSphere Enterprise Plus licenses
BL585 G7 with 4 sockets and 256G of memory = 6 vSphere Enterprise Plus licenses

So it's almost as if VMware is putting a penalty on density and encouraging users to buy hardware with more sockets rather than less.

I get that the vRAM entitlements are for what you use, not necessarily what you have, but who buys memory and doesn't use it?

Forget the hoopla about a VM with 1 TB of memory. Who in their right mind would deploy that using the new license model? It would take 22 licenses to accommodate! You could go out and buy the physical box for way less than that today, from any hardware vendor.

Anyone else completely shocked by this move?

[hmtk1976]

The apologists are back again!

I can sell a DL585 G7 with 512 GB RAM (and 2 hard disks) to a customer for € 24.000 VAT included.  For a quad socket machine with 48 cores this is not too bad.

BTW I think's it's really lame that vRAM for a FT machine counts for both the primary and secondary VM.  You pay for the feature and then pay essentially double for vRAM.

[hmtk1976]

SeanLeyne wrote:

Dracolith wrote:

Bigi wrote:

Again you paid for vSphere 4 and support, no one guaranteed vSphere 5 for you.

Wrong.     If you bought vSphere4,  you pay for   SnS.  That's short for Software and support.

SnS according to VMware includes entitlement to all future upgrades  at zero additional cost  (other than maintaining SnS).

I had read in an email I had read from my supplier that I only had 30 Days to accept the v5 EULA, otherwise the later upgrade would not be a $0.

Has anyone talked to VMware and confirmed that I could upgrade to v5 and any point in my SnS term?

Further, if I am SnS now and my contract expires in 6 months, and I renew, can I upgrade to v5 later and $0?

Would this mean that if you were to keep using 4.1 you'd still be bound by the v5 EULA concerning vRAM?  30 days isn't even a reasonable time to test!

[Dracolith]

hmtk1976 wrote:

Would this mean that if you were to keep using 4.1 you'd still be bound by the v5 EULA concerning vRAM?  30 days isn't even a reasonable time to test!

As far as I know, VMware never said anything about 4.1 deployments being bound by the v5 EULA,  or about a 30 day limit to upgrade.

The "v4 bound to v5 EULA idea"  and  "30 days to upgrade ideas",   I believe,  are  unfounded rumors.

To the contrary,  according to the pricing whitepaper, if you buy new vSphere5 licenses, and exercise  your rights  under SnS to downgrade to vs4,   the VS5   vRAM rules do not apply to your vs4 deployment,   Only to VS5 deployments.

[J1mbo]

Having personally invested so much time in vmware, it's quite sadening to see this unfold.

But as the industry moves to NFS and hence bypasses the 2TB LUN issue, I have to wonder whether v5 will end up being vmware's Vista.., i.e. sales for many being for the downgrade rights alone.  It certainly looks that it will be sensible for many to deploy unrestricted v4 unfortunately and just bypass both technical and compliance issues.

[JAndrews42]

>and hence bypasses the 2TB LUN issue

What 2TB LUN issue?  VMFS5 supports 64TB LUNs

[Dracolith]

JAndrews wrote:

>and hence bypasses the 2TB LUN issue

What 2TB LUN issue?  VMFS5 supports 64TB LUNs

vSphere4 does not support VMFS5.

Upgrading to VS5 bypasses the 2TB LUN issue.

BUT so does  using NFS and  not upgrading to VS5.

[rjb2]

tomaddox wrote:

Bigi wrote:

@ allenb1121

if 48 cores and 512GB of ram is not extreme I dont know what is.Your living in fantasy world. In your case stick with vSphere 4 no one is forcing people to upgrade. Updates and bug fixes will still be provided for version 4 even 3.5 still gets updates.

One can easily purchase an HP 4-socket Opteron system with that build, probably for about $30K, so no, I wouldn't consider it extreme.

Can we all agree that the "per CPU" model breaks at a certain point? For those that can't accept this, it probably doesn't make sense to read the rest of this post.

Now that we are all in agreement that there needs to be a new model, there needs to be a baseline established. The posts by Tom and Bigi made it clear that there is a difference of opinion about what is "normal". The "extreme" system today will most likely become the new "normal". This is part of the problem that VMWare is trying to solve so that they can continue to stay in business.This leads me to believe that we should shift the discussion to the value we are getting for our money.

Let's say VMWare would set the vRAM at 128 GB per CPU for Enterprise+. This would cover the Opteron system above, but when 4 sockets and 1 TB of RAM becomes the new "normal", the 4 licenses would no longer cover it. But, wouldn't that doubling of memory allow you to run more VM's, each of which has some value?

Now, the biggest problem that I see with this change has less to do with the future "normal", as it does with what we bought in the past and have paid SnS on. VMWare has sold a lot of licenses that entitled us to use up to a certain amount of RAM; for most versions this was 256GB "per host". That was the baseline that we were all working with when we purchased our licensing, so when VMWare decided to take away something we had paid for, many of us were rightfully upset to the point of some questioning whether it was even legal. We were not working with the assumption that we could scale beyond 256 GB per host and scale into the Opteron example given above, unless we were already buying Enterprise Plus.

So, I think we could all agree that Opteron example would require Enterprise Plus licensing even in the v4 model; 4 of them to be exact. And, the same system would realistically only require 4 licenses under the newly proposed v5 entitlements.

This takes me back to the point about what people have already purchased. For those who in the past had bought an Enterprise Plus license and thought they could use it with a CPU on a host with unlimited RAM, they have a legitimate gripe.The same thing applies to the other versions where a % of the RAM entitlement has been taken away. And it is this problem that may not go away anytime soon without some additional consideration by VMWare.

Here are two ideas:

1. Allow customers to run upgraded licenses in a separate vCenter up to the old entitlements. For example, an Enterprise Plus license would be able to run as much memory as they want in the hosts that have the upgraded v4 licenses on them. This is a provision that has already been added for virtual desktops already, so why not apply this to server workloads as well?
   
2. Provide vRAM packs to cover the paid versions up to the previous limits. The problem with this is that it wouldn't work for Enterprise Plus,.but there is a general consensus that VMWare should have vRAM sku's.
   

[J1mbo]

This would cover the Opteron system above, but when 4 sockets and 1 TB  of RAM becomes the new "normal", the 4 licenses would no longer cover  it. But, wouldn't that doubling of memory allow you to run more VM's,  each of which has some value?

No, because the OS's and applications in them will be demanding equally more RAM by then.  For example no-one would deploy a Win2k8R2 terminal service with 2GB RAM, which might have been fine before.

[Dracolith]

rjb2 wrote:

Can we all agree that the "per CPU" model breaks at a certain point? For those that can't accept this, it probably doesn't make sense to read the rest of this post.

With one stipulation.

The  per GB of RAM per licensed CPU model breaks at a certain point too.

And given the low RAM entitlements chosen by VMware, it breaks a lot sooner.

VS5 is not an abandonment of the per CPU model.

It's grafting on  another  very annoying restriction.

Seriously, what will happen in 3 years,  when the average server has a minimum of 512gb  of RAM

and the latest servers coming out can be loaded up to  6TB of RAM?

And  Windows 2012 Server is out  with a minimum supported system requirement  of   16GB of RAM per

server,  with recommendation of at least 32GB of RAM per basic server

[rjb2]

J1mbo wrote:

This would cover the Opteron system above, but when 4 sockets and 1 TB  of RAM becomes the new "normal", the 4 licenses would no longer cover  it. But, wouldn't that doubling of memory allow you to run more VM's,  each of which has some value?

No, because the OS's and applications in them will be demanding equally more RAM by then.  For example no-one would deploy a Win2k8R2 terminal service with 2GB RAM, which might have been fine before.

Is that a fact, or is it a prediction? Just a few years ago, it was the CPU that was the bottleneck. Maybe there will be another discontinuity in the next few years.

This takes me back to the point about what people have already purchased. For those who in the past had bought an Enterprise Plus license and thought they could use it with a CPU on a host with unlimited RAM, they have a legitimate gripe.The same thing applies to the other versions where a % of the RAM entitlement has been taken away. And it is this problem that may not go away anytime soon without some additional consideration by VMWare.

Here are two ideas:

1. Allow customers to run upgraded licenses in a separate vCenter up to the old entitlements. For example, an Enterprise Plus license would be able to run as much memory as they want in the hosts that have the upgraded v4 licenses on them. This is a provision that has already been added for virtual desktops already, so why not apply this to server workloads as well?
   
2. Provide vRAM packs to cover the paid versions up to the previous limits. The problem with this is that it wouldn't work for Enterprise Plus,.but there is a general consensus that VMWare should have vRAM sku's.
   

[J1mbo]

RAM requirements have grown broadly with Moore's Law since 1971, so I'd say there is a good chance

I don't think CPU has been a limitation (compared to RAM and disk) for some time - it is precisely why virtualisation works in the first place.

[rjb2]

Dracolith wrote:

The  per GB of RAM per licensed CPU model breaks at a certain point too.

And given the low RAM entitlements chosen by VMware, it breaks a lot sooner.

VS5 is not an abandonment of the per CPU model.

It's grafting on  another  very annoying restriction.

I would agree with you on the points mentioned above. But, I also think the market forces will determine how this plays out. Pricing is a big challenge.

That is why I think they need to avoid devalueing existing customers investments, and also set a competitive entitlement going forward.

And, retaining the per CPU licensing is as you say "annoying".

[JAndrews42]

J1mbo Any proof on the "industry moving to NFS"? (other than NetApp marketing materials)

My biggest client has 4500VMs on NFS, but none of my other clients run NFS at all and none are contemplating it.

[kmcferrin]

xhmtk1976 wrote:

Switching to another platform may cost more in hardware and a migration itself will cost money but it may also save money in the long run.  That's up to each for his own to decide.  For most of our customers the scenario would probably be comparable to changing tires.  Keep using them until they need to be replaced and then see what's the best value on the market.

There you go.  "cmangiarelli" likes to paint a picture of some tremendous expense with switching everything over at once.  Very few shops would ever consider that kind of migration.  Instead they are far more likely (as indicated previously numerous times in this thread) to stay with 4.1 for existing infrastructure and target new deployments for a less costly competitor, then migrate the legacy systems when the hardware needs refreshed.  If you do this then not only will you save money on licensing going from 4.1 to 5.0, but you would be able to avoid the inevitable price increase when they roll out the next version of vSphere (6? 7? 8?).

[kmcferrin]

Bigi wrote:

3. No one is forcing people to upgrade to vSphere 5.x you can stay on 4. Why are people going nuts with going to Hyper-V or Xen just because they dont like the newest version licensing model. How do you know Xen or Microsoft will not upgrade their policy.

Because VMware already made them buy SnS with their 4.1 licenses and touted it as a way to get rights to upgrade to the next version at no cost.  If they've already paid for the upgrade they should certainly get to use it, right?

[kmcferrin]

Bigi wrote:

@ allenb1121

if 48 cores and 512GB of ram is not extreme I dont know what is.Your living in fantasy world. In your case stick with vSphere 4 no one is forcing people to upgrade. Updates and bug fixes will still be provided for version 4 even 3.5 still gets updates.

Sounds to me like you have a Server sprawl. How many physical sockets per server are you counting HT as well?

Sounds to me like you haven't worked in an enterprise environment.  I was deploying blades with 16 cores and 128 GB of RAM 3 years ago.  Having 48 cores and 512 GB today isn't even keeping pace with Moore's law.  When you work for an organization with thousands of servers and tens of thousands of users, you build at this scale.  What you think of as extreme might be considered extreme for a $40 million company, but it's very common for companies that are Fortune 1000 sized.

[ClueShell]

Please read carefully

http://www.vmware.com/download/eula/

Especially

http://www.vmware.com/files/pdf/Upgrade_Policy_Final.pdf

There is this

1. Functionality Upgrades: Upgrade from a product with “lesser” functionality to a product
with a richer feature-set that includes the functionality of the “lesser” product.

Basis: All upgrades are executed on a 1:1 basis only. In other words, customer may upgrade
from one Original License to one Replacement License.

Products: Functionality Upgrades are available for a select subset of VMware products.
Functionality Upgrades require that the Replacement License at least contain all of the
functionality of the Original License.

So plain simple - physical RAM was capped at 256 GB or even unlimited with EntPlus.

VMware has to provide a full replacement for this license anything contrary was breach of contract.

and this

http://www.vmware.com/download/eula/multicore.html

As the core density per processor increases, customers may want to  deploy their VMware software products on Processors which have more  cores than their entitlement permits. Customers in these situations have  two options:

1) Upgrade to a different VMware software edition with higher core  per processor entitlements, sufficient for number of cores on their  processor OR

2) Combine multiple VMware software licenses on a single host.  Licensing Policy allows combining licenses of same software on single  processor.

Example: A customer has previously purchased vSphere  Enterprise licenses. Recall that each vSphere Enterprise license may be  deployed on a processor with up to 6 cores. However, the customer now  wants to use these licenses on a newly acquired server that has  processor with 12 cores. The customer has two options:

1. Upgrade the vSphere Enterprise license to vSphere Enterprise Plus, which provides a 12-core entitlement and additional OR
2. Use two (2) vSphere Enterprise licenses for each processor with 12 cores.

still they had the "future" problem.

How does this policy affect my licensing costs on servers with more than 12 cores per processor?

Though VMware Licensing Policy allows combining licenses of  same software on a single host, we are reviewing the Licensing Policy  and feasibility as x86 processors with greater number of cores become  available.

So here it goes. For the edition we pay for features. If the boxes get bigger and bigger you have other problems like I/O - Disk / Network whatever.

And VMware gets the cash for 12+ core machines since you'd have to buy multiples of your original core counts.

I guess this licensing is "uncool" for the Fortune 100 or whatever VMware asked in the first place. Because as 16 and 20 core CPUs come to market those companies would need to double up their license count. BUT those companies can afford it, they do charge back, etc.

[J1mbo]

Note line 3 - "Please note that this policy is subject to change without notice." :smileycry:

[ClueShell]

Oh come on thats written in every EULA out there. Thats such a blanked excuse its unenforcable if its a 180 degree turn in business practices.

[bobbach]

I know that it may not be popular, but I would still stand behind a core based model. Charge us based on something like 4 core increments for new purchases and the vSphere 5 licensing takes current core counts as the baseline. Done, simple, follows the way its been done in the past.

That would address VMware's concern about ever more cores in processors and still allow us to manage our environments and purchases. It would cut out the stupid shut down all of your VMs over the weekend scenarios we are dreaming up, and it would allow us to give memory to apps that need it due to poor code, or DB caching, whatever.

Again I don't expect a free lunch with 5. What I do expect is to keep the ability to predict costs, manage the envirnment and continue to service new technologies alongside legacy systems.