SQL Licensing under 4.0 Ent Plus

[craiglindsay]

I am very happy to be able to now create a guest with more than 4 processors, this means we can virtualize some workloads that previously needed to remain physical. I am not happy that I have to bump up my licenses to enterprise plus, but that is another rant. The problem I am running in to is understanding MS SQL licensing in a virtualized environment, especially in the 8 processor world as there are no clear documents or examples of this anywhere I can find.

Here is the situation. We have several HP DL580 G5s with 4 physical processors, six cores each, for a total of 24 cores, great machines. I can run SQL std on these boxes physically and have access to 24 cores. In this mode I license the box with 4 SQL Std processor licenses and am covered under MS's policy, cost about 30K. This is easy to understand.

Where it gets hard is that I would like to virtualize these. If I create a guest with 8 processors, since VMware creates a guest with vCPUs and it seems those are exposed as individual CPUs not cores to the guest. Reading the MS license it would appear I would need 8 SQL STD processor licenses for this guest (2x more than on the physical box). The cost is an issue, but the main problem is that SQL Std only supports 4 CPUs. So then it looks like I can move up to enterprise. Then licensing changes, I can then license all 4 physical processors on the box and then put as many SQL instances on the host as I want. That works except that SQL enterprise is 4x the cost of standard. That means an individual box is 120K to license, if I want HA with VMotion, I have to license another box filly. It is obviously impossible to convince anyone on earth to pay 120K+ to license a single box for SQL enterprise instead of 30K for SQL std regardless of ANY benefit virtualization can bring to the table. Seems I am stuck in the physical world.

I guess I am hoping that someone has some different information on how MS licensing applies to virtualiztion in 4.0 with more that 4 processors since this is something that is new, or better yet, that my understanding is incorrect, or that there is some proc/core licensing works that works in 4.0 by using processor affinity or some other "workaround". Or that vSphere 4 exposes cores not processors, something, anything to make this situation workable.

Now that 4.0 is almost here, it seems my dreams of a 100% virtualized datacenter are being dashed because of archaic licensing models.

[AsherN]

First, you should not need another licence for HA or vMotion. It's still the same server that you are moving. Think about a backup to tape and restore to new hardware.

Most important, if your SQL server truly needs all 24 cores, it may not be a good candidate for virtualization. Run some assessment tools, see how much resources are actually used.

[craiglindsay]

Using the 4 SQL Enterprise proc licenses I am licensing the host not the guests, so again, up to my interpretation, it seems that if I was going to use vmotion for something like maintenance of one box, I would need the second box licensed to allow me to put the first host in to maintenance mode. While I agree in the spririt of comparing it to backing up and then restoring, I beleive MS specifically states they do not allow short term transfer of a license less than every 90 days. So I wouldn't technically be able to upgrade a cluster from say 4.0 to 4.0 Update1 without taking 90 days between upgrading each node of the cluster. So I would need to license at least 2 nodes of my cluster for SQL Enterprise full to be able to by withing the letter of the law on this one.

The guests will run fine on 8 cores, just not fine on 4, thus the excitment surrounding the 4.0 release. The 24 cores on these physical boxes are overkill, and frankly were purchased because we planned on moving them in to the virtual world after vSphere 4.0 came out. Now it seems that won't really be workable.

[AsherN]

I've read the license brief, and my interpretation is that you license the OS platform (the guest) per vCPU. The term 'server' seems to refer to either the hardware running the OS or in the case of a virtualized environment, the VM running the OS.

My interpretation would be that a 4 CPU lic of SQL allows you to run it either on a 4 pCPU box running Windows, or in a VM using 4 vCPU. And that vMotioning a VM is not equivalent to re-assigning to a new server.

Best check with the very warped minds at MS Licensing.

[SWCS833]

Here is the licensing sheet for SQL 2008. I would say go with SQL 2008 Enterprise CPU licenses. You will need to license the physical processors in the server. To be compliant, you would have to license every physical processor in all of your vmware servers that could potentioanly run your SQL VMs. I am not sure if I like Microsofts stance on licensing all of the physical servers, and I myself would say that I would due my due diligence to "always" have my SQL boxes run on that one licensed physical server.

[AsherN]

Defiant, I've read the document. In all instances it talks about the number of processors in the OS environment. You license SQL server per vCPU. One VM using one vCPU is a single license. 5 VMs running on a single proc, dual core host needs 5 licenses. The only exception is the Enterprise license which allows you to run multiple instances on the same OS instance.

[craiglindsay]

Here is the meat of my problem.

I can see buying a proc license for every vCPU in my guests. It is a

high price to pay but it is the same rules as the physical world, no

penalty there.

The new problem introduced is that I can create a system with 8 vCPUs

that runs on hosts with only 4 physical CPUs. There isn't a scenario

in any paper I have seen where more vCPUs per machine than the host

has CPUs is outlined.

It seems like I should only have to pay for 4 proc licenses in any VM

tops since that is all there are physically in the host. But if I

swallow the pill I have to pay a penalty for virtualization and buy 8

SQL STD proc licenses I might even end up bring able to press forward

but SQL STD only allows 4 procs so I have to move to enterprise.

Enterprise costs 4x what standard costs. At retail thay is around 120k

to license one box.

Now I don't know how many people have asked therir CEOs for money to

buy hardware for virtualization and said for each host we have to

virtualize we have to not only pay for VMware licensing at 3.5k a proc

but now we also have to change our ms licensing model to enterprise

and pay a 120k premium for each box. But I can assure you if anyone

has asked, nobody has succeeded. I can buy 6 servers for this. With a

pricing model like this virtualization is a non-starter.

Again I am hoping for some info on this specific problem or a

"workaround" where by exposing cores instead of vCPUs. Surely someone

at VMware is working with ms and other companies on this type of thing.

On Apr 30, 2009, at 5:55 AM, "VMware Communities Emailer" <communities-emailer@vmware.com

[AsherN]

I've re-read the document that defiant posted, and he's right. With Enterprise, you can license the procs on the physical box and run as many SQL VMs as you with. In your case it would make sense. Of course there is that pesky 90 days thing, but you need to see if it is a paper restriction, or if it is enforced by SQL.

[SWCS833]

Craig,

What kind of processors do you have in your physical servers? It would make sense to purcahse SQL Enterprise CPU Licenses for your physical host. Microsoft does have a clause that says that you can only transfer the license every 90 days. This means if you have physical server1 and physical server 2, but only license physical server 1, you can only vmotion vms from physical server 1 to physical server 2 every 90 days. I myself wouldn't let this stop you from just licensing physical server 1. Just say that your SQL will "always" run on physical server 1 (notice the quotes). If you have many physical servers, maybe license half of your servers.

[Smoggy]

I have not read the documents linked in this thread but from my own personal notes I can share some examples/info I have used before. Microsoft SQL licensing is either ‘Per Processor’ or ‘Per Seat’.

• ‘Per Processor’ requires a license for each virtual CPU in each Windows Virtual Machine running Microsoft SQL. This applies to Microsoft SQL Standard only

• ‘Per Seat’ licensing has two halves:

* a SQL Server Standard license, required for each SQL Instance running inside each Virtual Machine

• plus a user Client Access License, allowing each user with a CAL to access any SQL instance

Microsoft SQL Enterprise Edition is slightly different; it can be licensed in two distinct ways:

• ‘Per Processor’ which licenses the physical CPUs in the server. This
  license allows unlimited SQL Instances on that server and unlimited
  client connections. The SQL Instances may be in numerous Virtual
  Machines, each with a different number of virtual CPUs. For numerous SQL Virtual Machines on the same server, this could be optimal

• ‘Per Seat’ licensing, identical to SQL Standard Edition, has two halves:

* a SQL Server Enterprise license, required for each SQL Instance

• plus a user Client Access License, allowing each user with a CAL to access any SQL instance

two examples I've seen before would be:

1.One two-socket, quad-core server running ten Virtual Machines. Each Virtual Machine has two virtual CPUs and 4GB RAM. Each VM will run Microsoft SQL, either Standard or Enterprise.

2 CPUs; 10VMs; 20 vCPUs	number of SQL ‘Per Proc.’ Server licenses	number of SQL ‘Per Seat’ licenses
Windows 2003 Server licenses	10	10
Microsoft SQL, Standard	20 (one per virtual CPU)	10 Server + User CALs
Microsoft SQL, Enterprise	2 (one per physical CPU)	10 Server + User CALs

2.One two-socket, quad-core server running three Virtual Machines. Each Virtual Machine has two virtual CPUs and 4GB RAM. Each VM will run Microsoft SQL, either Standard or Enterprise.

2 CPUs; 3VMs; 6 vCPUs	number of SQL ‘Per Proc.’ Server licenses	number of SQL ‘Per Seat’ licenses
Windows 2003 Server licenses	3	3
Microsoft SQL, Standard	6 (one per virtual CPU)	3 Server + User CALs
Microsoft SQL, Enterprise	2 (one per physical CPU)	3 Server + User CALs

hope this helps,

Lee Dilworth

[AsherN]

That's why I wondered if the restriction was just on paper, or enforced by the software in some way.

If it's opn paper, I'd licence the one server and take my chances. If MS somehow got wind of the VMs changing servers and wanted to pursue it, I'd fight it. I'm not a 100% sure that MS would win that one.

[craiglindsay]

Thanks, I am down with all these examples. I understand the agregate licensing shown in the MS papers and in the examples above. Nothing I can find shows how it works when a single guest has more vCPUs than the host has CPUs. So I still want to see a logical argument or an example why I would ever have to license 8 CPUs in a guest when the host only has 4 physical CPUs.

I guess I have basically 2 paths to take.

1. Suggest enterprise to managment, pack my bags and leave because I will be laughed out of a job

2. Don't virtualize all my workloads because vSphere with 8 proc VMs and MS SQL licensing is a cost prohibitive option

Oh, and I just for the record, I have asked 3 people at MS licensing and no answers yet. I am persuing that route also, but when I have asked question in the past it both takes a long time to get an official responses and it also completely depends on who you talk to as to what answer you will get.

[AsherN]

Why don't you download the MS virtualization assessment and planning tool

Run it for a while on your SQL server and see what MS thinks your host needs to be to support that application.

[andymc123]

Sorry to comment on such an old post, but this is the exact situation that we are in at our company.  Since this post it 2 years old does anyone know if things have changed? I have been going back and forth with our company that we buy licensing from and reading posts all over the web as well.

Any clear answers today?

[iviemeister]

This does have a fairly clear answer from Microsoft, yes:

http://download.microsoft.com/download/6/8/9/68964284-864d-4a6d-aed9-f2c1f8f23e14/virtualization_bri...

"Virtual processors are considered to have the same number of threads and cores as each physical processor in the underlying physical hardware system."

"If the physical processors in the server have two cores, for licensing purposes, each virtual processor also has two cores, even if the cores are allocated from separate physical processors."

In short, you need to license (Assigned vCPUS)/(Cores per socket) = (Virtual CPU count for MS).

You can only move licenses between physical servers every 90 days, so for DRS or HA, you need a license for each host that the vm may move to, but at least you don't need to license each core in the base physical machine....