which prevents a process associated with one zone from interacting with or observing processes in other zones. Each zone can be configured with its own separate user list. The system automatically manages user ID conflicts; that is, two zones on a system could have a user ID 10000 defined, and each would be mapped to its own unique global identifier. A zone can be in one of the following states: Configured: Configuration was completed and committed. Incomplete: Transition state during install or uninstall operation. Installed: The packages have been successfully installed. Ready: The virtual platform has been established. Running: The zone booted successfully and is now running. Shutting down: The zone is in the process of shutting down this is a temporary state, leading to "Down". Down: The zone has completed the shut down process and is down this is a temporary state, leading to "Installed". Some programs cannot be executed from within a non-global zone; typically this is because the application requires privileges that cannot be granted within a container. As a zone does not have its own separate kernel (in contrast to a hardware virtual machine), applications that require direct manipulation of kernel features, such as the ability to directly read or alter kernel memory space, may not work inside of a container. Resources needed Zones induce a very low overhead on CPU and memory. Most types of zones share the global zone's virtual address space. A zone can be assigned to a resource pool (processor set plus scheduling class) to guarantee certain usage, or can be capped at a fixed compute capacity ("capped CPU") or can be given shares via fair-share scheduling. Currently a maximum of 8191 non-global zones can be created within a single operating system instance. "Sparse Zones", in which most filesystem content is shared with the global zone, can take as little as 50 MB of disk space. "Whole Root Zones", in which each zone has its own copy of its operating system files, may occupy anywhere from several hundred megabytes to several gigabytes, depending on installed software. The 8191 limits arises from the limit of 8,192 loopback connections per Solaris instance. Each zone needs a loopback connection. The global zone gets one, leaving 8,191 for the non-global zones. Even with Whole Root Zones, disk space requirements can be negligible if the zone's OS file system is a ZFS clone of the global zone