Solaris Zones: what the global zone controls and how kernel zones differ from non-global zones

What it is

The instance of Solaris running directly on the hardware (or on a hypervisor's virtual hardware) is the global zone. Everything else is a non-global zone: an isolated runtime environment created and administered from the global zone. A kernel zone is a special kind of non-global zone that runs its own separate kernel and operating system image, independent of the global zone's kernel — closer to a lightweight virtual machine than to a container.

Why it matters

Zones are Solaris's built-in isolation and consolidation mechanism, comparable in intent to Linux containers but administered as a first-class OS feature rather than a set of namespaces assembled by a separate tool. Except for simple listing and help operations, zone administration commands only work from a user operating in the global zone and require the appropriate authorization, so an agent working inside a non-global zone has a deliberately narrower view and narrower privileges than one in the global zone.

How to apply

• See what is defined and what is running: zoneadm list -cv lists every configured zone (-c) with verbose detail (-v), including zones that are configured but not installed.
• Define or change a zone's configuration: zonecfg -z <zonename> opens the zone's configuration; inside it, subcommands such as create (default template SYSdefault; create -t SYSsolaris-kz for a kernel zone), property set commands, verify and commit create and persist the definition.
• Move a configured zone through its lifecycle with zoneadm -z <zonename> install, then zoneadm -z <zonename> boot.
• Get an interactive shell inside a running zone: zlogin <zonename>; connect to its console instead — available once the zone is installed, and useful before or during boot — with zlogin -C <zonename>, and leave the console with ~. on a new line (over SSH, ~~., since SSH consumes a single ~. and drops your own session).
• Decide kernel zone versus non-global (solaris-brand) zone by what is needed: a kernel zone can run an Oracle Solaris release, Support Repository Update, or kernel version different from the host, but needs hardware virtualization support visible to the global zone (virtinfo must list kernel-zone as supported; older SPARC systems need a firmware update, and on x86 inside a VM nested virtualization must be exposed) plus the kernel-zone brand package (brand-solaris-kz) and memory dedicated to it; a non-global zone shares the global zone's kernel and is administered as part of it.

Pitfalls

• Trying to run most zoneadm/zonecfg subcommands from inside a non-global zone: they require the global zone and appropriate authorization, so scripts meant to run "everywhere" need a zonename check first (see the orientation article in this series).
• Confusing a zone that is configured (zoneadm list -c) with one that is installed or running; only -c guarantees visibility of zones that were defined but never installed.
• Mixing up patching: solaris-brand zones are linked images kept in sync with the global zone, so a pkg update in the global zone updates them too (their zone BEs follow the global BE), whereas a kernel zone runs its own kernel and is updated with pkg update from inside it, independently of the global zone.