[systemd-devel] machined: after CPU offline then online, vcpupin KVM guest failed to start

[Lennart Poettering]

On Thu, 04.08.16 16:19, Cedric Bosdonnat (cbosdonnat at suse.com) wrote:

> Hi Lennart and Werner,
> 
> On Wed, 2016-08-03 at 16:56 +0200, Lennart Poettering wrote:
> > On Wed, 03.08.16 14:46, Dr. Werner Fink (werner at suse.de) wrote:
> > > problem with v228 (and I guess this is also later AFAICS from logs of
> > > current git) that repeating CPU hotplug events (offline/online). The
> > > root cause is that cpuset.cpus become not restored by machined.
> > > Please note that libvirt can not do this as it is not allowed to do
> > > so.
> > 
> > This is a limitation of the kernel cpuset interface, and it's one of
> > the reasons we do not expose cpusets at all in systemd right
> > now. Thankfully, there's an alternative to cpusets, which is the CPU
> > affinity controls exposed via CPUAffinity= in systemd, which do much
> > of the same, but have less borked semantics.
> > 
> > We'd like to support cpusets directly in systemd, but we don't do this
> > as long as the kernel interfaces are as borked as they are. For
> > example, cpusets are flushed out entirely currently when the system
> > goes through a suspend/resume cycle.
> > 
> > If libvirt has hook-ups with cpuset, then it bypasses systemd for
> > that.
> 
> I guess by CPU affinity you mean sched_setaffinity and friends. If that is
> the case, then this is constrained by cpuset too as mentioned here:
> 
> http://www.mjmwired.net/kernel/Documentation/cpusets.txt#53
> 
> As long as the machine.slice cpuset isn't restored after onlining a CPU again,
> then libvirt won't be able to set either the affinity or the cpuset if it
> contains that CPU.
> 
> May be the kernel's behaviour is weird and can be discussed, but libvirt can't
> do anything on that bug.

Yeah, to make this clear: I do not blame libvirt for this borkedness
at all. I blame the kernel.

Lennart

-- 
Lennart Poettering, Red Hat