VMs and CPU Cores





    Can virtual guests share a CPU core in hyper v? i,e can i allocate a VM to only use 50% of a core and another VM to use the other 50%?





    Wednesday, May 21, 2008 5:55 PM


All replies

  • As far as the first part, yes a core can be shared. More than one virtual machine can be run on a single core.


    You can allocate a virtual machine to use only 50% of a core. Ben Armstrong wrote about it here

    Wednesday, May 21, 2008 8:02 PM
  • You cannot set affinity as you can with ESX.


    All VMs share in the pool of host resources at all times, so your VM workload is constantly moved around as is necessary.  It's virtual processor could be on any physical or logical processor.


    The reserves are a way to bound the VM, either limit how much Host it can get, or grant it more host.



    Wednesday, May 21, 2008 8:14 PM
  • Does it means I can't work like VMWare, say assing the first VM using the 1st core and the second VM using 2nd and 3rd core?


    Thursday, May 22, 2008 8:26 AM
  • You cannot assign a virtual machine to a specific core.

    Thursday, May 22, 2008 10:47 AM
  • Correct, it DOES NOT work like VMware.


    I am sure there are tricks that can be done in the background and possibly there are items that are not exposed in the UI.  But as far as we know right now, this is not possible.


    Can I ask why you think that you would need to set a VM to a specific core?


    What benefit do you feel that you acheive by doing this?


    Thursday, May 22, 2008 3:10 PM
  • Assign VMs to individual or specific cores helps us on performance testing (benchmark collection) only, no such benfits we can get.

    Friday, May 23, 2008 2:45 AM

    I agree that, although VMware ESX supports this config, it is rarely used (and it is never -generally- suggested).


    I'll take that if with Hyper-V you set a 1 vCPU vm to use 50% of the processor it will use 50% of the core the hypervisor put the vm on. I would also speculate that the hypervisor will not move the vm around the cores ... in order to optimize and get the max out of the processor cache (i.e. you always want to run on the same physical core in order to NOT miss Lx caches). This should hold true even if you continue to add vm's at a reasonable pace.


    If you get to the point of overcommitting the system substantially than the VM's will start to float around based on actual usage patterns ...... but in a scenario like this I don't see why you would want to pin a vm to a specific processor .... what you are getting out of a scenario like this is going to be pretty unpredictable so also any sort of benchmarking would be a litlle bit a stretch.


    My 2 cents.



    Monday, May 26, 2008 3:45 PM
  • I have a good reason why you should be able to do this. I'm evaluating a dual socket Intel Quad X5460, 5000X chipset, 16GB with SAS 15k drive arrays. While running performance test with our ERP\SQL system I discovered that with 2 physical (8 cores) my benchmark tests ran 30%+ slower than when the system was using 1 physical (4 cores). This was the case whether I was running the tests on the host or guest environment. With an 8 core host \ 4 core virtual server my test results were very close in both environments but if I configured the virtual server to run on only 1 core I ran 30%+ faster since it could only run on 1 physical processor. If I ran the virtual with 2 cores it would run slower since the 2 virtual cores were being run on two physical cores on seperate physical processors.
    When I configured the server to 4 core host \ 4 core guest my performance was good. So ideally I would like to run the host with 8 cores and be able to specify that my ERP virtual server run on 4 cores within the same physical processor and run the balance of my less demanding virtual servers on the other processor's 4 cores.

    I hope the functionality become available in the final release of Hyper-V. In the mean time I will be evaluating an AMD Dual Quad 2356 or 2360 similar configuration to see if it’s on board memory controller and CPU to CPU latency is faster.



    Wednesday, June 04, 2008 8:00 PM