Bug 484314

Summary: virt-manager produces backtrace when setting domain memory
Product: Red Hat Enterprise Linux 5 Reporter: Rafael Godínez Pérez <rgodinez>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 5.3CC: kvolny, lihuang, llim, qzhang, sputhenp, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 09:42:35 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 Rafael Godínez Pérez 2009-02-06 00:37:41 UTC
Description of problem:
Cannot change domU memory on virt-manager

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

How reproducible:
Always

Steps to Reproduce:
1. start a virtual machine from virsh
2. launch virt-manager from menu or console, as root
3. open virtual machine details in virt-manager
4. change memory amount in field
5. click apply
  
Actual results:
It does nothing.

Expected results:
Memory amount changed.

Additional info:
If started virt-manager from console with --no-fork option, it shows error:
[root@dom0 ~]# virt-manager --no-fork
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 525, in config_memory_apply
    if maxmem.value < curmem.value:
UnboundLocalError: local variable 'maxmem' referenced before assignment
[root@dom0 ~]# 

I've fixed this behaviour adding before the referred line this other one:

        maxmem = self.window.get_widget("config-maxmem").get_adjustment()

        if maxmem.value < curmem.value:

Probably this is only a quick and dirty  solution, but at least it works.

Comment 1 Cole Robinson 2009-02-13 19:33:51 UTC
*** Bug 483529 has been marked as a duplicate of this bug. ***

Comment 3 Cole Robinson 2009-03-23 19:36:03 UTC
Upstream never had this issue, since it was a problem with the backport. The rebased version virt-manager-0.6.1-1.el5 is not affected by this as a result. Setting to MODIFIED.

Comment 6 Cole Robinson 2009-06-29 17:09:21 UTC
I still can't reproduce. Is QA sure they are reproducing this exact bug and not other memory related issues (assuming https://bugzilla.redhat.com/show_bug.cgi?id=508266 ?)

Setting back to MODIFIED.

Comment 8 Qunfang Zhang 2009-07-10 11:59:55 UTC
Verificationin results in virt-manager-0.6.1-1.el5
Xen:
PV: Passed.The memory can be changed correctly.
FV: Failed.
Steps:
1.Force off a vm.
2.Open the vm details window.
3,Change the memory amount in field and click "Apply" button.
4.Run the vm.
5.Click the hardware tab to check the memory.
Actual result: The memory amount changes a few. For example, I configured maximum memory as 1024.But it maybe change to 1050 or other.

KVM:Failed.
Steps to Reproduce:
1.Double click the virtual machine, and open the Virtual Machine Detail window.
2.Click the Hardware tab and select “Memory”
3.Change the “Change allocation” to another number but lower than maximum
allocation, and click “Apply”.
4.Change the “Maximum allocation” to another number, and click “Apply”.

Actual results:
After step3, “Change allocation”  restores to origination.
After step 4, “Current allocation”,“Change allocation” and “Maximum allocation”
are all changed to the number I input.

Comment 9 Cole Robinson 2009-07-10 12:07:05 UTC
Please see comment #6 : I'm pretty sure the KVM issues you are seeing are related to bug 508266. Not sure about the xen bugs, but they require a separate report at least.

I've changed the bug title to be more descriptive.

Comment 13 errata-xmlrpc 2009-09-02 09:42:35 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1285.html