Zones

Zones are illumos’s OS-level virtualization: isolated environments that share one kernel but each have their own filesystem, process table, users, network stack, and resource limits. They predate Linux containers by years and are, in several ways, what containers grew up to imitate — with stronger isolation and first-class integration with ZFS, DTrace, and the fault management architecture.

On illumos generally zones are mature and heavily used (SmartOS runs essentially everything in zones). On solnix zones are inherited from the illumos gate, but solnix’s own declarative zone tooling is early / not yet built — only a preview image exists so far (see Introduction), let alone a solnix.zones.* module. This page describes the illumos feature and the intended solnix relevance honestly, not a shipped capability.

What a zone is

A zone is a walled-off slice of one running illumos kernel. From inside, it looks like its own machine: its own root filesystem, its own processes and PIDs, its own users and hostname, its own network interfaces. From outside (the global zone), the operator sees and controls every zone. Because all zones share the single kernel, there is no hypervisor overhead — starting a zone is closer to starting a process than booting a VM.

• Global zone — the base OS; it owns the hardware and administers all other zones.
• Non-global zones — the isolated environments you create.

Branded zones

A zone’s brand determines the userland and syscall environment it presents:

• Native (illumos/ipkg) zones — a normal illumos environment.
• LX-branded zones — present the Linux system-call interface, so most Linux binaries run unmodified on the illumos kernel. This is how illumos distributions run Linux workloads without a VM. solnix plans to pull LX support in from SmartOS — see LX-branded zones.

Isolation and integration

Zones are not just namespaces bolted on — they are wired into the rest of the platform:

• ZFS — a zone typically lives on its own dataset, so snapshots, clones, and quotas apply per zone. See ZFS storage.
• Virtual networking — Crossbow creates a virtual NIC (VNIC) per zone; the zone gets a real, isolated network stack. Put the VNICs on an etherstub for a private network between zones.
• Resource controls — CPU, memory, and process caps are enforced per zone.
• DTrace — from the global zone you can trace across zones; a zone can be granted limited DTrace on itself. See DTrace.
• SMF — each zone runs its own SMF instance and service graph. See SMF services.

Brief usage (on any illumos host)

Zone administration is zonecfg (define) then zoneadm (install / boot / manage):

pfexec zonecfg -z web        # interactively define a zone named "web"
pfexec zoneadm -z web install
pfexec zoneadm -z web boot
zoneadm list -cv             # list all zones and their state
pfexec zlogin web            # get a shell inside the zone
pfexec zoneadm -z web halt   # stop it

solnix relevance

Zones are an obvious fit for reproducible, Nix-built environments — a native zone whose entire userland is a set of /nix/store paths, created and torn down declaratively, would be the illumos analog of a NixOS container. That is a natural direction for solnix but it is not built yet: the prerequisites are a working native solnix system (the bootstrap, see How solnix is built) and an SMF module, both of which come first. Treat zones today as “a powerful illumos feature solnix will be able to exploit,” not “a solnix feature.”

Further reading

• zones(7) · zonecfg(8) · zoneadm(8) — references.
• LX-branded zones — running Linux binaries in a zone, and the solnix roadmap for it.
• Networking (Crossbow) — how per-zone networking is built.
• illumos features — zones in context with ZFS, DTrace, SMF, and FMA.
• Further reading & resources — zone administration guides.