Bug 749191

Reproduced on F15, F16 and rawhide"
2.6.40.6-0.fc15.x86_64
3.1.0-1.fc16.x86_64
3.1.0-0.rc10.git0.1.fc17.x86_64

+++ This bug was initially created as a clone of Bug #748885 +++

Description of problem:
cpuset is incorrectly set for libvirt after resume from S3 sleep, causing all vcpus compete on single physical core/thread

Version-Release number of selected component (if applicable):
libcgroup-0.37-3.el6.x86_64

How reproducible:
always

Steps to Reproduce:
0. set up libvirt on multi-core box
1. run:
# cat /cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; pm-suspend ; echo resumed ; cat /cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; service cgconfig restart ; service libvirtd restart ; sleep 3 ; cat /cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus
  
Actual results:
0-3
0-3
0-3
resumed
0-3
0
0
Stopping cgconfig service:                                 [  OK  ]
Starting cgconfig service:                                 [  OK  ]
Ukončuji démona libvirtd:                                  [  OK  ]
Spouštím libvirtd démona:                                  [  OK  ]
0-3
0-3
0-3

Expected results:
after resume, all files should allow all cores to be used:
[snip]
resumed
0-3
0-3
0-3
[snip]

Additional info:

--- Additional comment from jsafrane on 2011-10-25 16:32:19 CEST ---

Libcgroup does not touch libvirt's cpuset.cpus, these cgroups are managed by libvirt itself.

--- Additional comment from berrange on 2011-10-25 16:39:22 CEST ---

IMHO this looks like a kernel bug. Suspend should be transparent to userspace apps like libvirt. If they have setup a specific cgroups configuration, that configuration should not be changed when the kernel suspends/resumes.

--- Additional comment from djasa on 2011-10-26 01:56:19 CEST ---

Applies to Fedora 15 as well:

# cat /sys/fs/cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; pm-suspend ; echo resumed ; cat /sys/fs/cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; service cgconfig restart ; service libvirtd restart ; sleep 3 ; cat /sys/fs/cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; uname -r
0-3
0-3
0-3
resumed
0-3
0
0
Restarting cgconfig (via systemctl):                       [  OK  ]
Restarting libvirtd (via systemctl):                       [  OK  ]
cat: /sys/fs/cgroup/cpuset/cpuset.cpus: No such file or directory
cat: /sys/fs/cgroup/cpuset/libvirt/cpuset.cpus: No such file or directory
cat: /sys/fs/cgroup/cpuset/libvirt/qemu/cpuset.cpus: No such file or directory

2.6.40.6-0.fc15.x86_64


In addition, Fedora's cgroups don't survive the cgconfig service restart. I'll verify on F16 (and clone the bug if it occurs) in short time too.

--- Additional comment from jsafrane on 2011-10-26 08:36:30 CEST ---

(In reply to comment #3)
> In addition, Fedora's cgroups don't survive the cgconfig service restart. I'll
> verify on F16 (and clone the bug if it occurs) in short time too.

This is expected, we're working on it. Open a new bug, if you wish to track its progress.