Bug 521755 - virt-manager doesn't fully support CPU overcommit
Summary: virt-manager doesn't fully support CPU overcommit
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager
Version: 5.4
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-08 07:41 UTC by Christopher Curran
Modified: 2012-10-15 22:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-07 20:59:17 UTC


Attachments (Terms of Use)

Description Christopher Curran 2009-09-08 07:41:24 UTC
Description of problem:
KVM supports CPU overcommit in RHEL5.4, virt-manager only supports this for up to 4 times the number of physical processor cores. This number should not be arbitrary or it should be modifiable by the user. 

Version-Release number of selected component (if applicable):
5.4

How reproducible:
all instances

Steps to Reproduce:
1. create a new VM
2. when you get to the CPU allocation part it states the maximum is 4 times higher but does not provide the number presently used or a way to exceed this.
  
Actual results:
virt-manager doesn't fully support KVM overcommit.

Expected results:
Instead of displaying a false maximum (as the real maximum is much higher now), display the present number of used VCPUs.

Additional info:
The maximum doesn't actually do anything with a KVM system. It doesn't error or stop the user doing anything silly.

The memory message at the top about overallocation is not true for KVM (and should probably be changed). This may be a separate issue, in which case I can file another bug.

The CPU graph also goes haywire with overcommitted CPUs. I managed to get it to create a slope while remaining at 100% (using virsh to start VMs in succession).

Comment 1 Cole Robinson 2010-01-20 22:07:02 UTC
Not done for 5.5, deferring to 5.6

Comment 3 Cole Robinson 2010-04-07 20:59:17 UTC
Hmm, the number that virt-manager lists as the 'Maxmimum virtual CPUs' is the max supported hypervisor value we get from libvirt. It's not based on how many logical/physical cpus are present on the host. AFAIK, the max cpus KVM supports in RHEL5 is 16, and qemu refuses to run if more are specified.

The overallocation message is kind of bogus, I agree: it doesn't exist anymore upstream. We can probably just change the message to say 'may cause out-of-memory errors', but I don't think it's really even worth it (figuring that it would invalidate all translations, etc.)

As far as the graph issue, I can't reproduce any weirdness: things seem to top out fine at 100%. So I'm closing this WORKSFORME. If you can still reproduce with latest RHEL, can you answer the following:

Is the weirdness on an individual VM CPU graph, or the host row CPU graph? Can you take a screenshot of the weirdness? If you run virt-manager --no-fork from the command line, are any errors printed to the console?


Note You need to log in before you can comment on or make changes to this bug.