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 613291 - guest did not honor cgroup memory.limit_in_bytes
Summary: guest did not honor cgroup memory.limit_in_bytes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Larry Woodman
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-10 14:15 UTC by Qian Cai
Modified: 2013-01-09 22:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-30 16:28:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Qian Cai 2010-07-10 14:15:28 UTC 
Description of problem:
Not sure if a bug or not using RHEL6.0-20100707.4 tree and -44.el6 kernel that the guest controlled memory usage may  go beyond the capped memory.

# mount -t cgroup -o memory none /cgroups/memory/
# cd /cgroups/memory/
# mkdir A
# cd A
# echo 256M >memory.limit_in_bytes
# ps aux | grep qemu-kvm
qemu      7444  9.0 10.4 1335288 385168 ?      Sl   16:06   3:37 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6 -uuid 32f27c50-0805-2f64-4fbe-fb0bb1b6971f -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/rhel6.img,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:21:bf,bus=pci.0,addr=0x4 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
# echo 7444 >tasks

Then ran a program inside the guest to malloc 2G and write to those memory. It still could pass, and the top from the host showed that it took more memory than it was controlled.

# top
...
7444 qemu      20   0 1914m 716m 3036 S 76.7 20.0   6:51.80 qemu-kvm  

I was also tried to set limit_in_bytes to 1500M, and allocate/touch 2G inside the guest, the result was the same. Should I expect the allocation should fail in this case?
Comment 1 Larry Woodman 2010-07-13 11:40:30 UTC 
You need to "echo $$ > tasks" just before running the program.

Larry
Comment 2 Qian Cai 2010-07-13 12:23:10 UTC 
Larry, where to run that command? I setup the cgroup in the host, and then start the malloc program in the guest. As you can see that there was no cgroup configured in the guest.
Comment 3 Qian Cai 2010-07-15 09:41:13 UTC 
I have also tried to move all KVM PIDs into the cgroup without luck.
Comment 5 Chris Lalancette 2010-07-29 20:28:35 UTC 
OK, Larry and I just tried this out, and it seems to work like it should.  There are a couple of things to note here:

1)  It looks like you started the guest via libvirt.  Did you?  If so, libvirt automatically puts all guests into a cgroup under /cgroup/memory/libvirt/qemu/<guestname>.  So one way you can run this test is to go into the pre-defined libvirt cgroup and limit the memory that way.  We tested this, and it did the right thing.

2)  If you do want to do something like in the original comment (i.e. make your own cgroup), you have to make sure that all of the threads from the qemu-kvm process get put into the new cgroup.  We also tried this out, and this also worked for us.

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