gvisor: KVM platform doesn't seem to work
First of all, what a cool project! I’m trying to use the kvm platform backend and running into an issue. I turned logging on and get the following:
I0502 09:38:41.822182 2663 x:0] ***************************
I0502 09:38:41.822305 2663 x:0] Args: [/usr/local/bin/runsc --network=host --debug-log-dir=/tmp/runsc --debug --strace --platform=kvm --root /var/run/docker/runtime-runsc/moby --log /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05/log.json --log-format json start 1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05]
I0502 09:38:41.822353 2663 x:0] PID: 2663
I0502 09:38:41.822379 2663 x:0] UID: 0, GID: 0
I0502 09:38:41.822402 2663 x:0] Configuration:
I0502 09:38:41.822432 2663 x:0] RootDir: /var/run/docker/runtime-runsc/moby
I0502 09:38:41.822456 2663 x:0] Platform: kvm
I0502 09:38:41.822483 2663 x:0] FileAccess: proxy, overlay: false
I0502 09:38:41.822518 2663 x:0] Network: host, logging: false
I0502 09:38:41.822546 2663 x:0] Strace: true, max size: 1024, syscalls: []
I0502 09:38:41.822571 2663 x:0] ***************************
D0502 09:38:41.822599 2663 x:0] Load sandbox "/var/run/docker/runtime-runsc/moby" "1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05"
D0502 09:38:41.824406 2663 x:0] Signal sandbox "1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05"
D0502 09:38:41.824445 2663 x:0] Start sandbox "1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05", pid: 2639
D0502 09:38:41.824476 2663 x:0] Executing hook {Path:/usr/bin/dockerd Args:[libnetwork-setkey 1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05 39ab48b69d8788a6b7c56f380259da7713ca1247b463b0f7317b03767a59c2bc] Env:[] Timeout:<nil>}, state: {Version:1.0.1-dev ID:1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05 Status:created Pid:2639 Bundle:/var/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05 Annotations:map[]}
D0502 09:38:41.851177 2663 x:0] Destroy sandbox "1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05"
D0502 09:38:41.851331 2663 x:0] Killing sandbox "1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05"
D0502 09:38:41.851369 2663 x:0] Killing gofer for sandbox "1570d7168cf1a1ef25052cf0433701779f9d7fa11a98c241f88b25bf1c5c8b05"
W0502 09:38:41.852246 2663 x:0] FATAL ERROR: error starting sandbox: failure executing hook "/usr/bin/dockerd", err: exit status 1
stdout:
stderr: time="2018-05-02T09:38:41-07:00" level=fatal msg="no such file or directory"
The command run was docker run --runtime=runsc hello-world
Docker version: Docker version 17.12.0-ce, build c97c6d6
I guess it’s trying to execute the hooks but the fs namespace has already been unbound?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 22 (9 by maintainers)
Commits related to this issue
- Use cni v0.7.0. (#11) Use cni v0.7.0 in the integration test. Signed-off-by: Lantao Liu <lantaol@google.com> — committed to amscanne/gvisor by Random-Liu 5 years ago
I think the common thread here is that the physical address size on these CPUs is only 36 bits. (The Core is pretty old, and it seems newer Atoms support VT-x but still have a small physical address size?) We’ll have to constrain the virtual hole punching or at least provide a better error here.