-- Ben Armstrong, Virtualization Program Manager
Talking about core virtualization at Microsoft (Hyper-V, Virtual PC and Virtual Server).
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
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.
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.
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.
What about the caching benefits you get with hard affinity?
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.
@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
@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!!
i saw the cat and i said you cant just go where you want and he said meow then i said breeahhh
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.
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