Re: [libvirt] cgroup cpuset limited by default?

On 04/16/2012 09:43 PM, Daniel P. Berrange wrote: > On Mon, Apr 16, 2012 at 06:00:22PM +0200, Marc-André Lureau wrote: >> Hi >> >> On Mon, Apr 16, 2012 at 2:32 PM, Srivatsa S. Bhat >> <srivatsa.bhat(a)linux.vnet.ibm.com&gt; wrote: >>> On 04/16/2012 05:34 PM, Marc-André Lureau wrote: >>> Did you happen to perform a suspend/resume or a hibernation/restore >>> on your computer? (Or did you do CPU hotplug manually?) >>> >>> If yes, you might be seeing the problem reported at: >>> https://bugzilla.redhat.com/show_bug.cgi?id=714271 >> >> yep, thank you very much, that seems to be the reason Thanks for the confirmation. The script below might work as a temporary workaround. > > This problem has existed for ages now. I wonder if there's a way we get get > a userspace workaround implemented. > > IIRC, pm-utils has the ability to run arbitrary shell scripts upon > restore from suspend/hibernate. We could put a temp hack in libvirt > which resets the CPU affinity in the top level libvirt cgroup. That > would at least make new VMs start with good affinity. To deal with > existing running VMs, we would need to record existing affinity > before suspend & re-store it fully afterwards which is more complicated > I don't think that would be all that complicated.. Below is a script that should do the trick, for all cases, including existing running VMs. This script is not at all specific to libvirt by the way (as the problem itself is not at all libvirt specific). It saves the cpuset configuration before suspend and restores it after resume, for all cpusets (not only the ones controlled by libvirt). Of course, it hooks onto the pm-utils mechanism, as you mentioned.