Bug 521755

Summary:	virt-manager doesn't fully support CPU overcommit
Product:	Red Hat Enterprise Linux 5	Reporter:	Christopher Curran <ccurran>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED WORKSFORME	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	low	Docs Contact:
Priority:	medium
Version:	5.4	CC:	xen-maint
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-04-07 20:59:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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?