[libvirt] [PATCH 00/18] Re-arrange the way cgroups are setup

This is a greatly expanded version of a previous series I posted https://www.redhat.com/archives/libvir-list/2013-March/msg01373.html Currently libvirt creates a cgroups hiearchy at $LOCATION-OF-LIBVIRTD/libvirt/{qemu,lxc}/$GUEST-NAME eg /sys/fs/cgroup ├── blkio │   └── libvirt │   ├── lxc │   │   └── busy │   └── qemu │   └── vm1 ├── cpu,cpuacct │   ├── libvirt │   │   ├── lxc │   │   │   └── busy │   │   └── qemu │   │   └── vm1 │   │   ├── emulator │   │   └── vcpu0 │   └── system │   ├── abrtd.service │ ....snip.... │   └── upower.service ├── cpuset │   └── libvirt │   ├── lxc │   │   └── busy │   └── qemu │   └── vm1 │   ├── emulator │   └── vcpu0 ├── devices │   └── libvirt │   ├── lxc │   │   └── busy │   └── qemu │   └── vm1 ├── freezer │   └── libvirt │   ├── lxc │   │   └── busy │   └── qemu │   └── vm1 ├── memory │   └── libvirt │   ├── lxc │   │   └── busy │   └── qemu │   └── vm1 ├── net_cls ├── perf_event This series changes it so that libvirt creates cgroups at /system/$VMNAME.{qemu,lxc}.libvirt and allows configuration of the "resource partition" (ie the "/system" bit) via the XML. So we get a layout like this: /sys/fs/cgroup ├── blkio │   └── system │   ├── demo.lxc.libvirt │   └── vm1.qemu.libvirt ├── cpu,cpuacct │   └── system │   ├── abrtd.service │ ....snip.... │   ├── demo.lxc.libvirt │ ....snip.... │   └── vm1.qemu.libvirt │   ├── emulator │   └── vcpu0 ├── cpuset │   └── system │   ├── demo.lxc.libvirt │   └── vm1.qemu.libvirt │   ├── emulator │   └── vcpu0 ├── devices │   └── system │   ├── demo.lxc.libvirt │   └── vm1.qemu.libvirt ├── freezer │   └── system │   ├── demo.lxc.libvirt │   └── vm1.qemu.libvirt ├── memory │   └── system │   ├── demo.lxc.libvirt │   └── vm1.qemu.libvirt ├── net_cls ├── perf_event Flattening out the libvirt created hiearchy has serious performance wins, due to poor kernel scalability with deep hierarchies. It also makes it easier to configure system wide policy for resource usage across system services and virtual machines / containers, since they all live at the top level in comon resource partitions.