1

Possible Duplicate:
Hyper-V and Hyper-threading: On or off?
Can you help me with my software licensing issue?

I've seen lots of people saying we should turn hyperthreading on on hyper-v hosts, but I've got a dilemma.

We're going to be running SQL Server 2012 Enterprise on a 2012 hyper-V cluster. This is licenced per core, and in a virtual hyperthreaded environment I think that core is a thread, not a full core. It's also quite pricey compared to the hardware cost :-)

If our SQL Server instances start being CPU-bound, how much extra processing power would we get from 4 non-hyperthread cores vs 4 threads (ie equiv to 2 cores)?

Should I be considering running my hyper-v environment with hyperthreading turned off?

  • 1
    Benchmark it with a representative workload. – Michael Hampton Oct 22 '12 at 20:29
  • Yes, benchmarking would be an obvious part of the answer. Unfortunately I can't do that right now, hence my question. – Clive George Oct 22 '12 at 20:31
  • It's not really the licensing question I'm trying to answer - I'm fairly confident I understand that (though if people can tell me I'm wrong that would be great :-) ). It's the performance question, ie what does hyperthreading give me or how much do I lose turning it off. – Clive George Oct 22 '12 at 21:35
  • Ignore my comment, just saw your update. – Mark Henderson Oct 22 '12 at 21:36
  • Hyperthreading doesn't affect your licensing, which is by physical processor, not core or thread. – Jake Oshins Oct 22 '12 at 21:36
  • [That question has been answered here before, too.](http://serverfault.com/q/47411/126632) – Michael Hampton Oct 22 '12 at 21:58
  • Scott, Michael - this isn't a duplicate question. The two threads you think are relevant don't answer the specific question, which is basically about the performance of SQL Server with or without hyperthreading. It's definitely not a licensing question - that's just the reason why I'm asking this question. It's also not answered by a generic thread on hyperthreading - this is specifically SQL Server. – Clive George Oct 22 '12 at 23:06
  • Jake, it's not by physical processor, it's by core on a physical machine or thread on a hyperthreaded virtual machine. This is SQL Server 2012 Enterprise, not 2008 or earlier - the rules changed. – Clive George Oct 22 '12 at 23:40

2 Answers2

1

Look at licensing at the host level instead of the VM level. If your cost has 24 cores and you've got two hosts you'll need to license 48 cores. If your VMs total up to 60 vCPUs it'll be cheaper to license at the host level.

This requires that you have SA and an EA, but if you are buying this much software you'll want these anyway.

mrdenny
  • 27,074
  • 4
  • 40
  • 68
  • Thanks, I did consider this one. But there's way more host CPUs than SQL Server ones so it's a bit expensive. If it was for a dedicated SQL Server farm, especially with each instance consuming a small amount, it would definitely be something I'd do, but it's more general purpose than that. – Clive George Oct 22 '12 at 20:49
  • What some people are doing is having two farms, one for SQL and one for the everything. With VM licensing yes you have to pay even if the host puts your vCPU on a HyperThreaded core. That being the case turning off HyperThreading may make sense. – mrdenny Oct 22 '12 at 20:55
0

For a comparable reason we're running our oracle server in a virtual machine BUT the host has only one socket, limited amount of memory and no access to the SAN. We have virtualized it mainly to be able to do snapshots and fast recovery and switchover to a new machine.

Oracles license management is insane... Every core wich can access the database server in a virtualized environment has to be paid. If we commected this server to our San we had to pay for all cores in the San capable of accessing the disc. So MS licensing cant be THAT bad...

cljk
  • 225
  • 1
  • 10
  • Oh yes, oracle and virtualisation just don't mix at all :-) (ok, there are some, but not mainstream - eg LPARs on AIX) – Clive George Oct 22 '12 at 21:33