Support of --runtime=kata-runtime

[mviereck]

Coming from https://github.com/mviereck/x11docker/issues/102#issuecomment-476174494 and https://github.com/mviereck/x11docker/issues/92#issuecomment-475987619 @1138-4EB wrote:

About GUI applications and kata, did you actually try it or is there any specific reason why you think that it is not supported? I ask it because kata is expected to replace runc, so the docker run command does not change at all. Therefore, it should be possible to share an X server from the host through a TCP port. For example, sharing folders with -v works as expected.

default-runtime: nvidia default-runtime: kata-runtime

Are these possible configurations of docker daemon instead of using run option --runtime? You are right that x11docker should check for them if possible.

Yes. Precisely, I found about it because kata-runtime was set up as default in a machine I used. ATM, docker build does not support --runtime (see moby/buildkit#842), so the mechanism to change it is to modify the default and restart the daemon.

See https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file. If /etc/docker/daemon.json does not exist, just create it:

{
"default-runtime": "runc"
}

Custom example for kata-runtime installation (to keep using runc as default):

{
  "default-runtime": "runc",
  "runtimes": {
    "kata-runtime": {
      "path": "/snap/kata-containers/current/usr/bin/kata-runtime",
      "runtimeArgs": [
              "--kata-config /etc/kata/configuration.toml"
      ]
    }
  }
}

This is also explained at https://docs.nvidia.com/dgx/nvidia-container-runtime-upgrade/index.html#using-nv-container-runtime for nvidia.

Nonetheless, you can retrieve this info with docker info, so you don't need to check where it comes from:

# docker info
...
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: kata-runtime runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
init version: fec3683
Security Options:
 seccomp
  Profile: default
...

[urbandroid]

i don't trust kata, i don't trust anything that comes from intel who puts web servers in their cpus. also meltdown and spectre was not long ago. Intel CEO sold his shares way before vulnerabilities became public and he is not charged with insider trading .(which tells a lot!)

[eine]

AFAIK, unlike Intel CPUs, kata-containers is open-source and based on QEMU. So, no need to trust anyone.

[mviereck]

I did a test with kata-runtime. The container starts up, but the scripts generated by x11docker are not executed. It hangs.

Accessing the container with docker exec -ti ID bash: Running e.g. sh /x11docker/containerrootrc just hangs without an error message. The script has the desired content, i.e. --volume works. I have no idea why sh does not continue or at least fails.

[eine]

It might be worth asking the architecture committee (/cc @egernst, @sameo, @jon, @gnawux, @WeiZhang555) if they have any thoughts about this. According to https://katacontainers.io/learn/, it might required for x11docker to provide the custom startup script to the Agent, since it seems that kata-containers also runs it's own startup script.

[mviereck]

There is a comprehensive list of kata limitations: https://github.com/kata-containers/documentation/blob/master/Limitations.md

However, none of them explains why sh cannot execute a script shared with --volume and hangs instead.

[mviereck]

First success: I got a running x11docker/lxde desktop with kata-runtime.

• The sh issue was due to a shared fifo file created with mkfifo. It is used to send messages from container to host. kata seems to have an issue with shared fifo files. I can use the workaround for MSYS2 and Cygwin here.

• Also, kata seems to have issues with shared unix sockets. I can use the X over TCP solution here, similar to x11docker on Windows.

• First tests with a shared HOME folder (--home): kata seems to store files created in container in that folder, but does not recognize new files created on host in that folder.

• tini as init system does not start for unknown reasons.

So far, a basic support of kata-runtime should be possible, but will have several limitations. The issues noted above need further investigation.

[mviereck]

I have added experimental support of kata. Add option --runtime=kata-runtime to custom docker run options.

It is still a lot to check and to fix, but basically it works. Options --hostdisplay, --printer, --gpu, --alsa and --webcam can not work due to missing support of shared unix sockets and device files.

The tini issue is solved with a workaround.

There is an issue with files shared with runc and kata containers simultanously.

[mviereck]

I have added a new x11docker option --runtime. Possible values are runc, crun, nvidia and kata-runtime.

A lot of x11docker options are not possible with kata, but x11docker shows messages and uses fallbacks in that case.

[mviereck]

I gave the kata developers a note that x11docker supports it, and they like it. :-) https://github.com/kata-containers/runtime/issues/586

[eine]

Awesome. I'm really glad to hear that!

[mviereck]

GPU acceleration for kata containers is possible now with iGLX. I left a note at https://github.com/kata-containers/kata-containers/issues/3524

Example:

x11docker --runtime=kata-runtime --xorg --gpu --network x11docker/check glxspheres64