Scott Drummonds on Virtualization

The Future of VMware Pricing


Bryan Semple at VKernel last week wrote a blog article on per-VM pricing in VMware and VKernel products. Bryan observed that VMware’s customers dislike per-VM pricing.  He then stated that VKernel will stick to asset-based pricing such as per-socket. Bryan spends a lot of time with customers and I will not refute his claims. Whether or not we like per-VM pricing, I think it is here to stay.

The challenge facing VMware was best summarized in Bruce Herndon’s article assessment of processor performance over VMmark’s brief history. The text is best summarized best using the article’s single image.Systems featuring Intel's Nehalem architecture and later enjoyed an unusual increase of performance.

You can roughly trace a straight line across the first four products to see the trend in performance. By any attempted best fit line, the Nehalem and Westmere numbers represent an incredible deviation. They show VMmark results that greatly exceed any attempt at trending the previous results. For VMware products, which until last year would cost the same on all six of these platforms, the customer would derive about three times as much value from the Nehalem-based system as the Harpertown. The sad calculation from VMware’s position is that the same number of customers would supply it with about one third the revenue.

I still have friends in the performance team at Intel I left many years ago. We talked about the desktop products from the Nehalem architecture that came out a few years back. I remember one of my friends told me the first silicon they tested in the lab produced numbers so high he was sure the test was in error. The results were so high they exceeded the reasonable bounds on expectation using Intel’s previously accurate performance estimation calculations.

The question that VMware had to ask itself with the release of the Nehalem parts is how much VMware was willing to tie its revenue to processor performance. From a business perspective, I find that proposition unacceptable. It is much more logical to tie the products’ prices to customer value. This assures that customers are willing to pay more for higher value products and VMware retains incentive to higher value products that we all appreciate.

But Bryan’s comments ring true. Customers do not want to pay more money for virtual machines they were previously getting for free. But VMware cannot remove itself from the value calculation that drives their adoption. What is VMware to do? I have a suggestion.

I think all VMware products should be priced per-VM. But VM prices should be graded based on value and not assigned a fixed cost. Furthermore, I believe it is crucial that VMware continue to support the entry-level model of free ESXi that allows all customers to try enterprise class VMware virtualization at no cost. A pricing model based on these positions might look something like this:

  • Two-way virtual machines with up to 4GB RAM: free.
  • Additional vCPUs: $10/vCPU
  • Additional vRAM: $1/2GB vRAM
  • Fault Tolerance enabled: $50/VM
  • HA protected: $10/VM
  • vMotion Capable: $10/VM
  • vCenter Administered: $20/VM
  • Capacity IQ Managed: $50/VM
  • etc.

(Ignore the specific values above.  I imagined numbers for the sake of discussion.)

The end result here is good for the customer and good for VMware. But this is complicated.  Without limiting unpredicted growth of a virtual environment it requires total honesty from VMware’s customers or a much-loathed regular audit. Would you allow this?

15 Responses

Yeah, good luck with that. You will at the very least piss off some customers if not lose some. Increasing licensing cost while making it more complex? Sounds like the Citrix and MS fiasco where many of their own employees don’t understand how their licensing works. I vote to KISS!

  • Forget it – I simply will not EVER buy a product with per-VM licensing. Nor will I buy a storage-related product with per-TB licensing.

    Your “value-based” license totally falls apart when I compare my customer-facing guest against a developer “play with the latest patch release” guest.

    License the socket and I know I’m done rather than writing a check every time somebody wants to spin up another guest.

  • Because that’s what we need – more complicated licencing. Licence the host. Period. I can buy Hyper-V per socket, with unlimited virtualization rights as well without all that hassle. In fact, many sites I know have HAVE done that for their Windows VM’s on vSphere. Start making vSphere hard to manage, and you’ll see people asking why they don’t just use the Hyper-V they’re already licenced for…..

  • Sounds terribly complicated when you’re looking at purchasing for say 3500 virtual machines. If I was responsible for figuring out what to buy I might look for something with a simpler licensing model. In my current customer environment today (where there are over 12,000 virtual machines) they would seriously consider looking at Xen just to avoid the complexities of VMware license pricing and trying to figure out a workable chargeback model. You’ll eventually need to start selling tools to help determine that license cost and VMware will end up the “800 lb gorilla everyone is looking for alternatives to.”

    The end result is NOT good for the customer and in the long run isn’t good for VMware. Customers want to simplify tools, processes and procurement not add another layer of complexity.

    I understand that VMware wants to keep revenues up as compute horsepower increases. If they want to do that then they should just add value through additional management products and innovation.

    KISS principle 100%. There should not ever be a need for a VMware Certified Licensing Professional.

  • I actually ran your numbers just for the sake of comparison. In a specific customer environment the per VM licensing model you used as an example (with HA, DRS and VC only) was literally 7 times the cost of a licensing agreement that customer signed.

    That ELA included everything with CapIQ and SRM..

    Its not good for the customer at all when your costs go up well over double what they were the previous year..

  • I think a move towards per-VM licensing won’t matter that much really – how is external cloud consumed today? Mainly on a per-VM basis, and business are chomping at the bit to get onto it. How do enterprises charge the business for VM’s today? Surprise, surprise, per VM! It has to be done that way because the guest OS requires maintenance, and that maintenance is usually costed on an ‘admin per X number of machines’ basis. Not to mention all the other things that are per VM – guest OS licenses, in-guest agent licenses, etc etc. It’s really no big deal.

    But what leaves a very bad taste in my mouth is VMware thinking they “deserve” a bigger cut of revenue due to advances in underlying hardware technology. Have a look at all the computers you’ve owned over the years – what did they cost? For me, they’ve always been a few grand, but it’s stayed constant over the years which means they have actually gotten cheaper in real terms. So hardware gets cheaper over time, yet software gets more expensive over time? I don’t get that. Maybe the likes of Intel should be rewarding themselves more for advances in hardware. More powerful CPU’s may mean fewer licenses for VMware on a per socket basis, but it also means less CPUs sold by Intel. But we don’t see them making moves to try and get more revenue from fewer sales. Maybe all VMware needs is a bit of healthy competition.

  • People handling enterprise chargeback want as many constants as possible to help them formulate cost recovery. They KNOW Oracle costs TotalCores/2 in licensing. They know that currently ESXi enterprise has a cost of X per socket. Just because someone is already charging per VM doesn’t mean we should toss them more licensing revenue “just because.”

    If you’re not doing chargeback (like plenty of shops in the 10-2500 VM count do) then you’re just adding unnecessary work and overhead in trying to get people to buy your product. If VMware takes that approach then they can expect to experience their market share to whittle away in favor of products that can get “close enough.”

  • VMware have already identified, at least in their Service Provider license agreements, that RAM is the limiting commodity. Sure I may have a CPU model that can support a vCPU:core ratio of 25:1 without breaking a sweat, but can I put enough RAM in the box to keep guest performance acceptable. Probably not without using an expensive technology like IBM’s MAX5.
    With VSPP, the licensing is per GB of vRAM per month. This decouples the pricing from either the number of guests or the CPU technology period. It allows customers to build out their infrastructure for elasticity without huge capitalization budgets required to purchase software. It’s simple, easily measurable, scalable and has price points that provide greater benefit as you scale up. I just wish they would:
    a) make it cheaper (they already dropped the price >50% from release and it’s still too expensive!
    b) make it available to all customers, not just service providers.

  • So…for those of you who don’t like a per-VM pricing model, what would you do if at VMware? (i.e. something that’s not complicated, keeps VMware in business/provides money for R&D, isn’t annoying as a customer)

    Am honestly curious…

  • Per GB pricing scaling down the higher the value…

  • doesn’t make sense to move ahead with this while there are many choice in the market always open to the users, I think vmware trying to put themselves in a situation like Oracle, which end up most users will migrate out. They are just a hypervisor and is always replaceable

  • IF!! – And still only IF VMware changes the licensing model to a pr. VM type, they will see a big revenue drop anyway. Admins and managers will look at the lost flexibility and say…. Well the product is excellent, manageable, scalable, but is there any other way to get this flexibility back? XEN, “Hyped-V”, Redhat? I know personally I would have to start investigating more heavily to justify the pr. VM model rather than just accepting the obvious platform for running VM´s….


    p.s. just past 2000 VM´s today

  • When I think about licensing model’s that piss me off the most Oracle comes to mind. Why, because the progress of technology in the industry marches on but I get no more value from them today then I did when I bought the licenses 5 years ago because I’m paying per core. I’m paying maintenance dollars that add up to more than buying MS SQL Enterprise licenses which would allow me to take advantage of that growing hardware power. The only reason I don’t switch is that MS SQL isn’t really a substitute. For Hypervisors if I was suddenly faced with a trippling in cost I would have to look very seriously at the value add and weigh it against just dropping VMWare and going with my already paid for Hyper-V licenses.

    Oh, and I don’t even want to think about how much licensing would slow down the agility that VMWare has given us, just yesterday my CIO asked me what the primary advantages we had achieved through virtualization were and one of the biggies was agility. If it takes me as long to get VMWare licenses approved and order and delivered as it used to to get hardware then you’ve just dropped the value add significantly.

  • The ability to create VMs at will and highly consolidate them is a major part of the value of VMware. Per-VM pricing models destroy that value. I don’t know what my company will ask for next week or next year, but I do know that if anything they want to do requires the owners to pull out the checkbook they’re not going to want to pay the already huge VMware support contract anymore.

  • Oh, and your model is ignoring a key point: applications are requiring more CPU time and more cores to function these days, so while you can put more of today’s VMs on tomorrows hardware, you will need to use bigger VMs for tomorrows applications.