svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
zones(7)
Standards, Environments, Macros, Character Sets, and miscellany
zones(7)
NAME
zones - Solaris operating system containers
DESCRIPTION
The zones facility in Oracle Solaris provides an isolated environment
for running applications. Processes running in a zone are prevented
from monitoring or interfering with other activity in the system.
Access to other processes, network interfaces, file systems, devices,
and inter-process communication facilities are restricted to prevent
interaction between processes in different zones.
The privileges available within a zone are restricted to prevent opera‐
tions with system-wide impact. See privileges(7).
You can configure and administer zones with the zoneadm(8) and
zonecfg(8) utilities. You can specify the configuration details a zone,
install file system contents including software packages into the zone,
and manage the runtime state of the zone. You can use the zlogin(1) to
run commands within an active zone. You can do this without logging in
through a network-based login server such as in.rlogind(8) or sshd(8).
Zones are managed by a Zones Delegated Restarter, identified by the SMF
FMRI:
svc:/system/zones:default
The autobooting of zones at system boot up depends on their autoboot
property. Conversely, zones are shut down according to their autoshut‐
down property when the global zone is gracefully shutdown. For more
information about autoboot and autoshutdown, see the zonecfg(8) man
page.
The zones delegated restarter allows control of boot order using depen‐
dencies and priorities. Throttling of concurrent state transitions is
also supported. For more information, see the svc.zones(8) man page.
An alphanumeric name and numeric ID identify each active zone. Alphanu‐
meric names are configured using the zonecfg(8) utility. Numeric IDs
are automatically assigned when the zone is booted. The zonename(1)
utility reports the current zone name, and the zoneadm(8) utility can
be used to report the names and IDs of configured zones.
A zone can be in one of several states:
CONFIGURED
Indicates that the configuration for the zone has been completely
specified and committed to stable storage.
INCOMPLETE
Indicates that the zone is in the midst of being installed or unin‐
stalled, or was interrupted in the midst of such a transition.
INSTALLED
Indicates that the zone's configuration has been instantiated on
the system: packages have been installed under the zone's root
path.
READY
Indicates that the "virtual platform" for the zone has been estab‐
lished. For instance, file systems have been mounted, devices have
been configured, but no processes associated with the zone have
been started.
RUNNING
Indicates that user processes associated with the zone application
environment are running.
SHUTTING_DOWN
DOWN
Indicates that the zone is being halted. The zone can become stuck
in one of these states if it is unable to tear down the application
environment state (such as mounted file systems) or if some portion
of the virtual platform cannot be destroyed. Such cases require
operator intervention.
UNAVAILABLE
Indicates that the zone has been installed but cannot be booted. A
zone enters the unavailable state when the zone's storage is
unavailable while svc:/system/zones:default is online or when the
zone tries to boot; when archive-based installations fail after
successful archive extraction; and when the zone's software is
incompatible with the global zone's software, such as after an
improper forced attach.
Shared Zone State
State of a zone is shared across all boot environments (BEs) on a host
system. If a state of a zone is changed, it affects all BEs no matter
which BE is currently booted. It also affects all states, including
changing the zone from being installed to configured; if a zone is
uninstalled, it is uninstalled from all BEs. The only way to recover
such a zone is from data previously backed up.
Process Access Restrictions
Processes running inside a zone (aside from the global zone) have
restricted access to other processes. Only processes in the same zone
are visible through /proc (see proc(5) or through system call inter‐
faces that take process IDs such as kill(2) and priocntl(2). Attempts
to access processes that exist in other zones (including the global
zone) fail with the same error code that would be issued if the speci‐
fied process did not exist.
Privilege Restrictions
Processes running within a non-global zone are restricted to a subset
of privileges, in order to prevent one zone from being able to perform
operations that might affect other zones. The set of privileges limits
the capabilities of privileged users (such as the super-user or root
user) within the zone. The list of privileges available within a zone
can be displayed using the ppriv(1) utility. For more information about
privileges, see the privileges(7) man page.
Device Restrictions
The set of devices available within a zone is restricted, to prevent a
process in one zone from interfering with processes in other zones. For
example, a process in a zone should not be able to modify kernel memory
using /dev/kmem, or modify the contents of the root disk. Thus, by
default, only a few pseudo devices considered safe for use within a
zone are available. Additional devices can be made available within
specific zones using the zonecfg(8) utility.
The device and privilege restrictions have a number of effects on the
utilities that can run in a non-global zone. For example, the eep‐
rom(8), prtdiag(8), and prtconf(8) utilities do not work in a zone
since they rely on devices that are not normally available.
Brands
A zone can be assigned a brand when it is initially created. A branded
zone is one whose software does not match that software found in the
global zone. The software can include Oracle Solaris software config‐
ured or laid out differently. The particular collection of software is
called a "brand" (see brands(7)). Once installed, a zone's brand can
not be changed unless the zone is first uninstalled. The solaris-kz
brand provides even more flexibility, altering many of the restrictions
mentioned in here.
File Systems
Each zone has its own section of the file system hierarchy, rooted at a
directory known as the zone root. Processes inside the zone can access
only files within that part of the hierarchy, that is, files that are
located beneath the zone root. This prevents processes in one zone from
corrupting or examining file system data associated with another zone.
The chroot(8) utility can be used within a zone, but can only restrict
the process to a root path accessible within the zone.
In order to preserve file system space, sections of the file system can
be mounted into one or more zones using the read-only option of the
lofs(4FS) file system. This allows the same file system data to be
shared in multiple zones, while preserving the security guarantees sup‐
plied by zones.
NFS and autofs mounts established within a zone are local to that zone;
they cannot be accessed from other zones, including the global zone.
The mounts are removed when the zone is halted or rebooted.
ZFS datasets that are delegated to a zone are manageable within the
zone. Within a delegated dataset, child datasets can be created.
Datasets that are created within a delegated dataset are themselves
delegated. Delegated datasets other than the top level delegated
dataset can be destroyed. Most, but not all, properties can be set on
delegated datasets. See zfs(8) for details.
Each zone has a top-level delegated dataset, which in turn contains the
ROOT and potentially other datasets such as .../export and
.../export/home. Datasets that exist under the ROOT dataset make up the
zone's boot environment(s). Boot environment datasets should only be
created or destroyed using the zoneadm(8) or beadm(8) commands.
When a zone is immutable, that is, the file-mac-profile is set to a
value other than "none", the top-level and related data sets are read-
only with certain exceptions.
Networking
A zone has its own port number space for TCP, UDP, and SCTP applica‐
tions and typically one or more separate IP addresses (but some config‐
urations of Trusted Extensions share IP address(es) between zones).
For the IP layer (IP routing, ARP, IPsec, IP Filter, and so on) a zone
can either share the configuration and state with the global zone (a
shared-IP zone), or have its distinct IP layer configuration and state
(an exclusive-IP zone).
If a zone is to be connected to the same datalink, that is, be on the
same IP subnet or subnets as the global zone, then it is appropriate
for the zone to use the shared IP instance.
If a zone needs to be isolated at the IP layer on the network, for
instance being connected to different VLANs or different LANs than the
global zone and other non-global zones, then for isolation reasons the
zone should have its exclusive IP.
A shared-IP zone is prevented from doing certain things to the network
(such as changing its IP address or sending spoofed IP or Ethernet
packets), but an exclusive-IP zone has more or less the same capabili‐
ties with respect to the network as a separate host that is connected
to the same network interface. In particular, the superuser in such a
zone can change its IP address and spoof ARP packets.
The shared-IP zones are assigned one or more network interface names
and IP addresses in zonecfg(8). The network interface name(s) must also
be configured in the global zone.
The exclusive-IP zones are assigned one or more network interface names
in zonecfg(8). The network interface names must be exclusively assigned
to that zone, that is, it (or they) can not be assigned to some other
running zone, nor can they be used by the global zone.
The full IP-level functionality in the form of DHCP client, IPsec and
IP Filter, is available in exclusive-IP zones and not in shared-IP
zones.
Host Identifiers
A zone is capable of emulating a 32-bit host identifier, which can be
configured via zonecfg(8), for the purpose of system consolidation. If
a zone emulates a host identifier, then commands such as hostid(1) and
sysdef(8) as well as C interfaces such as sysinfo(2) and gethostid(3C)
that are executed within the context of the zone will display or return
the zone's emulated host identifier rather than the host machine's
identifier.
Logging
The output of the zone's console is logged to /var/log/zones/con‐
sole.<zonename>. Other runtime information is logged to
/var/log/zones/messages.<zonename>. Each log is rotated periodically
using logadm(8).
Live Zone Reconfiguration
You can reconfigure a running zone without needing to reboot it. You
can also inspect live configuration of a running zone. zonecfg(8)
allows to retrieve and inspect the live configuration, make desired
changes, and temporarily apply them to the running zone. zonecfg(8)
allows to reconfigure the running zone persistently based on the saved
zone configuration. For more information, see zonecfg(8).
The zone configuration consists of resources and resource properties
defined in the zonecfg(8) man page. For the purpose of live zone recon‐
figuration, only resources and resource properties known to zonecfg(8),
which are also permitted by the associated brand are supported.
See brand specific manual pages for the list of resources and resource
properties supported by the live zone reconfiguration for the selected
brand. However, there are restrictions which apply to all brands.
The following resources and resource properties are not supported by
the live zone reconfiguration for all brands:
brand
zonename
zonepath
ip-type
rootzpool
Any changes made to the listed resources and resource properties will
cause the live zone reconfiguration fail if they are applied to the
running zone.
The resources and resource properties listed below do not affect the
running zone directly. For this reason, you can modify them in the per‐
sistent configuration at any time. But, any attempts to change them in
the live configuration will be refused. This applies to all brands.
admin
attr
autoboot
autoshutdown
bootargs
suspend
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Availabilitysystem/zones
SEE ALSO
attributes(7), beadm(8), brands(7), crgetzoneid(9F), gethostid(3C),
getzoneid(3C), hostid(1), in.rlogind(8), kill(2), logadm(8), prioc‐
ntl(2), privileges(7), proc(5), solaris-kz(7), sshd(8), svc.zones(8),
sysdef(8), sysinfo(2), ucred_get(3C), zfs(8), zlogin(1), zoneadm(8),
zonecfg(8), zonename(1)
Oracle Solaris 11.4 11 May 2021 zones(7)