runsc checkpoint saves the full state of a gVisor sandbox to files: every
process, every open file, every socket, and the application’s memory.
runsc restore brings it back, on the same machine or on a different one, and
the applications continue as if nothing happened.
This feature is not new. gVisor could checkpoint a sandbox in 2018. But the 2018 version was slow, and some people still think of gVisor checkpoint/restore that way. A lot changed in the last few years. In our tests below, restoring a 2 GiB sandbox from a slow disk went from 5,106 ms to 939 ms, about 5 times faster, saturating the max speed of the disk. When the image is already in the host page cache, it went from 651 ms to 71 ms.
In 2018, Google open-sourced gVisor under the Apache 2.0 license. To the best of its contributors’ knowledge, it has ever since remained the second most mature implementation of Linux, after Linux.
This year, the gVisor project is being donated to CNCF, and its governance model is shifting accordingly.
As an OCI runtime, gVisor is traditionally used to sandbox application containers containing a single service. These containers have little to no userspace running in them except the service itself. While this is great for efficiency and scalability, there are some use cases that can benefit from having something closer to a full Linux system inside the sandbox, with a “normal” service manager and system daemons.
gVisor now has gained support for running systemd. To this end, support for a handful of major new kernel APIs has been added to gVisor, including:
tmpfs and overlayfs,openat2(2) system call,along with numerous smaller features and bug fixes.
Systemd has been tested to work in full-system gVisor containers with Ubuntu, Debian, and Red Hat’s Universal Base Images.
This article was contributed by Tencent. Yifeng Tan, Hua Liu, and Hui Chen are engineers at Tencent, responsible for the internal container infrastructure.
As LLMs evolve from chat interfaces to autonomous agents, building a robust and
secure isolation environment becomes a necessity. We chose
gVisor as the default sandbox for our Agentic-RL
scenarios. Today, we run millions of gVisor sandboxes daily for Agentic-RL
training in production, and that scale continues to grow. After more than
74,000 side-by-side comparisons between runsc (gVisor) and runc
(unsandboxed/Linux), combined with targeted fixes driven by real-world
workloads, we have essentially closed the execution correctness gap with runc,
fully meeting our production-grade business requirements. During this process,
we successfully investigated and resolved gVisor compatibility issues that
accounted for approximately 1.7% of all test cases.
This post focuses on CPU-centric code execution and testing workloads. We will discuss gVisor compatibility verification and highlight representative issues, skipping implementation details like GPU support, image distribution, or cluster scheduling. We aim to answer three questions:
Does gVisor work with OpenClaw? This question has been asked a lot, so let’s answer it here and now: Yes.
In this post, we will set up a triple-agent system combining OpenClaw, PicoClaw, and Hermes Agent, each in separate gVisor sandboxes, all with local inference powered by Ollama in a gVisor sandbox using three different models, convening together in a self-hosted Matrix.org server (naturally, also running in a gVisor sandbox). Each agent will be given its own set of capabilities, each of which will be sandboxed. At the end of the day, you will have a fully self-sovereign triple-agent system that can answer queries, browse the web, and cogitate with itself.
Does this particular setup make practical sense? No, but it is cool. More importantly, it demonstrates the versatility of gVisor at sandboxing basically any component that an agentic system may need. gVisor’s compatibility has grown significantly over the last few years, and agent harnesses fit well within what gVisor is capable of.