The branded zones facility in the Solaris Operating System is a simple extension of Solaris Zones. This chapter discusses the branded zones concept and the lx brand, which implements Linux branded zones functionality. Linux branded zones are also known as Solaris Containers for Linux Applications.Although you can configure and install branded zones on a Trusted Solaris system that has labels enabled, you cannot boot branded zones on this system configuration. See Chapter 16, Introduction to Solaris Zones for general information on the use of zones on a Solaris system.You should be familiar with the following zones and resource management concepts:The global zone and the non-global zone, described in How Zones Work The global administrator and the zone administrator, described in How Non-Global Zones Are Administered and How Non-Global Zones Are Created. The zone state model, discussed in Non-Global Zone State Model. The zone isolation characteristics covered in Non-Global Zone Characteristics. Privileges, described in Privileges in a Non-Global Zone. Networking, described in Networking in Shared-IP Non-Global Zones The Solaris Container concept, which is the use of resource management features, such as resource pools, with zones. The use and interaction of zones and resource management features are described in Using Resource Management Features With Non-Global Zones, Setting Zone-Wide Resource Controls, Chapter 26, Solaris Zones Administration (Overview), and the individual chapters in Part 1 Resource Management of this manual that document each resource management feature. For example, resource pools are covered in Chapter 12, Resource Pools (Overview) and Chapter 13, Creating and Administering Resource Pools (Tasks) The fair share scheduler (FSS), a scheduling class that enables you to allocate CPU time based on shares, is covered in Chapter 8, Fair Share Scheduler (Overview) and Chapter 9, Administering the Fair Share Scheduler (Tasks). The resource capping daemon (rcapd), which can be used from the global zone to control resident set size (RSS) usage of branded zones. The property of the zonecfg capped-memory resource sets the max-rss for a zone. This value is enforced by rcapd running in the global zone. For more information, see Chapter 10, Physical Memory Control Using the Resource Capping Daemon (Overview), Chapter 11, Administering the Resource Capping Daemon (Tasks) and the rcapd1M man page. The Glossary provides definitions for terms used with zones and resource management features.Any additional information required to use branded zones on your system is provided in this part of the guide.The following chapters in this guide are not applicable to branded zones:Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview) Chapter 25, Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks) The Solaris Zones infrastructure is documented in this manual in Part II, Zones. By default, a non-global zone has the same characteristics as operating system in the global zone, which is running the Solaris 10 Operating System or later Solaris 10 release. These native non-global zones and the global zone share their conformance to standards, runtime behavior, command sets, and performance traits in common. The branded zone (BrandZ) framework extends the zones infrastructure to include the creation of brands, or alternative sets of runtime behaviors. The term brand can refer to a wide range of operating environments. For example, the non-global zone can emulate another version of the Solaris Operating System, or an operating environment such as Linux. Or, it might augment the native brand behaviors with additional characteristics or features. Every zone is configured with an associated brand.A brand can provide a simple or a complex environment. For example, a simple environment could replace the standard Solaris utilities with their GNU equivalents. A complex environment could provide a complete Linux user space which supports the execution of Linux applications.The brand defines the operating environment that can be installed in the zone and determines how the system will behave within the zone so that the non-native software installed in the zone functions correctly. In addition, a zone's brand is used to identify the correct application type at application launch time. All branded zone management is performed through extensions to the native zones structure. Most administration procedures are identical for all zones.You can change the brand of a zone in the configured state. Once a branded zone has been installed, the brand cannot be changed or removed.BrandZ extends the zones tools in the following ways:The zonecfg command is used to set a zone's brand type when the zone is configured. The zoneadm command is used to report a zone's brand type as well as administer the zone. You can change the brand of a zone in the configured state. Once a branded zone has been installed, that brand cannot be changed or removed. Branded zones provide a set of interposition points in the kernel that are only applied to processes executing in a branded zone.These points are found in such paths as the syscall path, the process loading path, and the thread creation path. At each of these points, a brand can choose to supplement or replace the standard Solaris behavior. A brand can also provide a plug-in library for librtld_db. The plug-in library allows Solaris tools such as the debugger, described in mdb1, and DTrace, described in dtrace1M, to access the symbol information of processes running inside a branded zone. The devices supported by each zone are documented in the man pages and other documentation for that brand. Device support is defined by the brand. A brand can choose to disallow the addition of any unsupported or unrecognized devices. The file systems required for a branded zone are defined by the brand. The privileges available in a branded zone are defined by the brand. For more information about privileges, see Privileges in a Non-Global Zone and Configurable Privileges in an lx Branded Zone. The lx brand uses the branded zones framework to enable Linux binary applications to run unmodified on a machine with a Solaris Operating System kernel.The machine must have one of the following supported i686 processor types:IntelPentium Pro Pentium II Pentium III Celeron Xeon Pentium 4 Pentium M Pentium D Pentium Extreme Edition Core Core 2 AMDOpteron Athlon XP Athlon 64 Athlon 64 X2 Athlon FX Duron Sempron Turion 64 Turion 64 X2 The lx brand includes the tools necessary to install a CentOS 3.x or Red Hat Enterprise Linux 3.x distribution inside a non-global zone. Versions 3.5 to 3.8 of each distribution are supported. The brand supports the execution of 32-bit Linux applications on x86 and x64 machines running the Solaris system in either 32-bit or 64-bit mode.The lx brand emulates the system call interfaces provided by the Linux 2.4.21 kernel, as modified by Red Hat in the RHEL 3.x distributions. This kernel provides the system call interfaces consumed by the glibc version 2.3.2 released by Red Hat.In addition, the lx brand partially emulates the Linux /dev and /proc interfaces.Note that you must maintain a supported configuration if you add packages to an lx branded zone. See About Maintaining a Supported Configuration for more information. The Solaris system imposes no limit on the number of Linux applications you can run in an lx branded zone. Sufficient memory must be available. Also see System and Space Requirements.Regardless of the underlying kernel, only 32-bit Linux applications are able to run.The lx zone supports only user-level Linux applications. You cannot use Linux device drivers, Linux kernel modules, or Linux file systems from inside an lx zone.See Applications tested under the lx brand for a list of some applications that have been successfully run under the lx brand. See How to Install an Application in an lx Branded Zone for an example of installing an application.You cannot run Solaris applications inside an lx zone. However, the lx zone enables you to use the Solaris system to develop, test, and deploy Linux applications. For example, you can place a Linux application in an lx zone and analyze it using Solaris tools run from the global zone. You can then make improvements and deploy the tuned application on a native Linux system. Solaris debugging tools such as DTrace and mdb can be applied to Linux processes executing inside the zone, but the tools themselves must be running in the global zone. Any core files generated are produced in the Solaris format and can only be debugged with Solaris tools.DTrace is enabled for Linux applications by the DTrace lxsyscall dynamic tracing provider. The provider acts like the DTrace syscall provider. The lxsyscall provider provides probes that fire whenever a thread enters or returns from a Linux system call entry point.For more information on debugging options, see the Solaris Dynamic Tracing Guide, and the dtrace1M and mdb1 man pages. The Solaris Dynamic Tracing Guide describes the public documented interfaces available for the DTrace facility. The documentation about the syscall provider can be used for the lxsyscall provider.Because NFS is dependent on name services, which are zone specific, you cannot access any NFS file system that is mounted outside of the current zone. Thus, you cannot debug NFS-based Linux processes from the global zone. The commands identified in the following table provide the primary administrative interface to the zones facility.Command Reference Description zlogin1 Log in to a non-global zone zoneadm1M Administers zones on a system zonecfg1M Used to set up a zone configuration getzoneid3C Used to map between zone ID and name brands5 Provides description of branded zones facility lx5 Provides description of Linux branded zones zones5 Provides description of zones facility lx_systrace7D DTrace Linux system call tracing provider zcons7D Zone console device driver The zoneadmd daemon is the primary process for managing the zone's virtual platform. The man page for the zoneadmd daemon is zoneadmd1M. The daemon does not constitute a programming interface.Table 26–5 covers commands that can be used in the global zone to display information about all non-global zones, including branded zones. Table 26–4 covers commands used with the resource capping daemon. The following table provides an overview of the tasks that are involved in setting up lx zones on your system for the first time.Task Description For Instructions Identify each 32–bit Linux application that you would like to run in a zone. Assess the system needs of the application. Refer to your business goals and to your system documentation if necessary. Determine how many zones to configure. Assess:The number of Linux applications you intend to run. The disk space requirements for Linux branded zones. Whether you need to use a script. See Application Support, System and Space Requirements, Evaluating the Current System Setup, Script to Configure Multiple lx Branded Zones. Determine whether you will use resource pools with your zone to create a container. If you are using resource pools, configure the pools before you configure zones.Note that you can add zone-wide resource controls and pool functionality to a zone quickly by using zonecfg properties. See How to Configure the lx Branded Zone, Chapter 13, Creating and Administering Resource Pools (Tasks). Perform the preconfiguration tasks. Determine the zone name and the zone path for each zone. If network connectivity is required, obtain IP addresses. Determine the scheduling class for the zone. Determine the set of privileges that processes inside the zone should be limited to, if the standard default set is not sufficient. For information on the zone name, zone path, IP addresses, and scheduling class, see lx Branded Zone Configuration Components. For a listing of default privileges and privileges that can be configured in a non-global zone, see Privileges in a Non-Global Zone.For information on resource pool association, see How Zones Work and How to Configure the lx Branded Zone. Develop configurations. Configure non-global zones. See Configuring, Verifying, and Committing a Zone and the zonecfg1M man page. As global administrator, verify and install configured zones. Zones must be verified and installed prior to booting the zone. You must obtain a Linux distribution before you install a Linux branded zone. See Chapter 32, About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview) and Chapter 33, Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks). As global administrator, boot the non-global zones. Boot each zone to place the zone in the running state. See Chapter 33, Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks). Prepare the new zone for production use. Create user accounts, add additional software, and customize the zone's configuration using standard Linux system administration tools and methodologies from within the zone. Refer to the documentation you use to set up a newly installed machine and install applications. Special considerations applicable to a system with zones installed are covered in this guide.