Processor Affinity and why you don’t need it on Hyper-V

I have just got back from spending a lot of time on the road, and in my time talking to various users, I ran into a question that I have heard a number of times:

“Can I allocate a specific processor for use by a single virtual machine”

And my answer is always:

“No, and you do not need to”

Let me take some time to explain my answer.  First, in scheduler lingo what we are referring to here is “hard affinity”.  Hard affinity is the ability to take a process (or in this case – a virtual processor) and tie it to a given physical processor.  Most systems have support for this – but in most cases it exists as a workaround for other problems that exist in the underlying scheduler. 

The traditional reasoning behind hard affinity is that if you encounter a situation where a process is not getting sufficient resource – you can go and manually distribute processes on processors to “fix the problem”.  But by doing this – you will create more problems for the scheduler.  Because now the underlying scheduler can no longer optimize the execution of all processes.  In effect – the schedulers hands have been tied by the fact that some of the processors have been hard affinitized.

With this background – why do I believe that you do not need this with Hyper-V?

When I ask users why they want to hard affinitize a virtual machine – the response is always “I have a virtual machine where I need to guarantee that it always has a whole processor”.  That we can do! And without the need to hard affinitize your virtual processors.  All you need to do is to open the virtual machine settings, go to the processor page, and configure the virtual machine reserve:

If you set this value to 100, then our scheduler will ensure that where ever the virtual machine is running, it is guaranteed to have a whole processor (or multiple whole processors – depending on how many virtual processors the virtual machine has).

Problem solved, with no need for hard affinity.

Cheers,
Ben

Comments

• Anonymous
  September 21, 2009
  Where as say, Virtual PC some tasks will completly become unusable if they don't have their affinity bound to a single cpu core... But I digress, i know those of use using Virtual PC to maintain legacy OS's are not the focus, nor concern anymore.

• Anonymous
  September 22, 2009
  What I wonder is that since Hyper-V is limited to a 4 core guest the rest of the available cores on a dual-quad might be getting bored. Setting it to 100 gives me Just 25%? of total system resources.

• Anonymous
  September 23, 2009
  I am having problems with Windows Virtual PCs consuming 100% CPU time after I try to convert over my VPC 2007 VPCs.  I have made a blog entry at http://blog.plippard.com/post/2009/09/23/Windows-7-64-bit-Extending-T61p-life-and-improving-performance.aspx Best to simply skip to the last couple of paragraphs. Can you advise how to report this problem to MSFT. There is no appropriate MSDN Newsgroup I can find.

• Anonymous
  September 24, 2009
  What about the caching benefits you get with hard affinity?

• Anonymous
  September 29, 2009
  Ben- If I gather correctly, for SQL licensing, MS licenses by physical processor (not core). A virtual processor ALSO counts as a single processor for licensing purposes. But with the way Hyper-V currently works, isn't the virtual processor basically equivalent to a physical core? So: in a two quad-core processor setup: in order to utilize all 8 of my cores in a virtual environment, I would need to use 8 virtual processors, and pay for 8 SQL processor licenses rather than two (if I installed on the host it would simply be two processor licenses). Another way of stating the same problem: if I create a single VM on my two-processor machine, and assign it four virtual processors, I've just doubled my SQL licensing costs. Is this something that would be simplified with processor affinity options? Please let me know if I'm looking at it all wrong! I'm very confused.

• Anonymous
  September 30, 2009
  @Josh Check this doc on Hyper-V Hosting Guidance. This gives you details on SQL licensing inside Hyper-V guests http://download.microsoft.com/download/F/5/8/F58E786D-529D-438A-8625-4948205D8BA5/Windows_Hyper_V_Licensing_Whitepaper_v2_0.docx -Ravi

• Anonymous
  October 02, 2009
  @Ravi Thanks. I looked through that, and it stated a license is required for each virtual processor, which is what I've seen elsewhere as well (I've also seen that each virtual processor is considered to have the same number of cores as the physical processor). The licensing guide here says differently (on page 27 of the PDF it gives a scenario where I would need a single license only, for FOUR virtual processors): http://www.microsoft.com/sqlserver/2008/en/us/licensing.aspx This makes much more sense, given that I can licenses multiple physical cores with one SQL license. I wonder which document is accurate, and what I am bound to legally? They are both clearly contradicting papers. Any ideas would be great!!

• Anonymous
  October 06, 2009
  The comment has been removed

• Anonymous
  July 27, 2010
  So you say we never need affinity. What about cases where software needs to be licensed and uses processor, hard drive and NIC? The CPU ID keeps changing and so the license will always FAIL.

• Anonymous
  May 18, 2011
  There actually might be a situation where setting the affinity could improve the performance. In case of processes that heavily utilize resource sharing (cache, process synchronization) hard-coding the physical(logical) CPU might be beneficial. What do you think guys? Libor

• Anonymous
  June 28, 2013
  The author obviously does not understand budgets and licensing.  One of the MOST important features a virtualization technology can have is the ability to limit a VMs cpu use to a specific number of CPUs (a CPU pool).  Many software licenses are based on cores in use, or slots in use.  You can buy a much bigger machine (more CPUs or cores) than a particular software license allows and then configure that software's VM to use less CPUs than the machine has.  This SAVES MONEY.  This saves money for the machine/hardware, network, man hours in maintenance, electricity, cooling, data center space, etc.  You can use the extra CPUs for other VMs, and hence other software.  

• Anonymous
  July 21, 2014
  If I run a 7zip operation on a 4 core guest, it is 33 percent faster if I tie the 7z process to a single guest core (within the guest) LIkewise, 7zip benchmark shows me ~1800MIPS, and 2400MIPS if I lock the 7z process to a single guest core I've noted the same behavior on esxi guests. Linux does not exhibit this issue, as a process is locked to a CPU for long periods of time. Why does windows insist on throwing processes all over town?

• Anonymous
  August 04, 2014
  Hi Ben, I've got a licensing issue. Pervasive database CPU license looks at the CPU ID or serial and binds it to the License number. So if the VM start taking resource from another CPU Pervasive stops working because the CPU ID no longer matches what if was upon installation. So this problem has nothing to do with performance but everything with licensing. For this same reason I have to run Oracle on a physical machine. Should I go voer to VMware or is there some workaround?