|
|||||||||||||||||||
Solaris Virtualization Product Overview 1. Introduction to Solaris Resource Management 2. Projects and Tasks (Overview) 3. Administering Projects and Tasks 4. Extended Accounting (Overview) 5. Administering Extended Accounting (Tasks) 6. Resource Controls (Overview) 7. Administering Resource Controls (Tasks) 8. Fair Share Scheduler (Overview) 9. Administering the Fair Share Scheduler (Tasks) 10. Physical Memory Control Using the Resource Capping Daemon (Overview) 11. Administering the Resource Capping Daemon (Tasks) 13. Creating and Administering Resource Pools (Tasks) 14. Resource Management Configuration Example 15. Resource Control Functionality in the Solaris Management Console 16. Introduction to Solaris Zones Features Provided by Non-Global Zones Setting Up Zones on Your System (Task Map) 17. Non-Global Zone Configuration (Overview) 18. Planning and Configuring Non-Global Zones (Tasks) 19. About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview) 20. Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks) 21. Non-Global Zone Login (Overview) 22. Logging In to Non-Global Zones (Tasks) 23. Moving and Migrating Non-Global Zones (Tasks) 24. About Packages and Patches on a Solaris System With Zones Installed (Overview) 25. Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks) 26. Solaris Zones Administration (Overview) 27. Administering Solaris Zones (Tasks) 28. Troubleshooting Miscellaneous Solaris Zones Problems 29. About Branded Zones and the Linux Branded Zone 30. Planning the lx Branded Zone Configuration (Overview) 31. Configuring the lx Branded Zone (Tasks) 32. About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview) 33. Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks) 34. Logging In to lx Branded Zones (Tasks) 35. Moving and Migrating lx Branded Zones (Tasks) 36. Administering and Running Applications in lx Branded Zones (Tasks) 37. Sun xVM Hypervisor System Requirements 38. Booting and Running the Sun xVM Hypervisor 40. Using virt-install to Install a Domain |
How Zones WorkA non-global zone can be thought of as a box. One or more applications can run in this box without interacting with the rest of the system. Solaris zones isolate software applications or services by using flexible, software-defined boundaries. Applications that are running in the same instance of the Solaris Operating System can then be managed independently of one other. Thus, different versions of the same application can be run in different zones, to match the requirements of your configuration. A process assigned to a zone can manipulate, monitor, and directly communicate with other processes that are assigned to the same zone. The process cannot perform these functions with processes that are assigned to other zones in the system or with processes that are not assigned to a zone. Processes that are assigned to different zones are only able to communicate through network APIs. IP networking can be configured in two different ways, depending on whether the zone has its own exclusive IP instance or shares the IP layer configuration and state with the global zone. For more information about IP types in zones, see Zone Network Interfaces. For configuration information, see How to Configure the Zone. Every Solaris system contains a global zone. The global zone has a dual function. The global zone is both the default zone for the system and the zone used for system-wide administrative control. All processes run in the global zone if no non-global zones, referred to simply as zones, are created by the global administrator. The global zone is the only zone from which a non-global zone can be configured, installed, managed, or uninstalled. Only the global zone is bootable from the system hardware. Administration of the system infrastructure, such as physical devices, routing in a shared-IP zone, or dynamic reconfiguration (DR), is only possible in the global zone. Appropriately privileged processes running in the global zone can access objects associated with other zones. Unprivileged processes in the global zone might be able to perform operations not allowed to privileged processes in a non-global zone. For example, users in the global zone can view information about every process in the system. If this capability presents a problem for your site, you can restrict access to the global zone. Each zone, including the global zone, is assigned a zone name. The global zone always has the name global. Each zone is also given a unique numeric identifier, which is assigned by the system when the zone is booted. The global zone is always mapped to ID 0. Zone names and numeric IDs are discussed in Using the zonecfg Command. Each zone also has a node name that is completely independent of the zone name. The node name is assigned by the administrator of the zone. For more information, see Non-Global Zone Node Name. Each zone has a path to its root directory that is relative to the global zone's root directory. For more information, see Using the zonecfg Command. The scheduling class for a non-global zone is set to the scheduling class for the system by default. See Scheduling Class for a discussion of methods used to set the scheduling class in a zone. Summary of Zone FeaturesThe following table summarizes the characteristics of global and non-global zones.
How Non-Global Zones Are AdministeredA global administrator has superuser privileges or the Primary Administrator role. When logged in to the global zone, the global administrator can monitor and control the system as a whole. A non-global zone can be administered by a zone administrator. The global administrator assigns the Zone Management profile to the zone administrator. The privileges of a zone administrator are confined to a non-global zone. How Non-Global Zones Are CreatedThe global administrator uses the zonecfg command to configure a zone by specifying various parameters for the zone's virtual platform and application environment. The zone is then installed by the global administrator, who uses the zone administration command zoneadm to install software at the package level into the file system hierarchy established for the zone. The zoneadm command is used to boot the zone. The global administrator can then log in to the installed zone by using the zlogin command. At first login, the internal configuration for the zone is completed. For information about zone configuration, see Chapter 17, Non-Global Zone Configuration (Overview). For information about zone installation, see Chapter 19, About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview). For information about zone login, see Chapter 21, Non-Global Zone Login (Overview). Non-Global Zone State ModelA non-global zone can be in one of the following six states:
Chapter 20, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks) and the zoneadm(1M) man page describe how to use the zoneadm command to initiate transitions between these states. Table 16-1 Commands That Affect Zone State
Note - Parameters changed through zonecfg do not affect a running zone. The zone must be rebooted for the changes to take effect. Non-Global Zone CharacteristicsA zone provides isolation at almost any level of granularity you require. A zone does not need a dedicated CPU, a physical device, or a portion of physical memory. These resources can either be multiplexed across a number of zones running within a single domain or system, or allocated on a per-zone basis using the resource management features available in the operating system. Each zone can provide a customized set of services. To enforce basic process isolation, a process can see or signal only those processes that exist in the same zone. Basic communication between zones is accomplished by giving each zone IP network connectivity. An application running in one zone cannot observe the network traffic of another zone. This isolation is maintained even though the respective streams of packets travel through the same physical interface. Each zone is given a portion of the file system hierarchy. Because each zone is confined to its subtree of the file system hierarchy, a workload running in a particular zone cannot access the on-disk data of another workload running in a different zone. Files used by naming services reside within a zone's own root file system view. Thus, naming services in different zones are isolated from one other and the services can be configured differently. Using Resource Management Features With Non-Global ZonesIf you use resource management features, you should align the boundaries of the resource management controls with those of the zones. This alignment creates a more complete model of a virtual machine, where namespace access, security isolation, and resource usage are all controlled. Any special requirements for using the various resource management features with zones are addressed in the individual chapters of this manual that document those features. |
||||||||||||||||||
|