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 980929 - RFE: Port to use Systemd DBus API for creating cgroups
Summary: RFE: Port to use Systemd DBus API for creating cgroups
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Daniel Berrangé
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-03 14:50 UTC by Daniel Berrangé
Modified: 2014-06-18 00:52 UTC (History)
10 users (show)

Fixed In Version: libvirt-1.1.1-2.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 09:43:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
output of old libvirt (1.45 KB, text/plain)
2013-08-06 02:29 UTC, zhpeng 		no flags Details
output of new libvirt (1.01 KB, text/plain)
2013-08-06 02:29 UTC, zhpeng 		no flags Details
View All

Description Daniel Berrangé 2013-07-03 14:50:03 UTC 
Description of problem:
systemd is taking ownership of the cgroups filesystem. To future proof libvirt it should be ported to use systemd's DBus API for creating the cgroups

All you need to invoke is one bus call:

org.freedesktop.machine1.Manager.CreateMachine() on the object
/org/freedesktop/machine1 on the service org.freedesktop.machine1:

      CreateMachine(in  s name,
                    in  ay id,
                    in  s service,
                    in  s class,
                    in  u leader,
                    in  s root_directory,
                    in  a(sv) scope_properties,
                    out o path);

name = some useful identifier. Something that feels like a filename or
so. We will escape this and use it for naming the unit (and hence
cgroup). Event though we escape it might be wise to choose something
that feels more like a file name than any arbitrary
string. i.e. "my-fedora-system" is preferable over "My Fedora System"
even though both will work. This identifier will show up in "ps" and
everywhere.

id = a UUID as BE array of bytes. This ID should identify the machine
nicely (i.e. if possibly should be the same as /etc/machine-id of the
machine). If you don't have anything nice to pass here, pass the empty
array.

service = some identifier for your client, i.e. "libvirt" or
"libvirt-lxc" or so. Free form, purely meta information. Something that
feels like a filanem might be good here too. nspawn passes "nspawn"
here...

class = either the string "container" or "vm" dependening on the class
of virtual machine you have.

leader = main PID of your VM/container, or 0, to let machined figure
that out on its own (which is really useful in case your container is in
its own PID namespace and hence doesn't know its host PID...).

root_directory = the root directory of the container, if this is known
and applicable. Otherwise empty string.

scope_properties = this is an array (not a dict!) of properties that are
passed on to PID 1 when creating a scope unit for your machine. This is
currently not fully implemented, but you will eventually be able to pass
initial settings for the cgroup and things like that via this
field. Ignore it for now, pass the empty array.

path = a bus path returned for the machine object created, in case you
want to execute further things on it.
Comment 1 Daniel Berrangé 2013-07-29 09:57:44 UTC 
First working version posted

https://www.redhat.com/archives/libvir-list/2013-July/msg01753.html
Comment 5 zhpeng 2013-08-06 02:28:07 UTC 
And for lscgroup:

For libvirt-1.1.1-1.el7.x86_64 It's like:
...
devices:/
devices:/machine.slice
devices:/machine.slice/machine-qemu\x2daaa.scope
devices:/machine
devices:/machine/aaa.libvirt-qemu
freezer:/
freezer:/machine
freezer:/machine/aaa.libvirt-qemu
freezer:/machine.slice
freezer:/machine.slice/machine-qemu\x2daaa.scope
...


For libvirt-1.1.1-2.el7.x86_64 It's like:
...
devices:/
devices:/machine.slice
devices:/machine.slice/machine-qemu\x2daaa.scope
devices:/machine
freezer:/
freezer:/machine
freezer:/machine.slice
freezer:/machine.slice/machine-qemu\x2daaa.scope
...

I'll attache the full outputs
Comment 6 zhpeng 2013-08-06 02:29:02 UTC 
Created attachment 783135 [details]
output of old libvirt
Comment 7 zhpeng 2013-08-06 02:29:34 UTC 
Created attachment 783136 [details]
output of new libvirt
Comment 9 zhenfeng wang 2013-11-12 09:16:06 UTC 
Hi, DB
Was the steps in comment 4 & 5 enough to verify this bug? if not can you please give me some sugesstion? thanks, the follwoing content just as the addtional info of the comment 4 & 5.

# mount
--
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
--
Comment 10 Daniel Berrangé 2013-12-13 12:07:33 UTC 
Basically you want to start a guest (either QEMU or LXC) and then look at /proc/$PID/cgroup

If the cgroup directory shown there is named along the lines of

   "machine-qemu\x2dmyguest.scope"

then it is using systemd.

If the cgroup directory shown there is named along the lines of

   "myguest.libvirt-qemu"

then it is using the old non-systemd method.

Obviously for this bug we want it to be using the systemd style naming.

For further examples look at this new document http://libvirt.org/cgroups.html
Comment 11 zhenfeng wang 2013-12-16 10:04:55 UTC 
Thanks for DB's response, verify this bug with the latest libvirt packet, the verify steps as following

pkg info
libvirt-1.1.1-15.el7.x86_64
kernel-3.10.0-60.el7.x86_64
qemu-kvm-rhev-1.5.3-21.el7.x86_64

steps
1.prepare a running guest
# virsh list
 Id    Name                           State
----------------------------------------------------
 13    rhel7                          running

# ps aux|grep rhel7
qemu      5641  2.3  3.9 4016016 313660 ?      Sl   17:36   0:34 /usr/libexec/qemu-kvm -name rhel7 -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024

2.Check the cgroup directory,it use the systemd style naming
# cat /proc/5641/cgroup 
10:hugetlb:/
9:perf_event:/machine.slice/machine-qemu\x2drhel7.scope
8:blkio:/machine.slice/machine-qemu\x2drhel7.scope
7:net_cls:/machine.slice/machine-qemu\x2drhel7.scope
6:freezer:/machine.slice/machine-qemu\x2drhel7.scope
5:devices:/machine.slice/machine-qemu\x2drhel7.scope
4:memory:/machine.slice/machine-qemu\x2drhel7.scope
3:cpuacct,cpu:/machine.slice/machine-qemu\x2drhel7.scope/emulator
2:cpuset:/machine.slice/machine-qemu\x2drhel7.scope/emulator
1:name=systemd:/machine.slice/machine-qemu\x2drhel7.scope

since the cgroup use the systemd style naming, so mark this bug verifed
Comment 14 Ludek Smid 2014-06-13 09:43:49 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.