RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 757768 - Huge memory usage with gnome-shell VM
Summary: Huge memory usage with gnome-shell VM
Keywords:
Status: CLOSED DUPLICATE of bug 789417
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: beta
: 6.3
Assignee: Markus Armbruster
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-28 16:36 UTC by David Jaša
Modified: 2013-01-10 00:34 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-13 14:34:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
qemu-kvm log (5.67 KB, text/plain)
2011-11-29 17:39 UTC, David Jaša 		no flags Details
qemu-kvm log (6.35 KB, text/plain)
2011-11-29 17:41 UTC, David Jaša 		no flags Details
output of valgrind --tool=memcheck --leak-check=yes (615.10 KB, text/plain)
2011-11-29 17:43 UTC, David Jaša 		no flags Details
spice communication dump (6.82 MB, text/plain)
2011-11-29 17:47 UTC, David Jaša 		no flags Details
qemu-kvm log (3.55 KB, text/plain)
2011-12-01 17:31 UTC, David Jaša 		no flags Details
output of valgrind --tool=memcheck --leak-check=full --track-origins=yes (3.89 MB, text/plain)
2011-12-01 17:32 UTC, David Jaša 		no flags Details
spice communication dump (4.24 MB, application/x-xz)
2011-12-01 17:34 UTC, David Jaša 		no flags Details
Show Obsolete (4) View All

Description David Jaša 2011-11-28 16:36:03 UTC 
Description of problem:
SSIA

Version-Release number of selected component (if applicable):
spice-server-0.8.2-5.el6.x86_64
qemu-kvm-0.12.1.2-2.209.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. install fedora 17 in a VM
2. log into gnome shell
3. watch VM usage of host memory
4. launch some window and move it back and forth
  
Actual results:
in host memory monitor, you can clearly see that each window movement takes 10-20 MB of host memory

Expected results:
memory usage of qemu-kvm process should remain +- constant

Additional info:
* can not provide valgrind output because of bug #757728 (I'll try workaround suggested by BaseOS QE colleague to get it soon)
Comment 2 Uri Lublin 2011-11-29 09:08:33 UTC 
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.
Comment 3 David Jaša 2011-11-29 16:02:49 UTC 
(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.
Comment 4 Uri Lublin 2011-11-29 16:41:41 UTC 
(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.
Comment 5 David Jaša 2011-11-29 17:39:36 UTC 
Created attachment 538147 [details]
qemu-kvm log
Comment 6 David Jaša 2011-11-29 17:41:57 UTC 
Created attachment 538148 [details]
qemu-kvm log
Comment 7 David Jaša 2011-11-29 17:43:24 UTC 
Created attachment 538149 [details]
output of valgrind --tool=memcheck --leak-check=yes
Comment 8 David Jaša 2011-11-29 17:47:58 UTC 
Created attachment 538157 [details]
spice communication dump
Comment 9 David Jaša 2011-12-01 17:31:26 UTC 
Created attachment 539309 [details]
qemu-kvm log
Comment 10 David Jaša 2011-12-01 17:32:36 UTC 
Created attachment 539311 [details]
output of valgrind --tool=memcheck --leak-check=full --track-origins=yes
Comment 11 David Jaša 2011-12-01 17:34:01 UTC 
Created attachment 539312 [details]
spice communication dump
Comment 12 David Jaša 2011-12-02 08:42:05 UTC 
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.
Comment 13 David Jaša 2011-12-05 11:05:42 UTC 
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
Comment 15 David Blechter 2012-01-23 20:01:21 UTC 
close WONTFIX
rhel does not support Fedora guests, F17 was not released yet
Comment 19 Alon Levy 2012-02-13 11:00:00 UTC 
(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?
Comment 20 Vladimir Benes 2012-02-29 14:56:00 UTC 
it doesn't matter whether it's spice/qxl or vnc/vga ..
Comment 21 Dor Laor 2012-03-13 08:31:06 UTC 
Markus, can you please check whether this guests knocks on some qemu leak?
Comment 22 Markus Armbruster 2012-03-13 09:39:49 UTC 
Smells just like bug 789417.  Please retest with qemu-kvm-0.12.1.2-2.228.el6 or later to make sure.
Comment 23 David Jaša 2012-03-13 14:34:00 UTC 

*** This bug has been marked as a duplicate of bug 789417 ***
Note You need to log in before you can comment on or make changes to this bug.