Bug 980929 - RFE: Port to use Systemd DBus API for creating cgroups
RFE: Port to use Systemd DBus API for creating cgroups
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2013-07-03 10:50 EDT by Daniel Berrange
Modified: 2014-06-17 20:52 EDT (History)
10 users (show)

See Also:
Fixed In Version: libvirt-1.1.1-2.el7
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-13 05:43:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of old libvirt (1.45 KB, text/plain)
2013-08-05 22:29 EDT, zhpeng
no flags Details
output of new libvirt (1.01 KB, text/plain)
2013-08-05 22:29 EDT, zhpeng
no flags Details

  None (edit)
Description Daniel Berrange 2013-07-03 10:50:03 EDT
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

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

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"

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 Berrange 2013-07-29 05:57:44 EDT
First working version posted

Comment 5 zhpeng 2013-08-05 22:28:07 EDT
And for lscgroup:

For libvirt-1.1.1-1.el7.x86_64 It's like:

For libvirt-1.1.1-2.el7.x86_64 It's like:

I'll attache the full outputs
Comment 6 zhpeng 2013-08-05 22:29:02 EDT
Created attachment 783135 [details]
output of old libvirt
Comment 7 zhpeng 2013-08-05 22:29:34 EDT
Created attachment 783136 [details]
output of new libvirt
Comment 9 zhenfeng wang 2013-11-12 04:16:06 EST
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 Berrange 2013-12-13 07:07:33 EST
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


then it is using systemd.

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


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 05:04:55 EST
Thanks for DB's response, verify this bug with the latest libvirt packet, the verify steps as following

pkg info

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 

since the cgroup use the systemd style naming, so mark this bug verifed
Comment 14 Ludek Smid 2014-06-13 05:43:49 EDT
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.