2019-03-30 02:40:11 +00:00
|
|
|
|
+++
|
|
|
|
|
title = "FAQ"
|
|
|
|
|
weight = 1000
|
|
|
|
|
+++
|
2019-03-30 04:09:15 +00:00
|
|
|
|
|
2019-04-14 22:43:24 +00:00
|
|
|
|
### What operating systems are supported?
|
|
|
|
|
|
2019-04-16 22:44:35 +00:00
|
|
|
|
gVisor requires Linux {{< required_linux >}} ([older Linux][old-linux]).
|
2019-04-14 22:43:24 +00:00
|
|
|
|
|
|
|
|
|
### What CPU architectures are supported?
|
|
|
|
|
|
|
|
|
|
gVisor currently supports [x86_64/AMD64](https://en.wikipedia.org/wiki/X86-64)
|
|
|
|
|
compatible processors.
|
|
|
|
|
|
|
|
|
|
### Do I need to modify my Linux application to use gVisor?
|
|
|
|
|
|
|
|
|
|
No. gVisor is capable of running unmodified Linux binaries.
|
|
|
|
|
|
|
|
|
|
### What binary formats does gVisor support?
|
|
|
|
|
|
|
|
|
|
gVisor supports Linux
|
|
|
|
|
[ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) binaries.
|
|
|
|
|
Binaries run in gVisor should be built for the
|
|
|
|
|
[AMD64](https://en.wikipedia.org/wiki/X86-64) CPU architecture.
|
|
|
|
|
|
|
|
|
|
### Can I run Docker images using gVisor.
|
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
Yes. Please see the [Docker Quick Start][docker].
|
2019-04-14 22:43:24 +00:00
|
|
|
|
|
2019-09-10 00:06:36 +00:00
|
|
|
|
### Can I run Kubernetes pods using gVisor.
|
2019-09-05 18:13:59 +00:00
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
Yes. Please see the [Docker Quick Start][k8s].
|
2019-09-05 18:13:59 +00:00
|
|
|
|
|
|
|
|
|
### What's the security model?
|
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
See the [Security Model][security-model].
|
2019-09-05 18:13:59 +00:00
|
|
|
|
|
2019-04-14 22:43:24 +00:00
|
|
|
|
## Troubleshooting
|
|
|
|
|
|
2019-03-30 04:09:15 +00:00
|
|
|
|
### My container runs fine with `runc` but fails with `runsc`
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
|
|
|
|
If you’re having problems running a container with `runsc` it’s most likely due
|
|
|
|
|
to a compatibility issue or a missing feature in gVisor. See
|
2019-10-18 06:40:54 +00:00
|
|
|
|
[Debugging][debugging].
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
2019-07-10 17:38:53 +00:00
|
|
|
|
### When I run my container, docker fails with: `open /run/containerd/.../<containerid>/log.json: no such file or directory`
|
2019-05-31 11:27:24 +00:00
|
|
|
|
|
|
|
|
|
You are using an older version of Linux which doesn't support `memfd_create`.
|
|
|
|
|
gVisor requires Linux {{< required_linux >}} ([older Linux][old-linux]).
|
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
This is tracked in [bug #268](https://gvisor.dev/issue/268).
|
2019-05-31 11:27:24 +00:00
|
|
|
|
|
2019-03-30 04:09:15 +00:00
|
|
|
|
### When I run my container, docker fails with: `flag provided but not defined: -console`
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
You're using an old version of Docker. See [Docker Quick Start][docker].
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
2019-03-30 04:09:15 +00:00
|
|
|
|
### I can’t see a file copied with: `docker cp`
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
|
|
|
|
For performance reasons, gVisor caches directory contents, and therefore it may
|
|
|
|
|
not realize a new file was copied to a given directory. To invalidate the cache
|
|
|
|
|
and force a refresh, create a file under the directory in question and list the
|
|
|
|
|
contents again.
|
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
As a workaround, shared root filesystem can be enabled. See [Filesystem][filesystem].
|
2019-04-03 19:18:46 +00:00
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
This bug is tracked in [bug #4](https://gvisor.dev/issue/4).
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
|
|
|
|
Note that `kubectl cp` works because it does the copy by exec'ing inside the
|
2019-04-03 19:18:46 +00:00
|
|
|
|
sandbox, and thus gVisor's internal cache is made aware of the new files and
|
|
|
|
|
directories.
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
2019-07-10 17:38:53 +00:00
|
|
|
|
### I'm getting an error like: `panic: unable to attach: operation not permitted`
|
|
|
|
|
|
|
|
|
|
Make sure that permissions and the owner is correct on the `runsc` binary.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
sudo chown root:root /usr/local/bin/runsc
|
|
|
|
|
sudo chmod 0755 /usr/local/bin/runsc
|
|
|
|
|
```
|
|
|
|
|
|
2019-09-05 18:13:59 +00:00
|
|
|
|
### My container cannot resolve another container's name when using Docker user defined bridge
|
2019-03-30 02:40:11 +00:00
|
|
|
|
|
2019-09-10 00:06:36 +00:00
|
|
|
|
This is normally indicated by errors like `bad address 'container-name'` when
|
|
|
|
|
trying to communicate to another container in the same network.
|
|
|
|
|
|
2019-09-05 18:13:59 +00:00
|
|
|
|
Docker user defined bridge uses an embedded DNS server bound to the loopback
|
|
|
|
|
interface on address 127.0.0.10. This requires access to the host network in
|
|
|
|
|
order to communicate to the DNS server. runsc network is isolated from the
|
2019-09-10 00:06:36 +00:00
|
|
|
|
host and cannot access the DNS server on the host network without breaking the
|
|
|
|
|
sandbox isolation. There are a few different workarounds you can try:
|
2019-09-05 18:13:59 +00:00
|
|
|
|
|
|
|
|
|
* Use default bridge network with `--link` to connect containers. Default
|
|
|
|
|
bridge doesn't use embedded DNS.
|
|
|
|
|
* Use [`--network=host`][host-net] option in runsc, however beware that it will
|
|
|
|
|
use the host network stack and is less secure.
|
|
|
|
|
* Use IPs instead of container names.
|
|
|
|
|
* Use [Kubernetes][k8s]. Container name lookup works fine in Kubernetes.
|
2019-04-16 22:44:35 +00:00
|
|
|
|
|
2019-10-18 06:40:54 +00:00
|
|
|
|
[security-model]: /docs/architecture_guide/security/
|
2019-04-16 22:44:35 +00:00
|
|
|
|
[old-linux]: /docs/user_guide/networking/#gso
|
2019-09-05 18:13:59 +00:00
|
|
|
|
[host-net]: /docs/user_guide/networking/#network-passthrough
|
2019-10-18 06:40:54 +00:00
|
|
|
|
[debugging]: /docs/user_guide/debugging/
|
|
|
|
|
[filesystem]: /docs/user_guide/filesystem/
|
|
|
|
|
[docker]: /docs/user_guide/quick_start/docker/
|
|
|
|
|
[k8s]: /docs/user_guide/quick_start/kubernetes/
|