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?

[sergeadam]

Overcommitment is also a way to keep the servers compliant with app vendor requirements. We all know that most of our VMs don't use as much RAM as we give them most of the time. But if an app vendor tells me 32GB, that's I give the VM.

VMWare tells us to 'right-size'. But if I just follow their lead, my 2008R2 VMs all have a minimum 4GB RAM. I run Essentials Plus. at 2 X 6 cores per server, that's 5.33 GB per core. that's 1.33 VMs per core.Hardly high density.

[wdroush1]

sergeadam wrote:

Overcommitment is also a way to keep the servers compliant with app vendor requirements. We all know that most of our VMs don't use as much RAM as we give them most of the time. But if an app vendor tells me 32GB, that's I give the VM.

VMWare tells us to 'right-size'. But if I just follow their lead, my 2008R2 VMs all have a minimum 4GB RAM. I run Essentials Plus. at 2 X 6 cores per server, that's 5.33 GB per core. that's 1.33 VMs per core.Hardly high density.

It's pretty much the only way. I can't believe they told us to "right-size" anything, if right-sizing makes me fall out of vendor specs they'll drop support. 

[Dracolith]

Duncan wrote:

overcommitment savings is more than "licenses". what about the cost of hardware? what about the cost of management? what about the cost of network / storage I/O ports? it is not worthless, far from!

Actually:   You're missing that the increase in license cost can overwhelm the hardware cost savings.

whether overcommit saves in cost is a function of the  cost of physical RAM per GB    VS  the  cost of vRAM per GB.

That is the ratio  of    cost per pRAM GB divided by   cost per vRAM GB.

If the number is greater than 1,   then  overcommit is beneficial,   if the number is less than 1, then

it is more sensible to choose  a Hypervisor that does not charge for vRAM  than one that provides overcommit.

Example scenario,  let's say you have a server   that  has    32 DIMM slots   and  2 CPU sockets,

and it can accomadate 8GB, 16GB,  and 32GB DIMMs,   for a maximum possible capacity of  1TB of RAM.

To start out,  you populate it with   2  6-core CPUs and  16  16GB modules, for a total of  256gb RAM,

at a cost of approximately $9000  for the RAM.

Running Enterprise+,     The number of licenses required is  3 licenses, and the vRAM licensed is 288gb.

Let's say  24 months later,    the price of 16gb DIMMs has dropped from  $562  to   $200,  and now 32gb DIMMs are available for $400.

Your organization has started an upgrade project.   You need  new virtual machines, which will use  64GB more of RAM,

for a new total utilization of   320gb.

cost per pRAM GB  (16gb DIMM)  =   200 / 16 = $12.50/pGB

cost per vRAM GB (vmware 1 cpu enterprise+) =  $4500 / 96gb  =    $47 / vGB

pGB / vGB =    0.26     (which is  < 1.0)

Consider the two scenarios:

(1)  You picked the 'cheap'  brand X per-server/per-CPU licensed competitor with no memory overcommit feature.

      Your additional cost for this vRAM capacity will be     $800     for  2 additional 16gb DIMMs  (2x$400),  to increase total pRAM

       to 320gb.

(2)  You picked VMware vSphere.

       Your additional cost for this  vRAM  will be    $4500  for an   additional Enterprise+ license.

       You will be overcommitting  64gb  or  20%   of your memory,  at this cost,   which will have a performance impact.

       In reality, such a high amount of overcommit is not really safe,  so you will be buying 2 additional 16gb DIMMs

       6 months later, at an additional cost of approximately  $400.

So you spent more for your incrementally added capacity with LESS  system performance to show for it.

Guess which IT manager will get the bigger bonus, the one who proudly shows senior management, he put the company

in scenario (2),  or the one that shows he avoided some serious pitfalls and put the company in scenario (1),  saving

the company hundreds of thousands  when multiplied across the entire new deployments?

[wdroush1]

Dracolith wrote:

That is the ratio  of    cost per pRAM GB divided by   cost per vRAM GB.

If the number is greater than 1,   then  overcommit is beneficial,   if the number is less than 1, then

it is more sensible to choose  a Hypervisor that does not charge for vRAM  than one that provides overcommit.

But remember: I'm leveraging CPU and lessening VM performance drastically to overcommit (or at least risk it), memory is cheap, the only reason overcommit was good was to save on licensing a whole other box, that situation doesn't exist anymore.... If I have to go bug accounting because I need to drag some sliders in VMWare, you might as well go with another hypervisor (which most of VMWare's competitors are going to have or already have overcommit, XenServer, Xen, KVM have it, Hyper-V should have it next version).

[LucasAlbers]

I can't find any indication that either xenserver or hyperv-3 will have TPS in the next version.

They both poo-pah the feature.

[Dracolith]

LucasAlbers wrote:

I can't find any indication that either xenserver or hyperv-3 will have TPS in the next version.

They both poo-pah the feature.

Page sharing among  HVM  domUs is a feature of the Xen 4.0 kernel.

The Xen product you refer to is based on a Xen 3  kernel.

I believe they promised the next major release would be based on the Xen 4 kernel.

Page sharing becomes less relevant though,   with Windows 2008  that uses  large 8KB pages for the performance

advantages.      With the move of guest OSes to large pages, TPS offers a rapidly diminishing amount of savings.

Vsphere5  SSD  cache  and Memory compression technologies are more interesting overcommit methods.

[LucasAlbers]

Xenserver 4.1 indicates this feature is of a beta quality, although it is nice to hear they are coming out with TPS.

"Fixes to xenpaging and memory sharing, but they are still considered as 'Tech Previews'."

I looked all over the internet a few days ago and could not find mention of this feature.

Back to an earlier point,

I am going to take vmware's side for a moment.

Consider what a normal customer can run on their box with the current 4.1 license scheme in 2011.

(For the sake of argument.)

year	RAM	sockets	cores	VMS	licenses	Lines of code	complexity
2011	256	2	24	64	2	X million
2013	512	2	48	128	2
2015	1024	2	96	256	2
2017	2048	2	192	512	2
2019	4096	2	384	1024	2	a lot more	a lot more

Consider what a customer can run on a box in 2019, is it fair to only buy two licenses?

Wouldn't this require more engineering hours to develop?

Isn't it a lot harder to build a hypervisor that can manage this number of cores and vms?

Would you say software that can manage 384 vm's is worth more than one that can manage 64?

[Rumple]

Consider what a customer can run on a box in 2019, is it fair to only buy two licenses?

Consider that a year ago you are buying hard drives, video cards, CPU’s, operating systems at the exact same price and are getting more then 2x the performance, space or utilization out of them do you really think its fair or sustainable to continue to charge your clients 2x increase every year?

Its called Moore’s law…see post #1

[sergeadam]

There are some basic assumptions here that are wrong.

- once the memory management code is there, it does not grow in complexity as memory grows.

- There is a limit on how many VMs can be put on a host, mostly for disaster recovery. If I have 50 physical servers, and they can all fit in one host, I'll still likely get 2 hosts with HA. When  refresh my hardware I'll still get 2 hosts. I may run single socket, but then again by that time the nase OS will require more computing power still requiring 2 cores.

If you read the thread, you'll find a number of us have acknowledged that the current licensing model may not be sustainable in the long run. But even that is debatable, since a bulk of the revenue should come from SnS. If VMWare increases sale price, therefore SnS yearly to keep pace with inflation and additional costs, they still make a profit.

Our main argument has centered around a few things.

- Licensing vAnything does not work in a non-chargeback model and punishes those of us who have followed VMWare's directive towards high dendity, scaleup model.

- RAM allocations tied to edition is punitive. We base our choice of edition on a list of needed features.

- Several models have been proposed:

     - Socket + pRAM allocation. Price varies by edition. SnS is based on this. pRAM packs available, not subject to SnS

     - Core. Can this change in the future? of course but is a sendible way right now.

The consessus from the community centeres around the predictability of licensing on physical hardware. If I have to pay for the memory overallocation feature then effectively i can't really use that feature. I might as well get a hypervisor that is cheaper even if I can't overallocate memory.

[kmcferrin]

wdroush1 wrote:

If I have to go bug accounting because I need to drag some sliders in VMWare, you might as well go with another hypervisor (which most of VMWare's competitors are going to have or already have overcommit, XenServer, Xen, KVM have it, Hyper-V should have it next version).

Assuming that you are referring to Xen's "Dynamic Memory Control", Hyper-V already has it in their current release (SP1).

[GaryHertz]

LucasAlbers wrote:

I am going to take vmware's side for a moment.

Consider what a normal customer can run on their box with the current 4.1 license scheme in 2011.

(For the sake of argument.)

year	RAM	sockets	cores	VMS	licenses	Lines of code	complexity
2011	256	2	24	64	2	X million
2013	512	2	48	128	2
2015	1024	2	96	256	2
2017	2048	2	192	512	2
2019	4096	2	384	1024	2	a lot more	a lot more

Consider what a customer can run on a box in 2019, is it fair to only buy two licenses?

Wouldn't this require more engineering hours to develop?

Isn't it a lot harder to build a hypervisor that can manage this number of cores and vms?

Would you say software that can manage 384 vm's is worth more than one that can manage 64?

I hate to sound like a broken record on this but I think it is important to kill this myth.

The only argument that I am hearing for vRAM is future increases in core density.  The 4.1 license model already addresses that.  Advanced and Enterprise+ allows for 12 cores per processor under 4.1. All other versions allow for 6 cores. That 384 core processor will require 32 or 64 licenses not 2.

Please stop using this as a reason to go to vRAM.  Whatever the reasoning was behind the change it wasn't core density.  Or on the other hand maybe it was.  Considering the extremely low initial vRAM entitlements and the number of well educated people that use core density as the reason, I wouldn't be surprised if VMware doesn't know that 4.1 licensing already addresses this

[RogerThomas]

LucasAlbers wrote:

Xenserver 4.1 indicates this feature is of a beta quality, although it is nice to hear they are coming out with TPS.

"Fixes to xenpaging and memory sharing, but they are still considered as 'Tech Previews'."

I looked all over the internet a few days ago and could not find mention of this feature.

Back to an earlier point,

I am going to take vmware's side for a moment.

Consider what a normal customer can run on their box with the current 4.1 license scheme in 2011.

(For the sake of argument.)

year	RAM	sockets	cores	VMS	licenses	Lines of code	complexity
2011	256	2	24	64	2	X million
2013	512	2	48	128	2
2015	1024	2	96	256	2
2017	2048	2	192	512	2
2019	4096	2	384	1024	2	a lot more	a lot more

Consider what a customer can run on a box in 2019, is it fair to only buy two licenses?

Wouldn't this require more engineering hours to develop?

Isn't it a lot harder to build a hypervisor that can manage this number of cores and vms?

Would you say software that can manage 384 vm's is worth more than one that can manage 64?

Using that logic we can expect the providers of the hardware (CPUs, Memory, disks etc) and the providers of all the software we need to install (OSs, applications etc) to apply the same idea. So we can expect them all to be charging far more in the future than they do today as all their products will be more complex. or do you think that VMWARE should be the only one to profit from Moore's Law? The reality is VMWARE is already profiting from Moore's Law as it is deployed in many sites because the hardware has already gone beyond the requirements of single server installs, so companies now consolidate.

As it is VMWARE are now trying to increase my costs by a factor of 20x as I have large amounts of RAM assigned to 3 simple VMWARE systems that include 3 database servers with 96GByte of RAM each. These systems have need to go beyond the dual quad core CPUs currently installed. The RAM is installed because it is/was cheaper than adding faster disk sub-systems, but now it's cheaper for me to install Fusion-IO SSD cards or even dedicated database servers than pay VMWARE's new licensing!

[bobbach]

After a great deal of reading the licensing, pondering where memory footprints are headed and going through several models of where our environment is headed during the period that will be covered by vSphere 5 I have decided to shut my mouth.

Will the new licensing impact us? Yes. Not this year, likely not next year, by year three it will and that makes us the poster child for VMware's conundrum.

We've had Enterprise Plus licensing since vSphere 4 came out. We will likely ride out vSphere 5 in the same socket footprint, while 2x, 3x or even 5x to 6x the memory. As saturation is reached in virtualization penetration, which will be coming soon, VMware needs to put a reasonable method of continued stable and growing revenue in place.

The feature set is certainly better than any of the competitors. The efficiencies are made evident when you read the documentation for software that supports multiple platforms. One of our critical applications supports VMware and Hyper-V, only under Hyper-V they support half the number of users on equivalent hardware. That combined with SMP FT and the new disk features of vSphere 5 make this an easy decision for our organization.

In several post I was adamant that we would have an increased management and usability issue. Given the price of physical RAM we will simply have to buy and license it up front. I realize not every organization can do this, but we can and will. It is cheaper to buy and license than to worry about oversubscribing and growing servers.

As a barrier to entry, the new licensing model should not be to bad either. If consultants and resellers take an honest look at the value inherent in the feature set, and sell customers what they need for their pilots or initial deployments VMware is still the same value it ever was at the entry level. Even testing under the free version of ESXi is viable now that the memory limits have been increased. The free version is even viable for a home test dev platform.

I still wish that the metric wasn't necessary, it is something else to be aware of and It could be a barrier to bringing large memory footprint servers in.

VMware should also still look at how FT is factored into vRAM utilization for licensing purposes.

Lastly, I also hope that there is a more economical partner model for larger external cloud environments so that we can continue to move toward large, affordable clouds for SMBs to move to.

VMware is still the best out there.

[J1mbo]

On the licensing update yesterday, reasoning for a hard cap on Essentials was that it was "designed for small IT environments with fewer than 20 server workloads", which is also stated here - as a 6-socket license, implied density is less than 1 VM per CPU core even with quads.

Interesting that Network World reported back in December "Smaller customers are actually driving the ratios up, as businesses that  installed VMware on fewer than 10 physical hosts are getting 20 VMs onto each  server".

[RogerThomas]

J1mbo wrote:

On the licensing update yesterday, reasoning for a hard cap on Essentials was that it was "designed for small IT environments with fewer than 20 server workloads", which is also stated here - as a 6-socket license, implied density is less than 1 VM per CPU core even with quads.

Interesting that Network World reported back in December "Smaller customers are actually driving the ratios up, as businesses that  installed VMware on fewer than 10 physical hosts are getting 20 VMs onto each  server".

That's one of the daft 'ideas' they have come up with - limit the number of VMs in an Essentials environment not by hard coding how many VMs can be running, but instead by the amount of vRAM as if there is a direct correlation.

In my production environment I run around 18 VMs, but use around 400GBytes doing so as I have so much memory assigned to 3 of the VMs, each of which runs an SQL instance.

[tomaddox]

RogerThomas wrote:

J1mbo wrote:

On the licensing update yesterday, reasoning for a hard cap on Essentials was that it was "designed for small IT environments with fewer than 20 server workloads", which is also stated here - as a 6-socket license, implied density is less than 1 VM per CPU core even with quads.

Interesting that Network World reported back in December "Smaller customers are actually driving the ratios up, as businesses that  installed VMware on fewer than 10 physical hosts are getting 20 VMs onto each  server".

That's one of the daft 'ideas' they have come up with - limit the number of VMs in an Essentials environment not by hard coding how many VMs can be running, but instead by the amount of vRAM as if there is a direct correlation.

In my production environment I run around 18 VMs, but use around 400GBytes doing so as I have so much memory assigned to 3 of the VMs, each of which runs an SQL instance.

You'll use VMware's software the way they want you to use it, and you'll like it! It seems like VMware's strategy is to force lower-level subscribers to upgrade and to force Enterprise Plus customers to leave altogether. We'll see how that works out for them.

[DSTAVERT]

Using that logic we can expect the providers of the hardware (CPUs, Memory, disks etc) and the providers of all the software we need to install (OSs, applications etc) to apply the same idea. So we can expect them all to be charging far more in the future than they do today as all their products will be more complex. or do you think that VMWARE should be the only one to profit from Moore's Law? The reality is VMWARE is already profiting from Moore's Law as it is deployed in many sites because the hardware has already gone beyond the requirements of single server installs, so companies now consolidate.

As it is VMWARE are now trying to increase my costs by a factor of 20x as I have large amounts of RAM assigned to 3 simple VMWARE systems that include 3 database servers with 96GByte of RAM each. These systems have need to go beyond the dual quad core CPUs currently installed. The RAM is installed because it is/was cheaper than adding faster disk sub-systems, but now it's cheaper for me to install Fusion-IO SSD cards or even dedicated database servers than pay VMWARE's new licensing!

And using your logic you shouldn't need to pay Microsoft a per seat license since you've already purchased the server license. The Microsoft license model says if you are going to use more of the services the software provides you pay for the privilege. If Microsoft did not have a per seat model how do you think a server license would be priced if companies could buy that monster server and one Windows Server license. It would either be out of reach of the smaller company or they would need to come up with a model that allowed for use based pricing. Per seat licensing makes the software viable for a range of situations. You pay for use. Why should that not be the same for VMware. Since servers are becoming larger and capable of unbelievable VM densities it doesn't seem fair that we as customers should punish VMware for making a product that can make use of that capability.

Perhaps the real problem is the software that runs our businesses. We should demand that software be written that uses less resources.

[tomaddox]

If Microsoft tripled their licensing costs overnight, you can bet there would be an uproar. Basements around the country and the world would be filled with the cries of outrage and forums would be filled with versions of "Mircro$haft!" and the like. In fact, Microsoft has kept licensing of their server OSes fairly straightforward for many years. The flip side is that you have a choice about whether to pay for Software Assurance, which is quite pricy, or just pay to upgrade when the new version comes out. For non-virtualized shops, it's easy to roll the OS cost into server purchases, so SA doesn't always make sense. In our case, we're going Windows Datacenter Edition, so we pay per processor instead of per server, which works better for heavily virtualized environments.

But I digress--my main point is that people are complaining primarily because of the suddenness and magnitude of VMware's licensing shift. A lot of shops are going to find themselves either needing to buy more licenses or upgrade their existing ones, drastically impacting their licensing costs. A point was made earlier in this thread that VMware is not a charity and needs to make money. The same things are true of my company, and we're not obligated to give money to VMware just so Paul Maritz and Joe Tucci can make the payments on their private islands.

[J1mbo]

If Microsoft did not have a per seat model how do you think a server  license would be priced if companies could buy that monster server and  one Windows Server license

To be fair, some of their products are licensed per CPU with no CALs.  But more generally I suspect Microsoft might have done rather well indirectly via vmware (and of course Hyper-V) by flogging a load of datacentre licenses.

Per seat licensing makes the software viable for a  range of situations. You pay for use. Why should that not be the same  for VMware.

That's a very good question, and an option I for one would like to see.

[GaryHertz]

DSTAVERT wrote:

And using your logic you shouldn't need to pay Microsoft a per seat license since you've already purchased the server license. The Microsoft license model says if you are going to use more of the services the software provides you pay for the privilege. If Microsoft did not have a per seat model how do you think a server license would be priced if companies could buy that monster server and one Windows Server license. It would either be out of reach of the smaller company or they would need to come up with a model that allowed for use based pricing. Per seat licensing makes the software viable for a range of situations. You pay for use. Why should that not be the same for VMware. Since servers are becoming larger and capable of unbelievable VM densities it doesn't seem fair that we as customers should punish VMware for making a product that can make use of that capability.

Perhaps the real problem is the software that runs our businesses. We should demand that software be written that uses less resources.

I hardly think VMware is being punished.  They just reported record sales growths.  If VMware's revenues where declining you might have an argument.

In regards to MS server licensing, the 1 workstation CAL allows me to access an unlimited number of servers.  Datacenter allows me to install an unlimited number of servers on a host. As hardware becomes more powerful I can install more servers on less hosts so I require less server licenses.

In regards to SQL I don't need a CAL if I go to socket licensing and I can install an unlimited number of SQL servers on a host.  As hardware becomes more powerful I can support more users without any additional license purchases.  I can also install SQL servers on fewer host so my licensing costs go down.

MS SQL licensing is designed to scale up.  For smaller businesses you can base your SQL licensing on CALs.  SQL server based on CALs is relatively low cost and you pay for usage through CALs.  At some point it becomes economical to go to the more expensive socket license and at that point your costs are fixed.  With server licensing I can by Standard or Enterprise with limits the number of installs within a VM.  As my needs grow I can switch to Datacenter and install an unlimited number of servers.  Again as hardware becomes more powerful I can install more servers on fewer hosts and my licensing costs go down.

On more point.  A CAL is a separate license from the Server license.  I don't need to buy additional server licenses to get more CALs.  My CAL can access a server using Standard, Enterprise or Datacenter.  There would be a lot less complaints to the new VMware license if they broke out vRAM licenses from the CPU license and allowed me to use it on any edition of ESXi.

Microsoft licensing certainly isn't perfect and I'm certainly not trying to defend any problems it may have. You stated "The Microsoft license model says if you are going to use more of the services the software provides you pay for the privilege".  While that is certainly true at smaller scales the more you scale up the more likely you are to see savings.