none
Logical Processors assignment.

    Question

  • Hello all,

    I have a machine with 2 x QuadCore with hyper-threading enabled (16 logical processors).

    If I only have one or two VM running in there (With 4 logical processors enabled each), does that mean that the other 8/12 processors are just sitting there? Doing nothing?

    Thanks

    Alex.
    • Edited by LeMoi Thursday, May 21, 2009 7:21 PM Typos
    Thursday, May 21, 2009 7:20 PM

Answers

  • The processors don't sit idle - it is not a one to one relationship.

    And you are assigning a virtual processor not a physical nor logical processor.

    What really happens under the hood is that processing time is scheduled across the group of processors.  The actual workload being processed by a virtual processor at any point in time can be on any logical processor.

    In the simplest way of thinking the virtual processor time is cycled across the available logical processors in a round-robin type of fashion.  Thus all the processing power gets used over time, and technically nothing ever sits idle.

    A virtual processor is more like processing time.  The hypervisor takes the logical processors and chunks then into processing resources that are in turn used as they are needed.
    VMware has an item called 'affinity' where a virtual processor can be said to always sit on a single core.  I have rarely heard of cases where it is implemented in an enterprise outside very high utilization VMs.

    If you need more than 4 processors for a VM then you need to consider why?  Does the application within the VM really need that?  Is it really using them?  (the same consideration that you would have on physical hardware - are all the processors being utilized, or is the application actaully single threaded).

    Brian Ehlert (hopefully you have found this useful)
    Thursday, May 21, 2009 9:40 PM
    Moderator

All replies

  • If your VM is configured to use 4 logical processors, the remaining logical processors are available for other VMs or processes.  Hyper-V handles the coordination between your settings (# of logical processors) and the mapping to actual hardware resources.

    Hope this helps answer your question,
    --Ryan
    Ryan Sokolowski | MCT, MCITP x3, MCTS x8, MCSE x2, CCNA, CCDA, BCFP
    Thursday, May 21, 2009 7:34 PM
  • Hey Ryan, thanks for the feedback!

    Let me dumb your answer down... It means that I'm correct, right? If I only have a single VM with 4 logical processors... Then the other 12 processors are idle, doing nothing? There is no way of telling Hyper-V to go and grab as many processors as it needs?

    Here is the thing, I'm setting up two identical machines (2xQuadCore with hyper-t, 32Gb RAM). One of them is going to run EBS 2008, the other one is a TS machine. We have 75 users, 100 by the end of the year.

    I want to virtualize the TS so I can move VMs around if one fo the servers suffers a critical hardware failure (I want redundancy!). Now, I know it's not going to run as fast, nor going to be able to have as many people connected... But at least the critical areas will be up and running until the server gets fixed or replaced.

    What I'm afraid of is that 4 logical processors aren't going to be enough to handle 75-100 users on a daily basis.

    So this becomes a performance vs redundancy issue.

    If I'm right then virtualizing the TS server is not the way to go (Meaning no emergency redundancy).

    So, that's my situation. What I need is the option to assign more then 4 logical processors to a VM :|

    Thanks again for your help, and any other tips you or others may have.

    Alex.
    Thursday, May 21, 2009 8:15 PM
  • The processors don't sit idle - it is not a one to one relationship.

    And you are assigning a virtual processor not a physical nor logical processor.

    What really happens under the hood is that processing time is scheduled across the group of processors.  The actual workload being processed by a virtual processor at any point in time can be on any logical processor.

    In the simplest way of thinking the virtual processor time is cycled across the available logical processors in a round-robin type of fashion.  Thus all the processing power gets used over time, and technically nothing ever sits idle.

    A virtual processor is more like processing time.  The hypervisor takes the logical processors and chunks then into processing resources that are in turn used as they are needed.
    VMware has an item called 'affinity' where a virtual processor can be said to always sit on a single core.  I have rarely heard of cases where it is implemented in an enterprise outside very high utilization VMs.

    If you need more than 4 processors for a VM then you need to consider why?  Does the application within the VM really need that?  Is it really using them?  (the same consideration that you would have on physical hardware - are all the processors being utilized, or is the application actaully single threaded).

    Brian Ehlert (hopefully you have found this useful)
    Thursday, May 21, 2009 9:40 PM
    Moderator
  • Ok. This is yet another case of "you need to know what Microsoft means by "it" to understand what "it" means". The documentation on this subject is poor at best.

    This is perfect, and is exactly what I was hopping for when I started doing research on the subject.

    Thanks.


    Alex.
    Friday, May 22, 2009 12:56 AM
  • I don't think that it is so much what Microsoft means as to what the concepts are behind the words.

    The overall concepts are similar whether it be Hyper-V, ESX, or XenServer - or any of the other type-1 hypervisors.

    Part of the issue is that very few explain how things work.  Which in your case, is what you needed to know.

    I still have my VMware training manuals from six years ago, and my Citrix WinFrame manual from 12 years ago.  Why?  Because they are less about the 'how' and more about the 'why'.  And the 'why' remains important.  I can easily find out where to click or what command to type.  But often it is more important to understand why - as I might not understand the ramifications of that action.

    There are a number of folks in forums who have a lot of pieces to that 'why' knowledge. 

    At the same time, I have seen lots of poorly written or incomplete documentation.  And I totally understand where you are coming from.

    Good luck!


    Brian Ehlert (hopefully you have found this useful)
    Friday, May 22, 2009 2:55 PM
    Moderator
  • I've been runnign some performance test.

    Machine 1:      Hyper-V with 1 VM (Windows 2008 Server no roles)
    Machine2:       Windows 2008 Server no roles

    I then installed CPU Burn-in (http://users.bigpond.net.au/CPUburn/). Then run multiple instances of CPUBi and open Windows Explorer. I stop opening instances of CPUBi the moment Windows Explorer takes more then 3 seconds to open.

    With Machine 1 I can have 5-6 CPUBi instances running at once before I get a big delay. Machine 2 allows me to have 17-18 CPUBi open before there is a big delay.

    At 1st glance it looks like M1 is able to handle only 1/3 of the CPU load when compared to M2 (Hyper-V < No Hyper-V)... But it occurs to me that maybe even though I'm comparing apples with apples, the M1 apples are 4 times bigger then the M2 apples.

    How would you guys go about testing CPU usage?

    Friday, May 22, 2009 10:03 PM
  • 1) you are not comparing apples with apples.  - you should always get better performance on bare metal than within a VM, period, end of story.

    2) where are you running CPUBurn on the Hyper-V server?  Within the VM? At the Host console?
         (remember, the windows host that you see at the console is a type of VM - that is why it is called the parent partition - dom0 in XenServer, host in ESX)

    Hyper-V is not analogous to Virtual Server or Virtual PC, it is analogous to ESX and XenServer.


    Brian Ehlert (hopefully you have found this useful)
    Friday, May 22, 2009 10:33 PM
    Moderator
  • I was expecting better bare metal performance, but not by such a large margin!
    And I'm running CPUBi within the VM (Windows 2008).

    I've been doing some research and it looks like "Hyper-V Hypervisor Virtual Processor\% Total Run Time ({instanceName})" tells me exactly what I need to know:

    "How much of your actual physical CPUs is the VM's virtual CPU using?"

    But for the life of me I can't find the "Hyper-V Hypervisor Virtual Processor" when I open perfmon... The way I understand this all I have to do is:

    - Go to the machine running the "Hyper-V Manager" (In this case a Windows Vista Bussiness laptop)
    - Star > Run > perfmon
    - Once Performance Monitor is open go to Reliability & Performance > Monitoring Tools > Performance Monitor
    - Click "Add", switch from the "local computer" to the server running Hyper-V Server 2008

    Then somewhere in there I'm going to find a bunch of new entries "Hyper-V...."

    But nada! Perhaps I'm going crazy...

    Edit:

    While I was typing that I was in the middle of rebooting the Hyper-V Server (I disabled the Hyper-V Server firewall). The "Hyper-V..." stuff now shows under perfmon. Going to play with that for a bit.

    • Edited by LeMoi Saturday, May 23, 2009 1:08 AM Update
    Saturday, May 23, 2009 1:04 AM
  • Looks like Hyper-V Hypervisor Virtual Processor only gives the info that the VM's Task Manager shows (The 4 Virtual CPUs).
    Hyper-V Hypervisor Logical Processor / %Guest Run Time on the other hand seems to show the actual logical CPU usage.

    So far I can see that indeed the Logical Processors (16 of them) and the Virtual Processors (4 of them) do not have a one-to-one relationship. But...

    No matter how many instances of CPUBi where open inside the Virtual Machine (Had 17 at some point), only 7 Logical Processors where in use at any time (7-8-9-10-11-13 & 15)... The rest of them never moved (0-1-2-3-4-5-6-12 & 14).

    Interestingly enough, of those 7 LP in use, not one of them was ever taxed to 100% for longer then a few seconds at the time.

    With only 1 instance of CPUBi running, only 5 Logical Processors would spike once in a while (9-10-11-13 & 15)

    So, if I'm reading this right a single VM running inside of a Hyper-V Server 2008 is not capable of accessing all of the Logical Processors available.

    I'm going to run a few more tests, this time running multiple applications with a small CPU footprint. I want to see if the behaviour is different or not.

    Sadly all this means that I'm not going to be able to virtualize the Terminal Services Server... So I'm back to no emergency redundancy :(

    Alex.
    Saturday, May 23, 2009 2:09 AM
  • This comment is in regards to the CPUBurn tests that you have been running.

    I have one suggestion - before you poo-poo Hyper-V in the way you have designed your tests, I would expect you to run the identical tests using ESX server, XenServer, VirtualBox, Oracle VM, VirtualIron and any other hypervisor that you can find.

    In regards to your threads moving, the virtual processors can only move when an exection finishes.  If CPUBrurn runs as a constant thread load (never pausing, never burping, never resting) then the virtual process will never cycle to another processor.  Thus the process will never be allowed to be passed to other cores.

    I am having a difficult time understanding what you are trying to accomplish.  What the desired outcome is?  What you are attempting to discover or demonstrate.

    And, I have no idea why you think that you are unable to virtualize a Terminal Server.  Folks have been doing it for years on ESX and XenServer, and continue to do it today with XenSever, ESX, and Hyper-V.  You will never acheive the same density of users on a virtual Terminal Server that you have on a physical server, therefore you will have to scale out by adding additional virtual Terminal Servers.

    From my personal experience of virtualizing Terminal Servers, in the end it comes down to the applications that are running within the users, session, and how that application behaves.  I had one application that only allowed me to have 10 users per virtualized Terminal Server.  If we excluded that application (which contained a number of 16-bit subroutines) then we could easily handle 30 users per virtual terminal server.

    Don't discount it until you actually virtualize a terminal server and load test it with the real applications.


    • Edited by BrianEhMVP, Moderator Saturday, January 09, 2010 12:36 AM removed incorrect signate due to incorrect LiveID
    Saturday, May 23, 2009 2:57 AM
  • before you poo-poo Hyper-V
    heh. poo poo... I got a kick out of that.

    Not sure why you think that's what I'm trying to do.
    I would expect you to run the identical tests using ESX server, XenServer, VirtualBox, Oracle VM, VirtualIron and any other hypervisor that you can find.
    Not sure why you think this is a Hyper-V vs ::whatever:: , either. I haven't even mention any other hypervisor. No trolls here, please look under a different bridge.
    In regards to your threads moving, the virtual processors can only move when an exection finishes.  If CPUBrurn runs as a constant thread load (never pausing, never burping, never resting) then the virtual process will never cycle to another processor.  Thus the process will never be allowed to be passed to other cores.
    I do suspect that the way CPUBi works is affecting my results (I mentioned that before). If what you say about "constant thread load " is true then it kind of explains what I'm seeing.

    However every single instance of CPUBi was opened a few minutes apart from each other. I find odd that when a new CPUBi process was open it didn't get move automatically to a different Logical Processor by Hyper-V.

    One possibility is that Hyper-V by default only assigns "x, y and z LP " to each VM, and data gets move to a different LP only when it stops or goes idle for a second. Anyone knows if this is how it works?

    Anyway, the next test I'm doing involves running tons of processes with a small CPU footprint. I'll make sure to add a pause/stop here and there.
    I am having a difficult time understanding what you are trying to accomplish.  What the desired outcome is?  What you are attempting to discover or demonstrate.
    One thing and one thing only:

    I have a Hyper-V Server with 16 LPs, if I install a single VM... Will this VM access ALL 16 LPs "at the same time " if it's required? Or is this VM only going to be able to access some of the LPs?

    So far it looks like my VM is only able to access 7 LP out of 16 at once. Processes with a smaller CPU footprint may yield a different result. We'll see.
    I have no idea why you think that you are unable to virtualize a Terminal Server.
    I have no idea why you think I think that.
    You will never acheive the same density of users on a virtual Terminal Server that you have on a physical server
    I did mention on a previous post that I do not expect the VM to have the same performance as a baremetal installation. But I do not expect the 50% performance hit I've seen so far, either.
    From my personal experience of virtualizing Terminal Servers, in the end it comes down to the applications that are running within the users, session, and how that application behaves.
    That's true for any Terminal Server, not only the virtualized ones :)
    Don't discount it until you actually virtualize a terminal server and load test it with the real applications.
    I haven't! The goal is to gain the redundancy that having two Hyper-V servers offers, but at the end of the day performance > redundancy (See my second post)

    Alex.
    Saturday, May 23, 2009 5:30 AM
  • I have a Hyper-V Server with 16 LPs, if I install a single VM... Will this VM access ALL 16 LPs "at the same time " if it's required? Or is this VM only going to be able to access some of the LPs?

    So far it looks like my VM is only able to access 7 LP out of 16 at once. Processes with a smaller CPU footprint may yield a different result. We'll see.

    I figured it's time for an update:

    So far every single test I've run comes back with the same results. This time as I mentioned before I've been using processes with a small CPU footprint (Various scripts and macros).

    I'm yet to see my VM use more then 7 LPs (Out of 16 available). I paid closer attention to the data/graphs, and it looks like at the end it ends up being a 1-to-1 relationship of sorts.
    On the one hand the VM "uses" more then 4 LPs, but on the other hand they never remain at 100% for more then a few "ticks"... So really at any time you don't have more then 4-5 LPs running at a 100%.

    I still want the added redundancy that having two Hyper-V server offers, so I'm going to deploy as it is in hopes that the TS Server is going to be able to handle a real office load... I'm also hoping that you guys are right, and that I'm getting the results I'm getting because my tests are flawed.

    Luckily I can do a progressive deployment (That is move only a few people at the time). This will let me examine how the LPs are used in the real world, and I'll be able to reverse the deployment and do a baremetal TS installation if necessary.

    Alex.
    • Edited by LeMoi Friday, June 05, 2009 12:25 AM Typos.
    Friday, June 05, 2009 12:22 AM
  • Virtualization gives the ability to quickly scale out (not up).

    And, in regards to Terminal Services, your mileage will vary by leaps and bounds.
    there is no magic bullet, there is no magic number, folks have been virtualizing terminal servers for years now and there is a lot of experience.

    Your experience in virtualizing a Terminal Server is all about the applications running inside that Terminal Server VM.
    there are many cases of virtualization not providing the performance that is deisred, due to the way an application is written - everything works great on hardware, but not in a VM.  The VM runs great until application X is loaded. etc.

    This is where the hard science of hardware ends and the soft art of monitoring, troubleshooting, and manging the user experience begns.

    I know of many old Citrix XenApp folks (WinFrame, MetaFrame, Presentation Server, etc.) including myself that have been running Terminal Services cine before there was "Terminal Services" (WinView and WinFrame on NT 3.51) and I can tell you that it is more art in troubleshooting, asking questions, and making judgement calls than a science.

    You will never be able to predict how a system will scale until you install it and then load test it with simulated or real users.  Only then will you truely have an idea of your potential capacity or design.

    Brian Ehlert (hopefully you have found this useful)
    • Proposed as answer by Sergey Nudnov Friday, January 08, 2010 6:07 PM
    Friday, June 05, 2009 3:38 PM
    Moderator
  • Hello all,

    Dear MVP and MSFT guys, so far you were not able to explain LeMoi's findings that a virtual machine cannot use all CPUs of physical machine.
    It looks like Ryan's answer was the most informative and correct here.

    Forgetting about virtual machine's any roles like Terminal Server or whatever, let me ask again: we have a physical server with 2x Quad Core HT CPUs, and we have a single virtual machine configured for 4x Virtual Processors. Will be all cores of physical CPUsUsers Medals used for this virtual machine?

    Conditions to consider:
    1. License level of a physical server and of a virtual machine: web, standard, enterprize, etc.
    2. Real CPU cores versus hyperthread processors - will Hyper-V make any differences between HT processors within one core?

    Thank you.

    Sincerely,
    Sergey
    Friday, January 08, 2010 6:21 PM
  • the short answer is:  Yes, all of your cores do get used.
    The problem is the test.  Since CPUBurn never stops and therefore never releases a thread the process never moves, becuase there is no break point int he process for the thread to be moved by the underlying system.

    In regular use threads are created and torn down, and new threads are spawned - it is the spawning of new threads that allows these to be round-robin'd amond the available resources.

    I have attempted to describe this visually here:
    http://itproctology.blogspot.com/2009/12/hypervisor-virtualization-basics.html

    You also mention hyperthreading.  With a hypervisor - don't count hyperthreading as an increase in available CPU processors.  The hypervisor focuses on Cores.
    Hyperthreading only mattered to an OS that is install on the hardware (it was designed for apps) - there is a hypervisor underneith the parent partition and it deals directly with the cores, not the logical processing set of hyperthreading.
    Brian Ehlert (hopefully you have found this useful)
    Saturday, January 09, 2010 12:34 AM
    Moderator
  • Heres some interesting vids if your new to hyper-v. It explains how to processor is utilized by visualization.

    http://itproctology.blogspot.com/2009/12/hypervisor-virtualization-basics.html

    BrianEh:  There is a video that specifically discusses how CPU sharing works.

    Sunday, April 18, 2010 7:55 PM
  • Dear Brian,

    I am sure all of the cores do get used because the hypervisor will allocate processes to the cores in turn.

    But I am wondering how the VM client will see these cores as processers.

    I mean when a VM client is assigned 4 virtual processors, this VM Client OS will see only 4 processors and at any one time, this client OS can only handle 4 processes in parallel at a maximum, right? (At a client level, the VM Client OS will not know whether these 4 processors are virtual or logical or physcial cores...)

    So, if the VM Client OS is already handling 4 processes, a 5th request will need to wait till one of the 4 running processes ended. At such waiting time, any available cores at the host level cannot help because the VM client OS can only see 4 processors and can only handle 4 processes at one time. 

    On the other hand, if this same OS is installed directly on the physical machine with 2xQuadCore for example, it will be presented 8 processers (make it simple and forget about HT here). As long as this OS can support 8 processers, this OS will be able to handle 8 processes in parallel at one time. And the potential performance will be very different from the situation when it is only presented with 4 processers as a VM.

    Is my reasoning correct?

     

    Dear LeMoi,

    How is (or was) your progressive deployment?

    How do you decide on performance vs. redundency tradeoff?

    I face a similiar situation now - not really Terminal Service but it is about XenApp...

    Some people say XenServer may match better for XenApp project. But it seems to me Hyper-V is a better choice in general.

     

    Best Regards

    Andrew

     

    Thursday, July 15, 2010 4:39 PM
  • Andrew:

    A VM is limited ot the number of virtual processors that the hypervisor is able to present and manage for that particular VM.

    All hypervisors have limits regarding the amount of the physical resources that a VM can see.  Today, most hypervisors cap the number of virtual processors a VM can use to 8 (probably soon to advance to 16).  This is irregardless of the number of virtual processors that a particular hardware combination can support as a total.

    Your reasoning is very close.  But there are some details that outline why a VM performance (in general) is lower than the same workload installed on baremetal.  It does not have to do with the number of processors but it has to do with thread handling.

    A virtual processor is (essentially) a thread itself - thus adding an additional layer of thread handling.

    Terminal Servers (XenApp included) are extremely thread intensive - the big crux is a process called context switching - this is the overhead of the OS switching from processing one thread to processig the next thread in line.

    In a virtualized environment this thread processing happens in the OS of the VM as well as at the hypervisor level.  You take out the hypervisor and you get better throughput by removing a layer of thread processing (and therefore a layer of costly context switching).  The end result is a better user experience on bare metal - this is just most easily experienced with Terminal Services.

    The highest user density per server will always be on bare metal.  Running in a VM forces you to do two things:  Test the applications in the TS VM - some applications really perform poorly in a Terminal Server VM.  Have more TS servers in your farm - scale out with fewer users per server.

    Hyper-V vs. XenServer for Terminal Services.  Well.....  I do work for Citrix and I am very familiar with both hypervisors.  XenServer has a tuning flag specific to the needs of the Terminal Services workload.  Beyond that, these two hypervisors are extremely similar in how they work - their managment experience is very different.


    Brian Ehlert (hopefully you have found this useful)
    Thursday, July 15, 2010 6:06 PM
    Moderator
  • BrianEh-

    Thanks for the information from what I can tell in your comment above. If I assign 4 virtual processors, the VM will only every have 4 logical processors available to use (these 4 logical processors use round-robin for the work load, but the maximum will always be 4 logical processors). So to your question, "If you need more than 4 processors for a VM then you need to consider why?" I would answer YES I would like to give my virtual machine all the processing power I can give it. I purchased 2 x Quad Core with a total of 8 logical processors; take the following for example:

    I purchased a license of SQL with a 2 processor license; if this were in a NON Virtual environment I would have 8 logical processors available.

    I now virtualized the same machine with 4 virtual processors; would I now only have the processing power of 4 logical processors?

    If this is true then from what I can see is that original question from 'LeMoi' is true.


    phanf
    Thursday, September 09, 2010 8:30 PM
  • I think that the clarification needs to be made between "all of your cores will get used" and "all of your cores will be used at the same time".

    A virtual machine with 4 virtual processors will not be able to fully utilize a physical computer with 16 cores.

    On such a configuration there will always be ~12 cores idle (okay - bit really because Hyper-V will do some stuff in the parent partition - so this will be more like ~11 cores idle).

    Hyper-V will move the load on the physical cores around in the way that makes the most sense - so over time all the cores will be used / can be used - but the virtual machine will not get any magic performance benefit in the configuration when compared to a similar system with say 8 physical cores.


    Cheers,
    Benjamin Armstrong
    ============================
    Windows Virtualization
    Senior Lead Program Manager

    This posting is provided AS IS with no warranties, and confers no rights. You assume all risk for your use.
    Thursday, September 09, 2010 8:45 PM
    Owner
  • Ben,

    Thanks for your response, I now have a clear understanding of how virtual processors work. Does Microsoft have a road map to future improvements with Hyper-V like increased memory limits and virtual processors? Could you provide links?


    phanf
    Thursday, September 09, 2010 11:01 PM
  • Ben,

    Sorry to muddy the waters some more, but I have a somewhat different scenario I wanted to implement.  I have a new host server with 2 quad core processors.  My original plan was to create a "small" server with 2 VP/ 2GB RAM to host a VM running a domain controller.  Workload on the DC is typically very low.  I then planned to devote the remaining VPs and RAM (total 6GB) to an application server to provide the best performance I could.  It looks like this scenario is not viable under either Hyper-V or ESX because they both limit a VM to 4 VPs.  Am I missing something?

    Wednesday, November 17, 2010 11:27 PM
  • One of the big concepts that you are missing is that more processor does not equal better performance - especially when it comes to virtual machines.

    Experience with ESX, XenServer, and Hyper-V has shown that you can frequently set a VM to use far fewer resources and it will perform just as well as the same system installed on hardware.

    Now, your mileage will vary with the workload of course.

    Personally, if your DC workload is very low, why give it 2 vCPUs?  Why not begin with one and wait and see if you need to assign more?  the same applies with your applicaiton server.

    Do you really need more than 4 processors in the VM?  Do you really know?

    2 quad core processors = 8 cores = 64 vCPUs (using the conservative 8 vCPU per core planning number).

    So you have a very large resource pool that can be divided far more than into 2 VMs.

    Also, remember that the fewer VMs you have the better the VM will perform as the hypervisor can swap the workload around a lot faster.

    Now, the workload matters.  There are workloads that don't virtualize well.  In some cases it is he application, in others it is the system as a whole.  This is generally not known until attempted.

    This is where testing might prove that two VMs with 2 vCPUs will provide higher performance and throughput than a single VM with 4 or 8 vCPUs.  Again, it depends on the application.

     


    Brian Ehlert (hopefully you have found this useful) http://ITProctology.blogspot.com
    Thursday, November 18, 2010 1:30 AM
    Moderator
  • Hi,

    I have a scenario where i have developers working.
    I have 16 Cores available on the Hyper-V
    My plan was to migrate one of our development server from Physical to Virtual and setup another one on the Hyper-V
    2 VM 8 Cores to begin with.

    We have to 13 developers working on the servers and they are compiling applications and debugging so it takes a lot of processing power
    I believe that 4 cores is not enough and would not like to take the chance to migrate without the ability to extend to 8 Cores if needed.

    The reason i would like to have the development servers running on Hyper-V is to make the servers not bound to physical hardware and the ability to use my resources better.
    Also the plan is to move/upgrade project from one server to another(upgrading OS and Development environment)

    My Question is simple : Does Microsoft intend to remove / extend the 4 CPU limitation in Hyper-V for VMs and if so when?

     

    Tuesday, November 23, 2010 2:47 PM
  • My Question is simple : Does Microsoft intend to remove / extend the 4 CPU limitation in Hyper-V for VMs and if so when?

    UP
    bumblebee
    Wednesday, March 09, 2011 2:51 PM
  • I was looking for an answer and am dumb founded why :

    1.  Users have a problem if they have a VM that needs more than 4 logical CPUs

    2.  A VM that thinks it has 4 CPUs and schedules accordingly will some how generate enough concurrently running threads to use more than 4 CPUs.

    3.  A hypervisor will run a VM (concurrently) on more CPU's than the VM is configured to use.

    I think Hyper-V  is a great product and I'm glad to see the inprovements in W2K8 R2 SP1, but other virtualization products offer at least 8 logical CPUs per VM.  While migrating an OS from older, slower computers might not have an issue, transitioning to virtualized servers for high performance is also highly desired for ease of migration, hardware upgrade and recovery.  Intel is now offering 8 cores with 16 hyper-threads per processor, making 32-64 logical CPUs in one server.

    There are scalability issues as VMs use more logical CPUs. Even bare metal hosts have issues.  NUMA architecrures for one. However, I hear users asking for the ability to use the scaling and determine the limits for there specific applications and deployment.  Since other hypervisor solutions enable more logical CPUs per VM, I think that Mcrosoft should add it to the Hyper-V product and let us know when it will be available.

     

     

    Sunday, March 27, 2011 3:45 PM
  • My Question is simple : Does Microsoft intend to remove / extend the 4 CPU limitation in Hyper-V for VMs and if so when?

    UP
    bumblebee

    +1 

    this becomes to be a problem and serious limitation. We are considering to move to Vmware only becouse Hyper-V has limit 4 cores per VM. With current standard 6 core CPU we just have no options to scale applications and effectively use hardware resourses. 

    just provide all of us the answer to simple question ? does MS have any plan in short/long  time  perspectives to remove/increase this limitation?


    Tuesday, October 11, 2011 9:21 AM
  • this becomes to be a problem and serious limitation. We are considering to move to Vmware only becouse Hyper-V has limit 4 cores per VM. With current standard 6 core CPU we just have no options to scale applications and effectively use hardware resourses. 

    just provide all of us the answer to simple question ? does MS have any plan in short/long  time  perspectives to remove/increase this limitation?


    Hi!

    MS has officially announced that the Hyper-V (A.K.A Hyper-V "V3") included in upcoming Windows "8" server will support at least 16 virtual CPU's.

     The source of this information can be found on the Hyper-V Product Team official blog, here:

    http://blogs.technet.com/b/virtualization/archive/2011/08/01/beware-the-vmware-memory-vtax-plus-good-news-for-hyper-v.aspx

     

    "Greater than 16 virtual processors within a Hyper-V VM. We are keenly aware that our customers want more virtual processors within a virtual machine to support large scale up workloads and the new version goes above and beyond in addressing that need. I demoed a 16-virtual-processor virtual machine under heavy load. I pointed out that 16 virtual processors is not the maximum number of virtual processors. It was simply the largest server I was able to ship for the demo. As for support for more virtual processors, I’ll just say, “Stay Tuned” for some good news."



    When will this be available? Well, there is no release date officially announced on any of it. The next version of Hyper-V is assumed to be made available whenever Windows "8" is released. There are some wild guesses flying around the internet that this will occur somewhere in Q2 2012.

    (My personal guess is that there will be coming betas and release candidates pretty soon)

    Tuesday, October 11, 2011 9:34 AM