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
