Making isolation usable: data, networking, snapshots, and warm starts
A nested microVM becomes valuable only when an application can use it without managing every low-level VM step. This chapter follows the practical ArcBox sandbox workflow: move data in and out, wait for a service without disturbing it, expose a port without publishing an untrusted workload to the LAN, and choose between a cold start, a checkpoint, a paused state, or a prewarmed template. The reader should come away able to design a useful sandbox session while seeing exactly which limits make that convenience safe and repeatable.
From isolated guest to usable session
The sandbox API treats file movement as a first-class data-plane operation. A caller can stream a file into the guest, run a command there, and stream a result back rather than relying on a host workspace mount or on a separate copy mechanism. Reads and writes have an explicit per-file limit of 256 MiB. The limit is not an arbitrary inconvenience: the service is moving bytes through a virtual-machine boundary, so an unbounded request could turn one client call into uncontrolled memory and transport pressure. Large trees need to be packaged and transferred as a bounded object, or handled through a sequence of files.
The write path also illustrates why lifecycle state matters to a seemingly simple operation. A paused sandbox has no live guest process to receive chunks. For a unary operation, the daemon can optimistically try the call, observe a paused-state response, resume the sandbox once, and retry. A client-streaming upload is different: once chunks have been consumed, the server cannot replay the original stream by itself. ArcBox checks the sandbox state before consuming the file data, resumes first when needed, and only then bridges the incoming chunks to the guest agent. The ordering protects both the caller's bytes and the meaning of auto-resume.
Inside the guest, the agent provides path operations such as stat, list, directory creation, removal, move, and directory watching. The host API receives typed results and errors rather than having to interpret a shell command's output. Symlinks are reported as symlinks, directory watches can be recursive, and an event overflow is surfaced as an error that tells the caller to re-list and watch again. Those details keep the file surface honest: it is a bounded guest filesystem API, not a claim that a long-lived event stream can never lose information.
A service needs a second kind of coordination. The naive way to wait for a web server would be to connect repeatedly until one attempt succeeds. Those attempts can create connections that the workload never expected to accept, perturbing a test or consuming an application slot. ArcBox's WaitForPort path asks the guest agent to inspect its own TCP listen table instead. The guest checks whether something is listening on the requested port and returns when the condition becomes true or the bounded deadline expires. Readiness is observed at the point where the guest knows it, rather than inferred from side effects at the host boundary.
Port exposure then adds a controlled path from the host to the service. The mapping is conceptually: a host listener forwards to an internal relay port, which is translated inside the guest toward the sandbox's address and requested port. The host-side runtime binds sandbox exposures to loopback. That choice is deliberate.