>>In our case the benefits of VM are mostly to have pathing in place as to not depend on dynamic pathing for each process and the ease of moving the environments to other HW in case of upgrade, failure or hosting switch. The 10% added runtime in the worst case was worth it, as fiddling with such issues was getting on my nerves.
>>
>>Yes, in my case the VMs would be set to specific cores - even if the speedup is only negligible, timing critical stretches should be less prone to variations stemming from the almost random distribution of others tasks swapping more or less than usual in the timed run.
>
>What would be more important to you - reduction in variation, or (incremental?) speed increase? Or both?

There is already quite a bit of variation in the % of total time due to different DB sizes, different data changes which follow some repeating patterns, sometimes shifting bottleneck from CPU to disc access even on SSD to name the worst offenders. Probably one of the next attempts will be to throw HW at the problem again and to measure how much of a speedup a pure RAM disc might offer if a SSD grows into a serious bottleneck - crossing my fingers that the measures taken to circumvent that situation (mostly re-arranging DB set sizes) will make it unneccessary.

>
>On Hyper-V processor affinity isn't supported, but then they tell you how to do it anyways ;) : http://blogs.technet.com/b/tonyso/archive/2009/09/22/hyper-v-how-to-set-processor-affinity-in-hyper-v.aspx
>
>That post is 2009 but applies to Hyper-V in Server 2012 R2 as well.

Thx! Bookmarked!