0

According to the libvirt documentation:

A VM configured with value 2048 will get twice as much CPU time as a VM configured with value 1024.

I have also heard it said that a VM with 2 vCPUs would have twice as much CPU time as a VM with one vCPU. Is this correct? And then, does the "shares" element take that into account as well?

For example, which of these two scenarios would be correct?

  • 1 vCPU x 10 Shares = 10 Units of CPU time
  • 2 vCPU x 10 Shares = 20 Units of CPU time
  • 1 vCPU x 20 Shares = 20 Units of CPU time
  • 2 vCPU x 20 Shares = 40 Units of CPU time

Or:

  • 1 vCPU x 10 Shares = 10 Units of CPU time
  • 2 vCPU x 10 Shares = 10 Units of CPU time
  • 1 vCPU x 20 Shares = 20 Units of CPU time
  • 2 vCPU x 20 Shares = 20 Units of CPU time

Thank you for reading!

1

The "shares" tunable is counted against the VM as a whole, with vCPU count not taken into consideration. So you'd likely want to scale up the shares value as you scale up the vCPU count.

Note that this is a relative prioritization, not an absolute measure of time. As such it only really comes into effect if you have overcommit the host CPUs, such that vCPUs from different guests are contending with each other for host CPU time. So you're not really giving "NNN units of CPU time". What its saying is that in periods where 2 guests both need CPU time and not enough is free to satisfy both, the available free CPU time will be allocated to the VMs matching the ratio of shares.

  • I appreciate your extra note about only applying in times of contention. Thanks for this! – Jared Brandt May 9 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.