VMware Cloud Community
SuperSpike
Contributor
Contributor

vSphere 5 Licensing

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?

@Virtual_EZ
Reply
0 Kudos
1,980 Replies
JustinL3
Contributor
Contributor

One thing I haven't seen mentioned yet in this post is the topic of memory limits on a VM.  I asked our SE if I had a VM allocated 6GB vRAM, but had a memory limit of 4GB applied to the same VM, what my vRAM usage would be.  Guess what the answer was.....6.  So, I have a VM that can only use 4GB of vRAM based on the limit I set; but it consumes 6GB worth of my vRAM allocation.  This whole money making scheme is very frustrating.

As I've thought about this new model of licensing based on vRAM I can see why they choose to base it on vRAM, but I think their scale is outdated.  It should be based on:

1 - Either a more realistic vRAM/CPU allocation; say 128GB/CPU for ENT+ (48GB/CPU for a 12 or 16 core system is nothing, and that's at today’s hardware levels).

2 - vRAM utilized, not allocated.  Why should VMware be deciding we can't over allocate RAM to a VM (that's one of their selling points)?  If I'm running "My Cloud", and I want to buy a server with 512GB of RAM in it and over allocate my VMs by 25% to account for increased workloads, or pacify a pesky developer; that should be my business.

I'm getting sick if the line from VMware that we need to right size our VMs and they trying to sell us CapIQ to find oversized VMs.  I can find oversized VMs myself; but I can't just push a magic button and right size 100's of VMs; there is change control, business buy in, and the perceived notion that my VM is running slower now because you took 1GB of RAM away from me.  Not to mention the user who says, hey RAM is cheap, why do you need to take 1GB of RAM from my VM?

In a small environment with say 50 VMs it's not hard to deploy and maintain a VM that's right sized within a few 100MB.

In an environment with 2000+ VMs, and active virtualization project, a move from Sparc to x86 _NIX, an active internal cloud initiative and a majority of LOB apps running virtualized, it's not practical to up/downsize VMs based on their workload cycles to try and manage to an unrealistic vRAM allocated licensing limit.   Not to mention it's disruptive.  We have a hard time getting buy in from the business to take a test/dev VM down, much less a production VM.

Reply
0 Kudos
SuperSpike
Contributor
Contributor

Alberto wrote:

SuperSpike, thanks for commenting and expressing your concerns. At first sight it seems that you are missing some very key points about the model that can end up affecting the end result:

1) vRAM entitlements are pooled across the whole enviroment, therefore when you do the math you shouldn't focus on one or two servers, but your whole environment. This can radically change the end result. Here is a good example from a customer that was just as shocked as you are and then ran the numbers: http://lonesysadmin.net/2011/07/12/the-five-stages-of-vmware-licensing-grief/

2) the vast majority of people overpovision CPUs and physcial RAM for HA purposes. I don't know about your enviroment, but I'd be surprised if you didn't do that with such large servers running many VMs. With the new model essentially you don't have to license that capacity

3) While core limits are not an issue today if you are running Ent + (they certainly are an issue today is you use Enterprise), within 12-18 months under the vSphere 4.x you will have to deploy to two licenses per processor with the additional negative factor that you won't be able to share core entitlements among hosts

4) To run a 1TB VM you probably need a 16 sockets server with 1TB RAM. This means that the incremental cost would be about 6 licenses since each socket has to have at least one license and we are not even factoring in any spare vRAM capacity you may have in your pool. Looking at prices for hardware like the one above, it seems that the HW alone would cost over $150K, so I am not sure that virtualization software would end up being the most expensive component of the solution

5) vSphere licenses are perpetual so if you are refreshing your existing vSphere environement with new larger boxes you can redepoly your existing licenses to the new boxes just to expand the pool

Look I don't mean to sugarcoat it to you, but I think you should really run the numbers first to determine if you are impacted. Looking at the configs of latest purchased servers may lead to very wrong conclusions as we are seeing in many cases. We will soon make available a free utility app to check possible impacts of the new model on your environment - I'll post the link as soon as it's out. Hopefully it will help provide more clarity and please let us know what you find out.

Alberto,

1) I acknowledged vRAM pooling in the very first post in this thread when I created it. It doesn't matter, especially if a) you use blades and b) you have VMs with high memory requirements.

2) Again, I don't know where some people get the idea that we're all made of money and over-provisioning resources intentionally. As I've stated in other posts within this thread, I push back on just about every request I receive. I scrutinize, I analyze, I ask for documentation. The VMs are sized correctly. When VMware did their very first virtualization assessment for this company, they came back showing we are way above the industry average in terms of memory utilization. We use a ton of Java.

3) When I started analyzing the vSphere 5 changes yesterday, I fully expected to find a fancy new matrix of all vSphere 5 editions. The first thing I wanted to see was if they had raised the per CPU socket core count. I would have been fine with this. When vSphere 4 came out and Enterprise Plus had a 12 core limit, it wasn't a problem because 12 core CPUs were not even on the market yet. Even today as an HP shop, there are only a couple of 12-core options available. I would have welcomed a continued (albeit modified for 16 core) vSphere 4 licensing model. It made sense. It worked. It gave customers a lot of flexibility and forced you to choose your edition based (mostly) on features - NOT on the physical config of your hardware.

4) I am surprised anyone out there is arguing against this point. It's just silly. Have you taken a look at major sever hardware vendor models? They are quickly approaching 1TB with a 4 socket model. Take a look at the HP DL580 G7. 2TB maximum memory. 4 CPU sockets. That's it. So let's do the math. I obviously need to license 4 physical CPU sockets - that's fine. Assuming Enterprise Plus, that means I can use a fraction of it with just a 192G vRAM entitlement. So if I want to spin up that bad boy 1TB VM? Guess what? Well I need ((1024G - 192G) / 48G) 17 (18 if you round up) more Enteprise plus licenses. Wow that 1TB VM just got really expensive! Why virtualize it? I already have the bare metal with enough memory anyway, so why take on the 21 (22 if you round up) license cost? That's nearly $77,000 in software, and you haven't even paid for the SNS yet!

5) I think you mean that if you already have an ELA with VMware that you'll be covered and not subject to these silly vRAM entitlement limits. If my sources are correct, I believe that to be true. It doesn't change the fact that when those ELAs expire and/or we need to buy more licenses, we're going to get hit hard. I can't imagine what the SMB guys are going through. You can't find ROI in virtualization anymore using this model.

I've already run the script provided by peetersonline.nl. While he is a very talented PowerCLI scripter, the script assumes that you're running all of your hosts at full load today, rather than preparing for where you want to be tomorrow.

I will tell you that it seems the more density you're striving for, the harder you're going to get hit.

Let's run some real-world numbers while we're on the topic.

3 data centers

Each data center has (32) 2-socket blades with 192G of memory. That's 96 blades.

Each data center has (4) 8-node clusters, with HA configured to tolerate 1 host failure. That's 12 hosts out of the picture for HA.

(96*192G) - (12*192G) = 16,128G of vRAM available for allocation to VMs

Let's add it up before we move on

96 hosts x 2 CPU sockets = 192 physical CPU sockets

192 sockets * 48G Enterprise Plus vRAM entitlements = 9216G that I can assign to VMs

Wait a second?

16,128G of vRAM available for allocation to VMs (remember, we already calculated for HA)

9216G of vRAM entitlements that I can assign to VMs based on my licensing.

That's less than 50% of the RAM I bought and intended to use.

16,128G - 9,216G = 6912G left to license

6912G / 48G = 144 Enterprise Plus vRAM entitlements to buy*

*Also known as a cool half million dollars.

Go over my math. Pick apart my strategy. Tell me this isn't a good hardware model for "cloud computing." 192G per host in a 2-socket footprint is not an odd-ball config. A lot of the guys on here have way more than that stuffed into a half height blade.

@Virtual_EZ
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Actually my response is that you need to do the math across your entire environment as part of upgrade planning. If you are 100% rightsized, and you are allocating 192G per node with only 2 sockets per node. Then this is just the case we were discussing after the VMware COmmunities Podcast. In this case, I would absolutely agree that there is an issue.
But I was a bit concerned and ran the numbers across my entire environment. I was pleasantly surprised others may not be pleasantly surprised.
Is this the right move by VMware, not sure, is this something that will impact many customers, absolutely. THose who are service providers would be impacted the most but they use a different licensing scheme that is today based off memory and has been since 4.0 was released.
I personally hope VMware changes this to at least 64GB entitlement per proc for Ent+. If this happens you have more elbow room. Perhaps increase each entitlement by 8-16GBs each would alleviate many of these issues across entire sites. Or perhaps offer some other sort of license for dense environments.
Assuming you use all the RAM in your nodes, I would also assume you have spare nodes to run these VMs during an HA event, in that case those spare nodes also become part of your vRAM pool.  Those spare nodes may alleviate some of the vRAM pool issues as well. What about those nodes sitting at a hot-site not running anything? They may also become part of your vRAM pool.  Is the pool per cluster or per vCenter as well? I would hlpe per vCenter (federated as well).
There is plenty still to clarify here of what is considered part of your vRAM pool.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
MKguy
Virtuoso
Virtuoso

What is Xen or Hyper V's answer to SRM, vCD, vCO etc etc.

Who said we need or even want these products in the first place? And do you know how much more money goes from customers to VMwares pockets for each of these separate products? For some like vCD, we also need Enterprise+ to even use them properly.

Sorry, but many of us are not riding the cloud bandwagon VMware has been buzzing about recently.

Your efforts at brushing this whole debate off as "too emotional" when dozens of users present their real-world examples are just laughable at best.

VMware, I am disappoint.

-- http://alpacapowered.wordpress.com
Reply
0 Kudos
DSTAVERT
Immortal
Immortal

This isn't defending the model it is suggesting the angry mob put down the rope. The reactions are just emotional and people need to look closely at what the real impact actually is across the complete infrastructure. Not with simple calculations proposed by others but a careful analysis with actual numbers. Make sure you have read and thoroughy understood the change.

-- David -- VMware Communities Moderator
Reply
0 Kudos
mikeyes
Enthusiast
Enthusiast

MKguy wrote:

What is Xen or Hyper V's answer to SRM, vCD, vCO etc etc.

Who said we need or even want these products in the first place? And do you know how much more money goes from customers to VMwares pockets for each of these seperate products? For some like vCD we also need Enterprise+ to even use them properly.

Sorry, but many of us are not riding the cloud bandwagon VMware has been buzzing about the recently.

Your efforts at brushing this whole debate off as "too emotional" when dozens of users present their real-world examples are just laughable at best.

VMware, I am disappoint.

Well said

Reply
0 Kudos
BrendonColby
Contributor
Contributor

1 - Either a more realistic vRAM/CPU allocation; say 128GB/CPU for ENT+ (48GB/CPU for a 12 or 16 core system is nothing, and that's at today’s hardware levels).

I totally agree! We're just a small shop and have HP DL380 G6 servers from 2009, and they have 192GB capacity (we're at 144GB)!

Reply
0 Kudos
fcsjpatterson
Contributor
Contributor

Our main production configuration that we recently purchased and are in the process of implementing are two Bladcenter H chassis with 5 HX5 blades each with MAX5 blades..  320GB each.  Imagine how fun this is going to be for us given the new licensing model?   This, of course, doesn't count our Std and Enterprise Plus configurations in other offices.  What a fine mess they've made..  At least have "Memory Pack" options you can purchase or something somewhat more reasonable than this.  I know the density of servers has increased exponentially since the initial licensing model was put out for VMWare, but c'mon people.. there has to be a better option.  I'd hate to have to jump ship after drinking the VMWare koolaid for so many years.  What you're proposing really "sticks it" to your Enterprise (ie: your BIGGEST) customers.

Reply
0 Kudos
mikeyes
Enthusiast
Enthusiast

DSTAVERT wrote:

This isn't defending the model it is suggesting the angry mob put down the rope. The reactions are just emotional and people need to look closely at what the real impact actually is across the complete infrastructure. Not with simple calculations proposed by others but a careful analysis with actual numbers. Make sure you have read and thoroughy understood the change.

After the angry mob puts down the rope they will still find that they will need to pay more in license costs.  It doesn't matter what you are using today or how under/over sized your environment is.

HOW IS THIS GOOD IN ANY WAY.  There is no BENEFIT here.  This new licensing model adds cost but doesn't give the customer anything.  Making an argument that the pain won't be as bad as we think and we should be thankful for that still doesn't answer the question of what we the customer get for going through ANY pain.

Scenario:

I have a 2CPU box with 192GB of RAM on VSphere 4.  I own 2 ent+ licenses.  I am only consuming 80GB of RAM.

Wow this change doesn't affect me at all.  I can breath so easy now.

After I upgrade to 5 and pass the 96GB limit now a box pops up telling me to call VMware and pay more money.  CRAP

It doesn't matter how much it affects us today.  The price just went up by a HUGE amount and there was no benefit!!!!!!!!!!!!!

Reply
0 Kudos
Full_Halsey
Contributor
Contributor

DSTAVERT wrote:

This isn't defending the model it is suggesting the angry mob put down the rope. The reactions are just emotional and people need to look closely at what the real impact actually is across the complete infrastructure. Not with simple calculations proposed by others but a careful analysis with actual numbers. Make sure you have read and thoroughy understood the change.

I am trying to ask an intelligent question to which I would like an answer to. My scenario, along with many others indicates at minimum, a doubling of licensing. No anger involved and I haven't seen any name calling. I have run the numbers and it does not look good. Just because someone disagrees with your assessment is no reason for you to get angry and get emotional. Stay calm, take a deep breathe, like I did and it will be all good. Smiley Happy

Reply
0 Kudos
Frank_Heidbuche
Contributor
Contributor

stop telling us we are emotional...

we are emotional because we are not being heard

you keep telling use real word examples...

guy we keep giving you real world examples...

i ran the Powershell script against my last designs of the last 6 months.

so i have real world examples.

not even all enviroments are fully 100% operational with all VM's on it.

not ONE of my design kept the same license price...

NOT ONE.

i just see a lot of 48Gb and 72GB per CPU statements...

WHO THE HECK BUY THESE SERVERS.

man i feel frustrated...

Reply
0 Kudos
cvbarney
Enthusiast
Enthusiast

OMG, are you keep repeating?

If it doesn't hurt right now it will hurt in the near future where servers become bigger (256GB+) and VM's more memory consuming.

You can repeat: DO THE MATH. People with low utilisation will think: hey, everything is fine. Last year the have invest in a nice upscaled environment (256GB servers) and now 40% is in use. After a couple of months, upgraded to vSphere5, the utilisation increase and vCenter alerts you have no vRAM anymore. Go to your boss (or customer) and say: you have to invest, otherwise we can't use the other resources in our cluster. Boss (or customer) said: but I've invest last year en now I've no IT budget...

And maybe you have to look in the future, not only at THIS moment (what you keep repeating). That will make you a good consultant. What does it cost to license a server next year if 396 or 512 GB is a common configuration and VMware still reside on the 48GB/CPU license?

Reply
0 Kudos
embusa
Contributor
Contributor

At the end of the day a more palatable approach would be a reasonable allotment of RAM per cpu and the ability to buy vRAM packs commenserate with the license version you're running.  I understand paying for what you use, and "get" the model, but the initial allocations just aren't reasonable or in line with today's standards.

Reply
0 Kudos
SeanLeyne
Contributor
Contributor

According to a newsletter (http://blogs.softchoice.com/advisor/2011/07/12/big-changes-in-licensing-model-for-vmware-vsphere-5-v...) from SoftChoice (a VMware retail/distributor partner), It seems that there may be an out (if you don't need any of the new v5 features):

After the official release, previous versions of VMware or vSphere will no longer be available for purchase.  If you are looking for additional licenses for your environment and running a previous version you will have downgrade rights as long as you have active support.  If you downgrade you will also be required to follow the present licensing model in VMware vSphere 4.1.


My questions will be:

Do the "downgrade rights" extend to the licenses upgraded via SnS? (The article refers only to new licenses)

What is impact on future upgrades of using "downgrade rights"?

Reply
0 Kudos
aarondovetail
Contributor
Contributor

True, forcing Essentials Plus customers to upgrade to Standard just to get more vRAM is pretty retarded especially given the huge price jump. I have 3 servers with Essentials Plus and just very recently started looking at upgrading even more RAM to stick with this license level and keep costs down

Reply
0 Kudos
ArtIW
Contributor
Contributor

I just posted this story, mostly based on the discussion here: http://informationweek.com/news/software/operating_systems/231001638

Art

Reply
0 Kudos
SeanLeyne
Contributor
Contributor

embusa wrote:

At the end of the day a more palatable approach would be a reasonable allotment of RAM per cpu and the ability to buy vRAM packs commenserate with the license version you're running.  I understand paying for what you use, and "get" the model, but the initial allocations just aren't reasonable or in line with today's standards.

  1. I would support the idea of having to pay $$$$ for more RAM support -- offer new "memory" pack SKUs which provide for 32, 64, 128, 512 and 1TB increments -- without the need for SnS (or at least a rate which is 5% of license fee, not 20% for "product" functionality). Also, memory pack should be fixed price, regardless of ESX product level. Product level is about feature set, it is not about how I am managing my VMs/hosts.
  2. I don't believe, however, that licensing based on "allocated" memory is correct -- "used" is much more approapriate.
  3. The current memory levels need to be doubled (if based on used) or trippled (if vRAM). The current levels are an insult to all users and go against everything that VMware has been espousing for the last 5 years (density, density, density).
Reply
0 Kudos
stevieg
Enthusiast
Enthusiast

Agree with other posters, there is no reason to get emotional about this or get an "angry mob" mentality, and for most of the posters here there is no emotional side or anger, just a little bit of frustration.

We know we can move to a different vendor, we just don't *want* to. many of us either sell to customers or sell to management VMware as the best solution and have used it's advantages against it's competitors to justify it's high costs.We don't want to have to either ask for more money or lead a project to migrate to a different platform. The frustration comes in from the comments from those giving repeated examples about these sub 100GB hosts many of us have been actively working to eradicate and replace with 200GB+ hosts.

To counter the "what else has vCD, SRM, vCO" - yes it is true VMware has some great software. But don't forget Microsoft isn't far behind with SCVMM 2012, Opalis, and even the replication features announced for Win Server 8's Hyper-V; not only that, third party vendors are planning Hyper-V support in products like Veeam, Embotics and others. We know we don't have to move away now, and can also see that if we look to move gradually in the next 12 months the marketplace will have changed and closed the gap.

This isn't the first time we've dealt with vendors who consider their product absolutely irreplacable and feel they have a captive market so think they can raise costs and we'll just pay it. We've dealt with this from Novell, Oracle, Shavlik just to name a few. The solution *is* to threaten to part ways and if they don't bend to what we require, we go.

Much like the IT bod who believes he's irreplacable and plays the diva, we're often better off without them. Novell and Shavlik were shown the door and Oracle bent. But our relationship with Oracle was ruined, and we've slowly replaced their databases with SQL Server at opportune times with the intention of dropping them entirely. Shockingly the only vendor we find very hard to replace wholesale is Microsoft, and they have never tried anything like this on with us - if anything we keep on getting more for our money.

I feel that this new licencing model does more to damage our trust in VMware than the impact of the licensing changes themselves. We know day one it's not going to cost us more, but it will cost money we were not prepared to spend going forward. The mistake VMware made was not understanding that the technology will eventually be a commodity (I thought they "got it" based on the diverse aquisitions - obviously not) and the Hypervisor feature set and pricing needs to be lower, not higher; especially with only Enterprise Plus benefitting from innovation.

Steve

Reply
0 Kudos
DSTAVERT
Immortal
Immortal

Have a look here

http://virtualisedreality.com/2011/07/13/understanding-vsphere5-licensing/

-- David -- VMware Communities Moderator
Reply
0 Kudos
SuperSpike
Contributor
Contributor

DSTAVERT wrote:

Perhaps it's time to dust off those Windows 2003 licenses or demand more RAM efficient OS's and applications.

For the record, the majority of my VMs with large memory requirements are Linux. Oddly enough, the biggest ones are for running the SpringSource stack (particularly vFabric), which just happens to be owned by...VMware.

@Virtual_EZ
Reply
0 Kudos