Max Speed of a VM on Multi-Core System

[robertn]

I'm looking for a quick clarification of speed allocation to VM's. If I have an ESX host that has 2 quad core cpu's at 3ghz/core I have 24ghz of speed in there (I know the reality is a good deal less). If I allow a "1 CPU" VM to have "unlimited" allocation of processing power will it have the ability to run at 3ghz (1 core), 12ghz (1 physical CPU) or 24hgz (everything)?

Obviously in any of the cases the real power is nothing close to that basic math, but hopefully you get the idea of what I'm asking; does the VM have access to the full capabilities of the underlying physical box?

Robert

[admin · Accepted solution]

The will run at the maximum speed of one core per vCPU - so in your example 1 vCPU = 3Ghz, 2 vCPU = 6Ghz, etc.

In reality a 2 vCPU won't be 6GHz, it'll be 2 x 3Ghz - so it'll only be faster than a 1vCPU VM if your application is written to take advantage of SMP.

[robertn]

Ah, I see. So there will be a 1:1 correlation between physical core and virtual cpu. In this example then 12 VM's with 1vCPU each would be similar to 12 3Ghz physical boxes (ignoring sharing of disk, bus, nic, etc.). That means then that the quad-core units are great for a Host filled with bunches of little 1vCPU machines but would not be too good for a couple of VM's that need some hefty processing power. In that case using fewer but faster pCPUs would be best, right?

[esiebert7625]

Unlimited is a very mis-leading term when it comes to setting resource allocation for cpu and memory. As Alex states a VM can never use more megahertz then the maximum of one cpu/core. If a VM has 2 vCPU's it can never use more megahertz then the maximum of each cpu/core. So "unlimited" really should be thought of as limited to maximum speed of a cpu/core and for memory it should be thought of as the maximum memory assigned to the VM. Even if you select unlimited for memory a VM can never use more memory then it has assigned to it. You can read more about this in the below links...

Resource Management in Vmware ESX Server 3 - http://download3.vmware.com/vmworld/2006/tac9726.pdf

Resource Management Guide - http://www.vmware.com/pdf/vi3_301_201_resource_mgmt.pdf

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

[esiebert7625]

It's a little more complicated then that. vCPU's are not mapped directly to pCPU's unless you use affinity which you should generally not do. The ESX Scheduler handles finding free physical CPU's to give to each VM based on need. So a VM will generally not be using the same physical cpu/core all the time, it will be using on whatever one is free at the time of it's needs. The below papers have some good info on that.

ESX Server 3 Ready Time Observations - http://www.vmware.com/pdf/esx3_ready_time.pdf

ESX Server CPU Scheduling - http://www.vmware-tsx.com/download.php?asset_id=39

Evaluation of ESX Server under CPU Intensive Workloads - http://www.windley.com/docs/2006/OIT%20Report%20Sept06.pdf

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

[admin]

Basically, yes. Read Eric's links for a much more in depth explanation for how it works though.

[robertn]

Thanks very much. That's given me a great insight and a lot of references for details.

[mreferre]

>That means then that the quad-core units are great for a Host filled with bunches of little 1vCPU machines but would not be too good for a couple of VM's that need some hefty processing power. In that case using fewer

> but faster pCPUs would be best, right?

That would be the theory. Anyway ... this is where the world is heading to (i.e. more little cores rather than few big ones) and also ... Remember that ESX really shines at collapsing many low profile workloads on top of a limited set of processors. As soon as you get into the "how do I get the max for my vm out of this piece of hw" all the weaknesses starts to come out (overhead, business case etc etc)

Having this said .... your theory is sound.

Massimo.