jonsilver
Contributor
Contributor

Definitions of vCPU, Reservations, Limit...

Jump to solution

I did read all of this someplace, but I can no longer find the vm docuemnt that describes it all.

So any pointers to the correct document is appreciated 0 I've spent the last 3 hours searching.

Stupid questions - But I just want to make sure that I understood

1. If I give a VM 1 vCPU and that is all that is on the 8 core machine (running at 2.5 GHz), that one

    machine is limited to 2.5 GHz processing. So I should never see the host at more than 1/8 ~ 12.5% CPU utilization.

    I thought that I read in some doc, that EXSI would give that VM more if no one else needed it.

2. Although ESXI 4.1 allows you to limit the 1 - 2.5GHz vCPU to 4000GHz, it does not make any sense to put this limit in.

    The limit would be only useful where you are tryiing to allow for fractional vCPUs - like <1 or 1.5. ??

thanks,

jon

0 Kudos
1 Solution

Accepted Solutions
jklick
Enthusiast
Enthusiast

2. Although ESXI 4.1 allows you to limit the 1 - 2.5GHz vCPU to 4000GHz, it does not make any sense to put this limit in.

    The limit would be only useful where you are tryiing to allow for fractional vCPUs - like <1 or 1.5. ??

The first part is correct. Much like memory limits, they only affect the VM if the limit is set lower than the allocation. Otherwise, the allocation already "limits" the VM.

I don't think the second part would work like that. Either a VM is using a core or it is not. For example, if you allocated two vCPUs and limited it to 3 GHz, it would still use 2 vCPUs regularly. However, if it attempted to use more than 3 GHz, then it would get limited in its consumption.

Because of both these facts, there's only two potential use cases for CPU limits that I can think up at the moment:

  1. Testing purposes. If you want to see the impact of CPU contention (CPU ready) on a virtual machine, CPU limits are great for that.
  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.
@JonathanKlick | www.vkernel.com

View solution in original post

0 Kudos
5 Replies
vmroyale
Immortal
Immortal

All of these are covered in the vSphere Resource Management Guide.

1. If I give a VM 1 vCPU and that is all that is on the 8 core machine (running at 2.5 GHz), that one

    machine is limited to 2.5 GHz processing. So I should never see the host at more than 1/8 ~ 12.5% CPU utilization.

    I thought that I read in some doc, that EXSI would give that VM more if no one else needed it.

1 vCPU = 1 core You could see higher CPU utilization across the host, but it would be from host-based processes and overheads.

2. Although ESXI 4.1 allows you to limit the 1 - 2.5GHz vCPU to 4000GHz, it does not make any sense to put this limit in.

    The limit would be only useful where you are tryiing to allow for fractional vCPUs - like <1 or 1.5. ??

I've honestly never used the CPU limit and don't find much use for it.

Brian Atkinson | vExpert | VMTN Moderator | Author of "VCP5-DCV VMware Certified Professional-Data Center Virtualization on vSphere 5.5 Study Guide: VCP-550" | @vmroyale | http://vmroyale.com
jklick
Enthusiast
Enthusiast

2. Although ESXI 4.1 allows you to limit the 1 - 2.5GHz vCPU to 4000GHz, it does not make any sense to put this limit in.

    The limit would be only useful where you are tryiing to allow for fractional vCPUs - like <1 or 1.5. ??

The first part is correct. Much like memory limits, they only affect the VM if the limit is set lower than the allocation. Otherwise, the allocation already "limits" the VM.

I don't think the second part would work like that. Either a VM is using a core or it is not. For example, if you allocated two vCPUs and limited it to 3 GHz, it would still use 2 vCPUs regularly. However, if it attempted to use more than 3 GHz, then it would get limited in its consumption.

Because of both these facts, there's only two potential use cases for CPU limits that I can think up at the moment:

  1. Testing purposes. If you want to see the impact of CPU contention (CPU ready) on a virtual machine, CPU limits are great for that.
  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.
@JonathanKlick | www.vkernel.com

View solution in original post

0 Kudos
michaelstump
Enthusiast
Enthusiast

Your second use case is a great one, for anyone who experiences run-away VMs (well, run-away applications on VMs). Better to contain the problem than let it affect performance of your other VMs.

mike

Data Center Virtualization with VMware - theeagerzero.blogspot.com
0 Kudos
jonsilver
Contributor
Contributor

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.

Yes, of course ESXI still needs to allocate the 2 CPUs but maybe it does for a shorter time slice (until the 3.0 GHz) is used up.

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.

Am I still totally missing this??

thanks again,

0 Kudos
jklick
Enthusiast
Enthusiast

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.

@JonathanKlick | www.vkernel.com