[lxc-users] Enabling real time support in containers

[Peter Steele]

On 04/05/2017 06:45 AM, Serge E. Hallyn wrote:
>   I correct in assuming LXC *does* provide a means to enable RT
> The kernel has hardcoded checks (which are not namespaced) that
> if you are not (global) root, you cannot set or change the rt
> policy.  I suspect there is a way that could be safely relaxed
> (i.e. if a container has exclusie use of a cpu), but we'd have
> to talk to the scheduling experts about what would make sense.
> (see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/core.c?id=refs/tags/v4.11-rc5#n4164
> )
>
> Otherwise, as a workaround (assuming this is the only problem you
> hit) you could simply make sure that the RT policy is correct ahead
> of time and the priority is high enough that the application is only
> lowering it, then the kernel wouldn't stop it.  Certainly that's
> more fragile.  Or you could get fancier and LD_PRELOAD to catch
> sys_setscheduler and redirect to an api over a socket to a tiny
> deamon on the host kernel which sets it up for you...  But certainly
> it would be best for everyone if this was supported in the kernel the
> right way.
>
Most of our containers do not require real time support. There are a 
couple of cases though where our software does use real time threads 
though. We originally were running under libvirt based VMs and real time 
support was not an issue in this kind of environment (it was fully 
supported). We ported our software to libvirt lxc based containers and 
with the appropriate configuration was able to get real time support 
working under this environment as well. We want to make one more 
transition now to LXC (mainly due to lack of active support for 
libvirt-lxc in CentOS). I had assumed this was simply a container 
configuration issue but your response makes me think that it's not as 
simple as that. Not sure where that leaves us.

Peter