The SQL Virtualization Tax?

I’ve been working in virtual server environments for a long time, and a big proponent of virtualization. It’s a great way to reduce hardware costs and power consumption, and frankly for smaller shops it’s also their easy foray into high availability. The main reason for the high availability are technologies like VMWare’s vMotion and Microsoft’s Hyper-V Live Migration—if a physical server in a virtualization farm fails the underlying virtual servers get moved to other hardware, without any downtime. This is awesome, and one of the best features of a virtual environment. What I don’t like is when software vendors feel they are getting the raw end of the deal with virtualization, so they develop asinine licensing policies around.

Oracle is my favorite whipping boy in this discussion—Oracle is most typically licensed by the CPU core. In my opinion, a CPU core should be the number of cores that the operating system can address. Oracle agrees with me, but only in the case of hard partitions (mostly old, expensive UNIX hardware that they happen to sell). Basically, if I have a cluster of 64 physical nodes, and I have one virtual machine, with one virtual CPU, Oracle expects me to license EVERY CORE in that cluster. The ways around this are to physically lock down your virtual machine to a given hardware pool and then license all of those cores (a smaller number of course). The other option is to dedicate a bunch of hardware to Oracle, and virtualize it—while this works, it definitely takes away a lot of the flexibility of virtualization, and is a non-starter for many larger IT organizations.

Microsoft, on the other hand has been generally pretty fair in their virtualization licensing policies. An Enterprise license for Windows Server bought you four VM licenses, and SQL Server (before 2008 R2) had some very favorable VM licensing. However, starting with the SQL Server 2012 things started to get a bit murkier—for Enterprise Edition, we have to buy a minimum of 4 core licenses, even if you are only running one 1 or 2 virtual CPUs. However, we don’t have to license every core in the VM farm. One thing that caught my eye with the SQL Server 2012 licensing, is that if you license all of the physical cores in a VM farm, you can run unlimited number of VMs running SQL Server, but only if you purchase Software Assurance. Software Assurance costs 29% of license costs, and is a recurring annual cost. In the past Software Assurance was generally only related to the right to upgrade the version of your software (e.g. if you had SA, you could upgrade from SQL 2008 R2 to SQL 2012). This rule bothered me, but it didn’t really affect me, so I ignored it.

I was talking to Tim Radney (b|t) yesterday, and he mentioned that in order to do vMotion/LiveMigration (key features of virtualization) Software Assurance was required. I hadn’t heard this before, but sure enough in this document from Microsoft, it is mentioned:

So, in a nutshell if you want to run SQL Server in virtual environment, and take advantage of the features that you paid for, you have to pay Microsoft an additional 29% per license of SQL Server. I think this stinks—please share your thoughts in the comments

Another great post. Thanks. As a developer I don’t deal with licensing much but it’s good to learn about these things and how they affect real world situations.

It has always been weird to me that virtualization costs so much in licenses especially when it’s purpose is for disaster recovery or quality assurance or etc. In my release cycle all the VMs serve a purpose to help production even the dev VMs. Sometimes it’s hard to validate another VM to do something “properly”. I want to stay out of production, I really do.

Like if I really want to create a data mart so there is less load on the database for ad-hoc stuff, that would be beneficial but at what ROI. You’d think an “enterprise” license would allow for me to build the data solution out to support the enterprise. When I think “enterprise” that’s what comes to mind, not column store indexes or another feature.

Oh well, I just write the code and queries and hope the organization can afford the cost of doing business, with a good level of service.