4.5 KiB
Executable File
title | permalink | layout | category | weight |
---|---|---|---|---|
FAQ | /docs/user_guide/FAQ/ | docs | User Guide | 90 |
What operating systems are supported?
Today, gVisor requires Linux.
What CPU architectures are supported?
gVisor currently supports x86_64/AMD64 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 binaries. Binaries run in gVisor should be built for the AMD64 CPU architecture.
Can I run Docker images using gVisor?
Yes. Please see the Docker Quick Start.
Can I run Kubernetes pods using gVisor?
Yes. Please see the Kubernetes Quick Start.
What's the security model?
See the Security Model.
Troubleshooting
My container runs fine with runc
but fails with runsc
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
Debugging.
When I run my container, docker fails with: open /run/containerd/.../<containerid>/log.json: no such file or directory
You are using an older version of Linux which doesn't support memfd_create
.
This is tracked in bug #268.
When I run my container, docker fails with: flag provided but not defined: -console
You're using an old version of Docker. See Docker Quick Start.
I can’t see a file copied with: docker cp
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.
As a workaround, shared root filesystem can be enabled. See Filesystem.
This bug is tracked in bug #4.
Note that kubectl cp
works because it does the copy by exec'ing inside the
sandbox, and thus gVisor's internal cache is made aware of the new files and
directories.
I'm getting an error like: panic: unable to attach: operation not permitted
or fork/exec /proc/self/exe: invalid argument: unknown
Make sure that permissions and the owner is correct on the runsc
binary.
sudo chown root:root /usr/local/bin/runsc
sudo chmod 0755 /usr/local/bin/runsc
I'm getting an error like mount submount "/etc/hostname": creating mount with source ".../hostname": input/output error: unknown.
There is a bug in Linux kernel versions 5.1 to 5.3.15, 5.4.2, and 5.5. Upgrade to a newer kernel or add the following to /lib/systemd/system/containerd.service
as a workaround.
LimitMEMLOCK=infinity
And run systemctl daemon-reload && systemctl restart containerd
to restart containerd.
See issue #1765 for more details.
My container cannot resolve another container's name when using Docker user defined bridge
This is normally indicated by errors like bad address 'container-name'
when
trying to communicate to another container in the same network.
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 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:
- Use default bridge network with
--link
to connect containers. Default bridge doesn't use embedded DNS. - Use
--network=host
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. Container name lookup works fine in Kubernetes.