Bug 484314 - virt-manager produces backtrace when setting domain memory
virt-manager produces backtrace when setting domain memory
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager (Show other bugs)
5.3
All Linux
medium Severity high
: ---
: ---
Assigned To: Cole Robinson
Virtualization Bugs
:
: 483529 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-05 19:37 EST by Rafael Godínez Pérez
Modified: 2009-12-14 16:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:42:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rafael Godínez Pérez 2009-02-05 19:37:41 EST
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 14:33:51 EST
*** Bug 483529 has been marked as a duplicate of this bug. ***
Comment 3 Cole Robinson 2009-03-23 15:36:03 EDT
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 13:09:21 EDT
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 07:59:55 EDT
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 08:07:05 EDT
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 05:42:35 EDT
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

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