Virtualization Technology News and Information
Virtualization Management Socket-Based Pricing Versus Per-VM Pricing

Software licensing has really started to get "tricky" what with the introduction and growing popularity of server virtualization.  Gone are the days of one server, one app.  And now, people are again wondering how they should license software... or more to the point, there seems to be a growing concern around licensing virtualization management software.  Should it be Per-Host?  Per-VM?  Per-Socket?

Bryan Semple, CMO at VKernel, wrote a really interesting blog post yesterday talking about this very topic. Semple has heard from customers, prospects and virtualization admins on the street while attending shows like VMworld and VMware User Group (VMUG) meetings. He writes:

Virtualization admins and their managers don’t like pricing models based on the number of managed VMs. Socket- and server-based models appear to be the way most directors of infrastructure want to buy.

This seems to follow along with what VKernel's current pricing strategy is as well as their currently planned future pricing model as well.  The company prices their management applications on a Per-Socket basis rather than on a Per-VM basis, a model which is starting to grow in popularity with software makers.  Even VMware itself has switched many of its applications to Per-VM pricing.  With perhaps more changes on the way.

From an end-user's perspective, I tend to agree with Semple's findings.  Quite frankly, Per-VM pricing can be rather cumbersome to keep track of as compared to Per-Socket.  Ask any virtualization administrator how many physical servers they have under management, and 9 out of 10 times I'd bet they are pretty darn close to accurate.  And most know how many sockets are in each of these servers.  But ask them how many virtual machines they have under management, and I bet almost all get it wrong... sure, if you have 10 VMs in your environment, it's a much safer bet.  However, with VM Sprawl being a known problem, and one that has caused many software solutions to hit the market, well, it's really difficult to know off hand just how many VMs are running wild in your environment most of the time. 

In addition to that, what happens if I have VMs that are turned off for a short period of time?  What about a long period of time?  Do those count against Per-VM pricing?  Is it only counting against powered on VMs?  Or maybe it looks at some sort of rolling average?  What about VMs that are part of a load balancing environment or a disaster recovery situation?  Do those count against you as well?  If you let your virtualization environment grow out of control, you may start ending up with a bill that reminds you of the old cell phone days before they had unlimited text messaging.  This could be a wake up call to get your virtual house in order.

In this day and age when we are talking about tiering storage or talking about the difference between virtualizing test/dev, low hanging fruit, or production/mission-critical applications, should Per-VM pricing take these types of VMs into consideration?  You might be willing to pay, say, $50 to monitor/manage a mission-critical application, but would you pay the same for a low-hanging fruit or Test/Dev VM?  And if not, what happens here? 

Hmmm... [scratch head]

So am I saying Per-VM pricing doesn't make sense?  Not at all.  But there are questions that need to be answered. I don't believe it should be as simple as every VM in your environment gets charged a price of "$X" no matter what. In the end, this move to Per-VM pricing is a natural progression towards a pay-as-you-go cloud pricing.  Isn't that where the pundits are telling us that this is all headed anyway?  Today, the reason for moving to this style pricing for a vendor seems fairly obvious.  As servers become more and more powerful with increasing core count per socket, the densities of VMs to host go way up and through the roof!  Charging Per-Host or Per-Socket will no longer make sense for that software vendor's bottom line.  Do the math.

On the VKernel blog, Semple lists two key reasons why his company won't be changing to Per-VM pricing any time soon.  Go check them out. 

And he writes, "Per-VM pricing benefits the selling vendor, not the end user. Charging for virtual goods like VMs might be a good idea if you are the makers of Farmville, but not for purveyors of virtualization management software."

I say good for VKernel.  But I also wonder, how long can they hold out?

What say you... do you mind Per-VM pricing?  Are you ready to move to Per-VM pricing?  Is it much ado about nothing or do you have concerns?

Published Thursday, June 02, 2011 5:00 AM by David Marshall
Virtualization Management Socket-Based Pricing Versus Per-VM … « Management Fair - (Author's Link) - June 2, 2011 8:46 AM
Virtualization Management Socket-Based Pricing Versus Per-VM … | Web Hosting Geeks - Shared Web Hosting, VPS, Dedicated Servers, Virtualization and Cloud Computing - (Author's Link) - June 2, 2011 1:12 PM
virtualization management - (Author's Link) - June 14, 2011 4:16 PM
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<June 2011>