Thanks for the response, so it looks like its a "fractional CPU" maybe bad terminology, but still the right thing. In the example with 2 - 2.0 GHz CPUs and limiting to 3.0 GHz, we are effectivl...
See more...
Thanks for the response, so it looks like its a "fractional CPU" maybe bad terminology, but still the right thing. In the example with 2 - 2.0 GHz CPUs and limiting to 3.0 GHz, we are effectivly specifying 1.5 CPUs usage. When you're managing CPU capacity for your hosts, there are two separate kinds: (1) the ratio of virtual CPUs (vCPUs) to physical CPUs (pCPUs) and (2) the amount of GHz available. The first affects the CPU scheduler on the host and helps determine if VMs will contend with each other for physical cores. Note that this sort of contention can (and does) take place even if the amount of GHz being consumed is very small. In the scenario where you have 2 vCPUs allocated with a 3 GHz limit, it would only be effectively 1.5 CPUs in the case of GHz capacity, but it would still be the equivalent of 2 CPUs when it comes to your vCPU:pCPU ratio. Otherwise, I'm not sure why you specify reason # 2 : If you have a VM that starts consuming all its allocated CPU and starts to impact the performance of other virtual machines. CPU limits can be created and removed instantly, without having to power off the VM. because you wouldn't allocate 2 CPUs if you did not intend for the VM to need and be able to use them. I would then expect to use SHARES to determine how the contention should be handled. For the second use case, people allocate more CPU than they need all the time (often by a significant amount); I'm betting your environment has situations like this. Heck, 1 vCPU is often to much for some applications, but it's the least you can do. In some cases, a VM may only need 100 MHz, but performs better with 2 vCPUs because it's a multi-threaded application. Now, let's look at an average scenario where you have 50 vCPUs allocated on a host that only has 24 cores (2x 6 core procs with hyperthreading). This is often a very safe and normal CPU ratio. However, if you have a VM on the same host with 4 vCPUs (no limit) that gets a runaway app causing the CPU usage to jump from 300 MHz to 8 GHz, suddenly 4 of your cores get tied up by that one app. To make matters worse, those 4 cores are hyperthreaded, so you've effectively reduced your number of cores by 8. To do some quick, on-the-fly damage control, you could slap a CPU limit on the VM, throttling it back so it isn't so much a "noisy neighbor" for the other VMs. In regards to shares, they'll do a good job at making sure your VMs are not starved for GHz. However, in 90-95% of cases (including the one above), GHz isn't the bottleneck - it's the vCPU:pCPU ratio that starts causing problems. You'll encounter the same thing with DRS. DRS would look at the host, see it has plenty of GHz available, and not pay attention to the vCPU:pCPU ratio. Hopefully, this helps. Let me know if you have more questions.