Description of problem: Changing dom-U's memory abnormally. Version-Release number of selected component (if applicable): virt-manager-0.6.1-3.el5 How reproducible: 100% 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. Expected results: After step 3, the “Change allocation” and “Current allocation” should be changed. After step 4, the “Maximum allocation” should be changed properly, but “Change allocation” and “Current allocation” are constant. Additional info:
I can't reproduce. What type of guest is this? KVM, Xen FV, Xen PV? How are you changing the memory values: using the arrows or manually entering a number?
I'm sorry for poor description. The type of guest is KVM. When a virtual machine is forced off, I change the memory values. Both using the arrows and manually entering a number can reproduce this issue.
For both Xen FV and Xen PV, this issue not exists when the guest machine when not running, they always produce the expected result. When the Xen FV guest running, it works OK too. The "Maximum allocation" can be set freely and it will not effect the "current allocation", the "Change allocation" is not changeable. When the Xen PV guest running, "Maximum allocation" can be set freely and it will not effect the "current allocation". The "Change allocation" field can be set to a smaller number than the original memory number which is set at start time, but this number can not change to a larger number than original.
Okay, pretty sure this is a result of a libvirt issue that I recently fixed upstream: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=0219fc00cf3fc68eeb8446a512cc7bebb05455b6;hp=2b4bf15f61c950a208b105fe71c6e80b23459c73 Reassigning to libvirt.
Okay apparently it's a bit late in the game even for a simple patch like this and it's not a critical bug, so let's defer it to 5.5, Daniel
Link to the upstream commit (with new libvirt.git location): http://libvirt.org/git/?p=libvirt.git;a=commit;h=387935345c54c586dad323290b46fa122e52f2b0 Fix should be an easy backport.
Created attachment 377249 [details] Backport of upstream changset Patch applied cleanly (after dropping Changelog piece) and builds fine.
*** Bug 542522 has been marked as a duplicate of this bug. ***
libvirt-0.6.3-25.el5 has been built in dist-5E-qu-candidate with the fix, Daniel
This bug has been verified with libvirt 0.6.3-25.el5 on RHEL-5.5. Already fixed, set status to VERIFIED. Steps to Reproduce: 1) Run virt-manager, open an existing shutoff status guest and go to the Hardware tab 2) Click "Memory", change "Change allocation" and "Maximum allocation" field value,then click "Apply" "Current allocation" field value can change to "Change allocation" field value ,and "Maximum allocation" field value can also be changed successfully. Version-Release number of selected component (if applicable): [root@dhcp-66-70-62 ~]# uname -a Linux dhcp-66-70-62.nay.redhat.com 2.6.18-183.el5 #1 SMP Mon Dec 21 18:37:42 EST 2009 x86_64 x86_64 x86_64 GNU/Linux [root@dhcp-66-70-62 ~]# lsmod|grep kvm kvm_intel 86664 0 kvm 223648 2 ksm,kvm_intel [root@dhcp-66-70-62 libvirt]# rpm -qa|grep libvirt libvirt-python-0.6.3-25.el5 libvirt-0.6.3-25.el5 libvirt-debuginfo-0.6.3-25.el5 [root@dhcp-66-70-62 ~]# rpm -q virt-manager kvm virt-manager-0.6.1-11.el5 kvm-83-140.el5
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-2010-0205.html