locked
vCPUs & Licensing RRS feed

  • Question

  • I have a host with dual CPU, each 6 cores and HT enabled. So during the setup of my VM I can set up to 24 vCPUs. I did read up on this whole vCPU thing and my understanding is that x vCPUs means that a maximum of x threads from my VM can run simultaneously on the physical CPUs. So let's say I assign 4 vCPUs to my VM. This means a maximum of 4 threads from my VM can run at the same time on the physical VM. As mentioned above, my host has a total of 24 cores (counting HT). This means my VM can consume a maximum of 4/24 = 17% of the physical CPU power available. Is this understanding correct?

    Assuming I understood the above correctly, then in order to not waste physical CPU power (I only have two VMs, hence they could use max 34%) I could simply increase the number of vCPUs to the full 24 and have hyper-v allocate resources between the host and 2 VMs. However, that means my Server 2012 R2 Standard sees 24 CPUs while the licensing only allows 2 CPUs. So how can I take full advantage of the physical CPU power without getting in trouble with licensing?

    Monday, December 15, 2014 5:34 PM

Answers

  • Don't over think this.

    The rule of thumb you are referencing is old.  As each core has multiple execution threads and each one of these threads is a potential vCPU.

    Does hyperthreading double this?  That is debatable.

    Back to execution threads.  Long ago (before 2008 when Hyper-V was new, and longer ago when VMware gave guidance on this) there was guidance that a core had 8 execution threads, thus 8 vCPU per core.  In 2008 that ranged between 8 and 12.

    Since then the algorithms for CPU sharing and chipsets have advanced and it is rare to even find published numbers.  Not to mention that faster processors make this number mostly irrelevant today.

    one vCPU cannot be mapped to any one physical core nor CPU thread in default configurations.  As a vCPU is simply time on the CPU, nothing more.

    Complicate this more with the fact that not all workloads scale linearly to simply adding additional vCPU.  Some really don't use more than 1, thus adding 2 makes the VM run better but adding 4 does nothing.  It all depends on the workload in the VM.  You can assign 100 vCPU to each VM (nothing stops you), but that still does not mean that you will use all of your CPU processing power.

    In the vast majority of cases, you will run into a storage limit prior to CPU.  So the common advice today is to not over-think vCPU and not lose sleep over the allocation as there are more critical limits to consider.

    If it makes you sleep better at night to do the math and allocate the vCPU in this way, then by all means do it.  However, don't obsess over performance counters that end up not showing that you are using all of your physical CPU, or that you have room for more VMs (you can never have only one or two..)


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.

    • Proposed as answer by Eric SironMVP Monday, December 15, 2014 6:41 PM
    • Marked as answer by Elton_Ji Monday, December 22, 2014 3:20 AM
    Monday, December 15, 2014 5:49 PM
  • Brian's post is really good, although I don't think I understand what he means about "8 execution threads" on a CPU. But, since it's old stuff, it's probably academic at this point. I can certainly concur that I don't know anyone that spends a significant amount of time mathing up CPU on new Hyper-V hosts.

    One place I would amend his post is to add a comment on software vendor support. Some vendors will absolutely insist that you architect their server applications in a virtual environment to use 1-to-1 mapping. I have yet to see more than a handful of them than really need anything close to that, but it's no fun to call support with something as relatively benign as a printing error and hear "UNSUPPORTED CONFIGURATION BYE >>click<<". If you've got one of those vendors, the best way to meet their demands is through CPU reservations and/or vCPU weights. But as far as actual CPU cycle consumption, Brian is dead-on. Most of the builds I've seen are completely out of RAM before their 90th-percentile CPU usage passes 20%.

    As for the licensing question, Windows Server guest operating systems are not directly licensed at all (don't confuse this with the need to enter keys or provide KMS info -- licensing and keys are different concepts). Guests fall under the guest virtualization rights that come with the license(s) that you assign to their host(s). Those physical OSE licenses are by socket(s), not core(s). Your best point of reference for licensing questions is the authorized reseller that you buy your Windows Server licenses from. You can also contact Microsoft directly.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent blog contributor, not an Altaro employee. I am solely responsible for the content of my posts.

    • Marked as answer by Elton_Ji Monday, December 22, 2014 3:20 AM
    Monday, December 15, 2014 6:41 PM

All replies

  • Don't over think this.

    The rule of thumb you are referencing is old.  As each core has multiple execution threads and each one of these threads is a potential vCPU.

    Does hyperthreading double this?  That is debatable.

    Back to execution threads.  Long ago (before 2008 when Hyper-V was new, and longer ago when VMware gave guidance on this) there was guidance that a core had 8 execution threads, thus 8 vCPU per core.  In 2008 that ranged between 8 and 12.

    Since then the algorithms for CPU sharing and chipsets have advanced and it is rare to even find published numbers.  Not to mention that faster processors make this number mostly irrelevant today.

    one vCPU cannot be mapped to any one physical core nor CPU thread in default configurations.  As a vCPU is simply time on the CPU, nothing more.

    Complicate this more with the fact that not all workloads scale linearly to simply adding additional vCPU.  Some really don't use more than 1, thus adding 2 makes the VM run better but adding 4 does nothing.  It all depends on the workload in the VM.  You can assign 100 vCPU to each VM (nothing stops you), but that still does not mean that you will use all of your CPU processing power.

    In the vast majority of cases, you will run into a storage limit prior to CPU.  So the common advice today is to not over-think vCPU and not lose sleep over the allocation as there are more critical limits to consider.

    If it makes you sleep better at night to do the math and allocate the vCPU in this way, then by all means do it.  However, don't obsess over performance counters that end up not showing that you are using all of your physical CPU, or that you have room for more VMs (you can never have only one or two..)


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.

    • Proposed as answer by Eric SironMVP Monday, December 15, 2014 6:41 PM
    • Marked as answer by Elton_Ji Monday, December 22, 2014 3:20 AM
    Monday, December 15, 2014 5:49 PM
  • Thanks for the input Brian. I certainly don't want to ponder about these things. Ideally, I just leave things at default and let the hypervisor do all the allocations. Having said that, I don't want to have a configuration that lets more than half the physical HW sit idle. Considering this, can you clarify the following:

    You said "You can assign 100 vCPU to each VM". When I look at the VM settings, the maximum I can set is the number of physical cores the host sees (in my case 24). With your statement did you assume the host sees at least 100 cores (which is a LOT)?

    I read the following on this link: http://www.altaro.com/hyper-v/hyper-v-virtual-cpus-explained In this article it says "if I had a 24-core system and left this VM at 2 vCPUs, then it would only ever send a maximum of two threads up to the hypervisor for scheduling." So this would mean out of the 24 cores the VM would only use 2, hence 1/12 of the actual physical resources. So is this statement in that article wrong or did I misunderstand that?

    Last but not least, if I assign more than 2 vCPUs for my Server 2012 Standard will this cause a licensing issue?

    Again, I don't want to ponder on this but I simply want to make sure my 2 VMs can actually use all of the HW resources rather then letting some of these resources go to waste.

    Monday, December 15, 2014 6:39 PM
  • Brian's post is really good, although I don't think I understand what he means about "8 execution threads" on a CPU. But, since it's old stuff, it's probably academic at this point. I can certainly concur that I don't know anyone that spends a significant amount of time mathing up CPU on new Hyper-V hosts.

    One place I would amend his post is to add a comment on software vendor support. Some vendors will absolutely insist that you architect their server applications in a virtual environment to use 1-to-1 mapping. I have yet to see more than a handful of them than really need anything close to that, but it's no fun to call support with something as relatively benign as a printing error and hear "UNSUPPORTED CONFIGURATION BYE >>click<<". If you've got one of those vendors, the best way to meet their demands is through CPU reservations and/or vCPU weights. But as far as actual CPU cycle consumption, Brian is dead-on. Most of the builds I've seen are completely out of RAM before their 90th-percentile CPU usage passes 20%.

    As for the licensing question, Windows Server guest operating systems are not directly licensed at all (don't confuse this with the need to enter keys or provide KMS info -- licensing and keys are different concepts). Guests fall under the guest virtualization rights that come with the license(s) that you assign to their host(s). Those physical OSE licenses are by socket(s), not core(s). Your best point of reference for licensing questions is the authorized reseller that you buy your Windows Server licenses from. You can also contact Microsoft directly.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent blog contributor, not an Altaro employee. I am solely responsible for the content of my posts.

    • Marked as answer by Elton_Ji Monday, December 22, 2014 3:20 AM
    Monday, December 15, 2014 6:41 PM
  • All of the physical CPUs are always used (in a default configuration) the vCPU execution thread is passed from one physical execution thread to the next and cycles through all physical cores of the machine.

    From this standpoint all cores are always used.

    A single vCPU is not pinned to a single core in any way.  And by default they always float.  The number of vCPU you assign is arbitrary and should be monitored and tuned over time to maximize the performance of the application running in a particular VM.

    I have seen cases where folks give too many vCPU to a VM and actually negatively impact the performance of the VM.  This is always a possibility to consider.

    I used my numbers as examples.

    As Eric mentioned, licensing is a totally different issue.  And also different SKUs of windows actually limits the number of CPU that the OS in the VM can use.

    Lastly, unless your VMs are heavily used SQL or HPC workloads I would never expect only two VMs to actually utilize your physical CPU resources at anything near the theoretical 70% sweet spot in a workstation or server class physical machine.  Only adding and balancing additional VMs (with appropriate workloads) can get you there.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.

    Monday, December 15, 2014 7:37 PM
  • Hi hfaun,

    I would like to check if you need further assistance.

    Best Regards,

    Elton JI


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com .

    Thursday, December 18, 2014 3:51 PM