Bug 757768

David, please provide more information about memory used:
How much memory is configured for the guest ?
How much memory is used when guest is idle ?

I'm not sure memory should remain constant.
As you suggested, valgrind may provide more information.

(In reply to comment #2)
> David, please provide more information about memory used:
> How much memory is configured for the guest ?
1024 MB

> How much memory is used when guest is idle ?
> 
After start, around 1,5 GB. But with every movement of windows withing guest, memory usage of host increases. Memory usage in guest remains constant.

> I'm not sure memory should remain constant.

The memory should be freed at some finite time. I was able to make qemu-kvm use 11 GB out of 12 available on the host this way. IMO, this could qualify as DoS vulnerability if we supported llvm-pipe guests.

> As you suggested, valgrind may provide more information.

I already worked the bug around so I will attach more info shortly.

(In reply to comment #3)
> 
> The memory should be freed at some finite time. I was able to make qemu-kvm use
> 11 GB out of 12 available on the host this way.

I agree. There should be no memory leak. Thanks.

Created attachment 538147 [details]
qemu-kvm log

Created attachment 538148 [details]
qemu-kvm log

Created attachment 538149 [details]
output of valgrind --tool=memcheck --leak-check=yes

Created attachment 538157 [details]
spice communication dump

Created attachment 539309 [details]
qemu-kvm log

Created attachment 539311 [details]
output of valgrind --tool=memcheck --leak-check=full --track-origins=yes

Created attachment 539312 [details]
spice communication dump

Comment on attachment 538157 [details]
spice communication dump

I've appended some infos to the logs when I was about to do anything interesting or after something interesting finished.

What's intriguing is that valgrind said exactly nothing when I was moving the window and memory usage increased by some 400 MB, so this is not technically a leak, it's rather some caching mechanism gone wild. Maybe this one:

> In addition, the drawables limit should be based on the
> drawables total size and not on their count. Additional
> limit can be based on an estimation of how much rendering
> they convey (in order to avoid too heavy update_area events).
( http://post-office.corp.redhat.com/archives/spice-list/2011-November/msg00080.html )

maybe some other.

Two more observations: 

* when vm graphics is switched to VNC and video to cirrus with 64 MB VRAM (vga with 64 MB VRAM make Xorg crash, cirrus with 64 MB requires manual editing of properties of libvirt-managed VM via virsh), the problem persists, so it might also be something in qemu

* when the guest OS restarts, the VM memory usage does not drop

close WONTFIX
rhel does not support Fedora guests, F17 was not released yet

(In reply to comment #13)
> Two more observations: 
> 
> * when vm graphics is switched to VNC and video to cirrus with 64 MB VRAM (vga
> with 64 MB VRAM make Xorg crash, cirrus with 64 MB requires manual editing of
> properties of libvirt-managed VM via virsh), the problem persists, so it might
> also be something in qemu
> 
> * when the guest OS restarts, the VM memory usage does not drop

So you get the same memory ballooning with window movement without QXL and with VNC? can you confirm and if so, move this to qemu component?

it doesn't matter whether it's spice/qxl or vnc/vga ..

Markus, can you please check whether this guests knocks on some qemu leak?

Smells just like bug 789417.  Please retest with qemu-kvm-0.12.1.2-2.228.el6 or later to make sure.

*** This bug has been marked as a duplicate of bug 789417 ***