Description of problem: Do evict memory for windows guest, then restart guest, memory will become initiate value(max vm) Version-Release number of selected component (if applicable): virtio-win-1.1.8-0 How reproducible: always Steps to Reproduce: 1.Boot guest with virtio balloon /usr/libexec/qemu-kvm -m 2048 -smp 2 -cpu qemu64,+x2apic -usb -device usb-tablet,id=input0 -drive file=/home/win08r2.s1.qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,mac=0a:00:34:3F:20:1A,bus=pci.0,addr=0x5 -uuid f25687ba-e2b3-4179-a2aa-5fc4aa0fc051 -chardev socket,id=monitor1,path=/tmp/monitor,server,nowait -mon chardev=monitor1,mode=control -name win7-32-53 -vnc :1 -boot c -device virtio-balloon-pci,bus=pci.0,addr=0x3 -monitor stdio 2.Install virtio balloon driver, and install balloon service, and restart guest 3.Check balloon info (qemu) info balloon balloon: actual=2048,mem_swapped_in=1040 4.Do evict memory (qemu) balloon 1024 5.query balloon memory info for about 520 times 6.Check balloon info again (qemu) info balloon balloon: actual=1024,mem_swapped_in=0 7.Do system restart in guest or using system_reset from monitor 8.Check balloon info after guest boot ok (qemu) info balloon balloon: actual=2046,mem_swapped_in=0 Actual results: Memory become max. Expected results: The memory should be the value before restart Additional info:
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. **
That's works-as-designed. This is the restriction of the balloon feature.
(In reply to comment #3) > That's works-as-designed. This is the restriction of the balloon feature. Hi, Dor This issue does not exist on rhel guest. This issue does not exist when using virt manager run windows guest, and from libvirt log, I see it is querying balloon info continuously after restart, and memory reduce 2M on each query, then memory become value we set. So I did query balloon for about 520 times after step8, the value become I set in step 4.
Did virt-manager was executing another balloon inflate request after the reboot? Without such, maybe qemu saves the value of the balloon. Hmm, I wasn't aware of that. Not even sure that's a good idea. Anyway, mgmt should be able to work through it. Let's postpone to the next release.
I tested that with Linux guest and indeed the balloon stays inflated post reboot. Windows should probably do the same.
Please try with the latest drivers: http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.19/
Change the status to MODIFIED so Vadim can help to add this bz to errata 2011:10808. Then we can change back to ON_QA.
Verified on 8 guests with the following packages, passed: qemu-kvm-0.12.1.2-2.147.el6 kernel-2.6.32-117.el6.x86_64 seabios-0.6.1.2-3.el6 vgabios-0.6b-3.5.el6 RHEL6.1-20110210.1
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-2011-0782.html