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?

[s1xth]

Licensing will stay the same under 4.1 The new licensing is for 5.0 only going forward.

[cvbarney]

sergeadam wrote:

Question is, how are they going to enforce the memory limit on 4.1?

Where did this come from? Please refer to a source if such rumours are being stated, otherwise it becomes a pointless discussion

This comes from VMware:

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.

PRESENT licensing mode, so license per socket. vRAM is only for vSphere5.

[sergeadam]

cvbarney wrote:

sergeadam wrote:

Question is, how are they going to enforce the memory limit on 4.1?

Where did this come from? Please refer to a source if such rumours are being stated, otherwise it becomes a pointless discussion

This comes from VMware:

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.

PRESENT licensing mode, so license per socket. vRAM is only for vSphere5.

I has been stated many times, along with the 30 days to upgrade.

Glad to see it is not true.

[ftempel]

Did some calculations for my environment again (hey, gotta report to manglement so I better be prepared):

Currently, I'm golden, both in the old and new model. But I don't scale for "currently", I scale for "tomorrow and beyond". I'll be upgrading a couple of servers with double the memory and I'll be adding a few too. In that new scenario, if I keep my memory allocation below 56% (pooled vRAM/pooled pRAM) then I'm  not paying more than I would be in the "old" model. However, things  deteriorate fast from there. At 75% memory allocation (not unreasonable to expect in the  coming few months) the tab is running at 33% price increase already. Say I want to use all pRAM (unlikely, I do actually design at least N+1, preferably N+2) then it's at a  79% price increase over the old model. Granted, not a 100% price hike  but it's getting there. Overcommitting has become exceptionally pricy.

I have to admit, before jumping the gun everyone should run the numbers like suggested before.

Question: Pooled vRAM is only possible for the same edition, but is it possible to still combine editions in the same datacenter? e.g. I've a cluster "Enterprise" and a couple of clusters "Enterprise Plus". I can't throw those two together into a vRAM pool, the Enterprise cluster is a vRAM pool and the Enterprise Plus clusters are a vRAM pool (right?). Please don't tell me I have to upgrade the Enterprise cluster to Enterprise Plus just because they live in the same vCenter datacenter...

Of course I'll be asking this same question to my VAR and VMware, but maybe someone has an idea beforehand.

[wdroush1]

sergeadam wrote:

Mark Hodges wrote:

Overall I think most of us would be totally fine with one of 2 options:

A - tie the licensing to the amount of Physical RAM in the servers and make it a standard increment across the board (128Gb maybe?) with different price points based on the edition (since if someone wants to run 2 servers with local storage and have no HA and load the servers to the walls with VM's..well..all the power to you...when one host falls over, you will probably reconsider your licensing level.  All Incremental increases cost the same.

B - Make it a base license cost per Host w/ first 256Gb vRAM included and then incremental vRAM costs are an incremental price point (say 30% of the full base (since there is no need to put S&S on additional ram).  Base price is determined upon the edition you want.

Even if the base price is a bit higher then now...at least we have more control of costs...and can budget for it easier since we purchase more vmware licenses when we but the physical RAM or buy a new host...

Tie pricing to pRAM. It's something we can explain to management.

Base price host cost with pRAM allocation, I'd say 64GB. Tie it to pCPU if you want. This is what we pay SnS on.

Sell fixed pRAM increments (32 or 64GB), not tied to pCPU, with no SnS.

That would truly minimize the effect on your customers.

Density has nothing to do with edition. I buy an edition based on the features I need. Because Standard licenses are what I need at a location does not mean my VM density will be any less.

I do like the idea of vRAM because it doesn't penalize those that are running Xeon processors or older machines, I just think the allocation needs to be fixed and anything pCPU related taken off the board and the allocation to be aligned with what people are purchasing for brand new hardware, not 4-5 year old machines.

vRAM is extremely easy to explain to management, it's the amount of RAM these machines would have if they were put in racks and we bought RAM for each individual machine.

[sergeadam]

The issue with vRAM, from a technical perspective it's not feasable because we all know that our machines consume less vRAM than we configure them at. I configure servers based on 2 things. Peak usage, which tends to be transient, and app vendor recommendation. I'm currently building a solution that includes a MS SQL server the vendor wants the SQL server to have 32GB RAM. I know from experience that for my anticipated load, it's too much. But I'm not going to fight the app owner or vendor. That used to be the strength of VMWare. The ability to overallocate pRAM because we knew what the actual usage was going to be and satisfy app vendors in the process.

I also spin up servers and environments to test. My latest one is to test and validate a domain rename/merging project. I spun up 5 servers and 3 workstations. 23GB. They sit mostly idle. But I want that RAM to be available when needed. So what do I do with the new model? ask for more $$ for resources that are not real????  

[itoperationsgrh]

So what do I do with the new model? ask for more $$ for resources that are not real????

You have just indicated a very thorough understanding of the new licensing model and its implications.

Yes, the 5.0 licensing model demands that you purchase resources that are not going to be fully realized.

[wdroush1]

sergeadam wrote:

The issue with vRAM, from a technical perspective it's not feasable because we all know that our machines consume less vRAM than we configure them at. I configure servers based on 2 things. Peak usage, which tends to be transient, and app vendor recommendation. I'm currently building a solution that includes a MS SQL server the vendor wants the SQL server to have 32GB RAM. I know from experience that for my anticipated load, it's too much. But I'm not going to fight the app owner or vendor. That used to be the strength of VMWare. The ability to overallocate pRAM because we knew what the actual usage was going to be and satisfy app vendors in the process.

I also spin up servers and environments to test. My latest one is to test and validate a domain rename/merging project. I spun up 5 servers and 3 workstations. 23GB. They sit mostly idle. But I want that RAM to be available when needed. So what do I do with the new model? ask for more $$ for resources that are not real????  

Well remember I'm saying we should align vSphere5 vRAM costs to what it is effectively at now: Enterprise = 256GB/license (the max you can basically get with a modern system, and scale the other respectively).

The biggest point here is regardless, that is the best vRAM allocation you're going to be able to possibly get on a box (AFAIK, do inform me if we have >1TB boards available!).

As for dealing with it from a technical perspective, I think it's easier to be honest, it allows you to think of VMs more as physical boxes when you're talking about license consumption. If it was physical you still need to account for peak and vendor recommendation, and with vRAM you can still over-allocate. I think with more reasonable numbers you wouldn't care about that 23GB test environment, considering to have those extra resources would only cost a few hundred dollars at worst, and is way cheaper than having additional hardware lying around for testing.

I'd actually argue that a really good vRAM model will move a lot of our development/test environments from ESXi frees into licensed vCenter environments.

Also it means that you're not constrained to using the newest and greatest to get the most out of your license, and can reuse old blades and the like (a situation we're running into).

[vin00020]

VMware has obviously played a hard ball this time with licensing - not only that, now the hypervisor ball is so high in cloud that MS-Citrix n(N)exus will grab this apportunity and will do anything to keep the ball off VMware.

Did I see 300+ posts before weekend and now people took their postings off or almost 200+ postings just vanished in cloud along with ball?    

[itoperationsgrh]

Yes, the 5.0 licensing model demands that you purchase resources that are not going to be fully realized

Let’s look at where this licensing model is heading, one of the main strengths of this product is that it applies a form of “Thin Provisioning”, (see definition), to usage of CPU Threads and RAM.

• (Thin provisioning) Thin provisioning is a mechanism that applies to large-scale centralized computer disk storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.
  

en.wikipedia.org/wiki/Thin_provisioning

Because of this the prudent thing to do is always have at least 20% of those resources in reserve to take care of spikes in usage.

The next logical step for version 6.0 is to charge for disk usage; I.e. a per terabyte charge added to the licensing model for 6.0

[wdroush1]

vin00020 wrote:

VMware has obviously played a hard ball this time with licensing - not only that, now the hypervisor ball is so high in cloud that MS-Citrix n(N)exus will grab this apportunity and will do anything to keep the ball off VMware.

Did I see 300+ posts before weekend and now people took their postings off or almost 200+ postings just vanished in cloud along with ball?    

I think it's a bug in the forum software due to us beating this thread todeath or something.

Yeah, it's well beyond 400+ replies.

It could be how it counts replies (as in replies to the OP, not replies to eachother).

[wdroush1]

itoperationsgrhc wrote:

Yes, the 5.0 licensing model demands that you purchase resources that are not going to be fully realized

Let’s look at where this licensing model is heading, one of the main strengths of this product is that it applies a form of “Thin Provisioning”, (see definition), to usage of CPU Threads and RAM.

• (Thin provisioning) Thin provisioning is a mechanism that applies to large-scale centralized computer disk storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.

en.wikipedia.org/wiki/Thin_provisioning

Because of this the prudent thing to do is always have at least 20% of those resources in reserve to take care of spikes in usage.

The next logical step for version 6.0 is to charge for disk usage; I.e. a per terabyte charge added to the licensing model for 6.0

I'm still betting they're going to charge on vIOPs once we basically end up disk thrashing to save on licensing costs.

Or EMC will swoop in and tell us how we can buy their SANs to compensate.

[kcucadmin]

The biggest thing for me, is how this makes me look as a vmware advocate.

I made recommendations last year, on this year and next years growth.  Now those recommendations are completely blown out of the water.  It makes it look like I have no clue what I'm talking about.

Yes we as IT guys have the full faith in Virtualization, but from a business perspective, others were just starting to see the possible upside.  Now that is gone in a blink.

there was a reason Virtualization picked up so much in the last 2 years, because the hardware finally starts to give some scale up that justified the additional VMware costs.  it was not because vsphere 4 added some cool fluffy features.

VMware is a "Want" not a need.  As it was, it took some dancing to convince people to buy the Cadillac instead of the focus.

also, i wonder how your HW partners are taking this.

you basically just killed the UCS from Cisco, why spend all that premium on hardware when now your vmware costs will skyrocket to allocate the vRAM the hardware was so good at handling.

VMware claims they need a model for sustainability.  GROW your customer base, dont GOUGE your current base.  Offer more VAULE and your base will grow.  GOUGE your base and it will shrink.

I'm an IT guy and i didn't need to go to business school to figure that out.

[URDaddy]

Yep, VMWare has REALLY screwed up this time.  Our VMWare is now becoming as expensive as just buying cheap servers to do the job in the first place.  Like you, I have been the VMWare tech-evangelist for the company up until now.  I really don't want to but it looks like I am going to have to look at Microsoft and Citrix for a replacement of VMWare.  Greedy F#####s have just cut their nose off in spite of their face!  

[MrSyslogd]

In our organization, we run a number of four node clusters with SRM.   The day the new license info came out we did the calculations and it does not look good.   Some clusters we are already running at max vRAM limits and others we will need to buy two CPUs per node in a cluster just to cover the vRAM numbers.

Reading the posting on 7/14 by Bogomil Balkansky I will state without a doubt this is just spin without real world facts.   The people posting here do know what they are talking about.  The numbers posted by Mr. Balkansky are massaged to fit their argument.  For 64Bit VMs, 3GB of RAM is far below average.  If you are running 64-bit VMs it is because you need to address more than 4GB per process.  We manage our VMs so we know how much each VM needs to deal with peak and idle requirements.  We set of applications to cache X, to run a heap size of Y.   I am not alone in this.  I rather not go into the specific quotes listed by Forrester or Taneja.  But honestly, who pays attention to Forrester, JD Powers, or any of those pay for play organizations.

It is not that uncommon were people run more than the 5:1 ratio as listed in the licensing PDF just issued (tho Mr. Balkansky listed 5.7:1).  We alone run at common ratio of 20:1, and that is not uncommon in the real world.   I do not want to assume, but for myself and the people I have discussed this with in the past week.  We are not cloud providers, we are not service providers.  We are corporations that work in leveraging VMs to support cost reductions while maintaining performance and, being able to be agile with changing directions. Not everyone drinks the "into the cloud" tainted sugar water.  Not everyone can put their major workloads into some re-badged hosted services offering.   Either remove the restrictions of vRAM for Enterprise and Enterprise Plus customers, or offer vRAM entitlements at a reasonable cost.

An email to our VMWare rep has basicly been a black hole.  Only our reseller has responded, only the reseller showed intrest in our position.  VMWare, not so much.

[wuffers]

Taking the consumption-based model to the extreme, why not do away with licenses and SnS completely? VMWare can just lease the software and charge per hour/day per VM (vRAM/vCPU/HD space) per feature (DRS/vMotion/etc) much like how the vCloud providers are doing (well they aren't doing it by feature.. yet). Production VMs would cost more to run than dev/test VMs for the advanced features, just as an example.

Obviously the cost to run the VMs inhouse has to be much cheaper than getting IaaS from a provider (it's running on your own hardware!) but I believe that could be a viable business model. Less upfront costs for the customer, and a constant revenue stream for VMWare and it really is pay-as-you-go. A monthly bill may make it more palatable instead of a one time large expenditure. If they did the pricing matrix correctly they could probably do something like 50% of customers would cost less to run, 30% about the same, 20% more for their current environment. Of course they would want customers in the lower tiers to consume more and up their usage. This to me is "fairer" than what they've got announced so far (unilateral increase for everyone).

Make it affordable and the customer base will grow. Gouge them and they will walk with their wallet.

http://wuffers.net/2011/07/16/vmware-vsphere-5-licensing-changes-overshadows-new-feature-set

Poll/survey coming later tonight. Probably not SurveyMonkey as the free survey is limited to 100 responses.

[wuffers]

DSeaman wrote:

1. Leave the existing vRAM entitlements for all new v5.0 licenses, BUT with 2-years paid up front S&S double the entitlement, tripple for 3 years of up-front S&S. This encourages business to spend more up front, and commit to VMware over the long haul helping prevent defection to other vendors. Remember XS and Hyper-V will be increasingly feature rich and be more competitive over the next 3 years.

While this could in theory work, you are essentially tying core functionality to maintenance, which I haven't seen any real-world examples. Borrowing the car analogy, that this is like putting a rev limiter on a car, but hey, pay for extended warranty, it gets removed (imagine if they did something like that to say, braking distance.. lol). It also doesn't quite make sense that a purchased license could effectively change into something else once SnS has expired.

[itoperationsgrh]

It is not that uncommon were people run more than the 5:1 ratio as listed in the licensing PDF just issued (tho Mr. Balkansky listed 5.7:1).  We alone run at common ratio of 20:1, and that is not uncommon in the real world.  

We are running 2 clusters

• 6 hosts
  
  • 106 VMs that's 17.66:1
    
• 5 hosts
  
  • 79 VMs that's 15.8:1
    

17 - 18 to 1 is about where the RAM @ 96GB per host hits 75%.  CPU usage averages 15% to 25%

We are in the process of increasing the RAM on 8 of these hosts to 144GB and on 3 of these hosts to 256GB. This should enable us to increase CPU usage on each host.

However this is not sustainable with the 5.0 licensing model, if VMware sticks to their current licensing model we will spend the next year (our licensing expires Fall of 2012) testing alternatives and picking an alternative.

[bilalhashmi]

sergeadam wrote:

Mark Hodges wrote:

Overall I think most of us would be totally fine with one of 2 options:

A - tie the licensing to the amount of Physical RAM in the servers and make it a standard increment across the board (128Gb maybe?) with different price points based on the edition (since if someone wants to run 2 servers with local storage and have no HA and load the servers to the walls with VM's..well..all the power to you...when one host falls over, you will probably reconsider your licensing level.  All Incremental increases cost the same.

B - Make it a base license cost per Host w/ first 256Gb vRAM included and then incremental vRAM costs are an incremental price point (say 30% of the full base (since there is no need to put S&S on additional ram).  Base price is determined upon the edition you want.

Even if the base price is a bit higher then now...at least we have more control of costs...and can budget for it easier since we purchase more vmware licenses when we but the physical RAM or buy a new host...

Tie pricing to pRAM. It's something we can explain to management.

Base price host cost with pRAM allocation, I'd say 64GB. Tie it to pCPU if you want. This is what we pay SnS on.

Sell fixed pRAM increments (32 or 64GB), not tied to pCPU, with no SnS.

That would truly minimize the effect on your customers.

Density has nothing to do with edition. I buy an edition based on the features I need. Because Standard licenses are what I need at a location does not mean my VM density will be any less.

Pricing with pRAM model will be a conflict of interest for VMware. Why would they enhance memory overcommitment in the future if they know they can charge more by forcing users to put in more pRAM in the servers. IMO vRAM is the right approach, however, the entitlements have room for revision.

Follow me @ Cloud-Buddy.com

[bilalhashmi]

JDLangdon wrote:

Why do you insists on using this forum as a means to generate traffic for your personal blog?

I don't. I have ample traffic. I just thought it was appropriate to share something with whats happening in this thread. If my post was precieved differently, I had no such intentions.

Follow me @ Cloud-Buddy.com