Solaris-Zones: Linux IT Marbles Get a New Bag

Seldom is a data center asked to do less. More often, it's asked to do more with less—fewer computers and less power consumption. One significant industry discussion for the past few years has been regarding a reduction in the number of physical servers and an increase in the application-to-server ratio to maximize server utilization. Often, this increase is done via virtualization.

At Texas Instruments (TI), we have numerous data centers and design environments that thrive on the use of Linux and Solaris. Typically, each OS is installed on individual systems stacked high and aligned in rows throughout the data center. Linux applications run on Linux; Solaris applications run on Solaris.

Recently, a new virtualization solution has emerged that enables IT professionals to combine Linux and Solaris together within one physical environment. This solution reduces the number of physical systems in the computer environment and increases server work with greater efficiency.

One of the Solaris virtualization environments is called Solaris-Zones (also known as Solaris-Containers). Through the development of Open-Solaris, Solaris-Zones has been expanded to support zone branding. Solaris-Zones now enables the creation of “lx” branded zones. The lx branded zone supports the installation and execution of the Linux OS and its applications. When lx branded zones are used in conjunction with the ZFS (Zeta-byte File System), Linux environments are able to do more, faster.

Linux always has been about technical developers and enthusiasts doing whatever moves them. The security of Solaris-Zones combined with the power of Linux opens a huge new frontier of development freedom—from the enterprise environment to the single desktop. With Solaris-Zones, it's easy to define, create, install and execute Linux (lx) branded zones.

This article introduces lx branded zones and presents the necessary tools for each step of the zone management process. Readers should have some understanding of a chroot environment and the basic concepts of virtual machines (VMs) and the features they provide. Knowledge of these concepts is not required, but it will help in conveying what a zone is and create a better platform for understanding.

So, what is a zone? A zone provides security and virtualization in a unique way. The Solaris-Zone has its own filesystem with a root directory, system files and so on, like that of the primary environment of the physical system. The private root filesystem, one per zone, gives it the ability to be fully configurable and flexible. A zone provides nearly the same experience as the main OS. In this regard, it is like a VM without the VM hardware emulation layer.

The zone is provided with an operating environment but without a private dedicated kernel. The lack of a dedicated kernel is a huge performance enhancement—when you experience the boot process, you will see how fast it is compared to a normal boot. User and administrator experience within the zone is very similar to that of a full VM in flexibility, but like a chroot environment, it sheds the overhead of a full VM.

It is important to understand that a zone is not a full virtual machine in the sense that you would see with Xen or VMware or VirtualBox. A zone is an emulation layer, more akin to Wine perhaps, but at a more fundamental level. This, for example, means that an lx branded zone does not contain its own Linux kernel; rather, the kernel calls are redirected by the zone's emulation layer to the underlying Solaris kernel.

The zone provides security through isolation. Each zone has its own root account and password. The superuser within a zone has no special privileges to gain access to objects outside the zone. No account has rights to exit the zone or examine processes and files outside the zone. Advanced resource management is enabled when control of memory and CPU resources by zone is important. Resource management keeps zones from being harmed by others, including but not limited to CPU and memory starvation.

Note: the primary Solaris OS and the physical platform on which it executes are also known as a zone. It is defined as the global zone and continues to look and feel as it always has. All other zones are created from the global zone. Created zones are called sub or non-global zones. Non-global zones cannot create zones within themselves. Figure 1 illustrates the relationship between the global zone, non-global zones and possible VMs.

Figure 1. Relationships between Zones and VMs

Solaris-Zones became available with the release of Solaris 10 (later Open-Solaris). With these early releases, only a “native” Solaris zone could be defined, installed and executed. With the August 2007 release, Solaris-Zones includes support for zone branding to allow Linux installation and execution. By default, a zone is defined as native, unless it's defined explicitly as a Linux (lx) branded zone. Once a zone is branded lx, only Linux can be installed into that zone.

The zone experience is defined by a simple command set. Each command is used to manage one of the logical divisions of the zone maintenance process. The primary divisions of zone administration are define, install and execute. The zone experience is very simple; it involves only a few commands. Two of the commands provide support for the definition, installation and setup of zones, and the other two are used for a running zone:

Use the zonecfg command to define a zone. Although it is possible to define a zone without networking, all examples presented here define zones with networking. Listing 1 shows how to define a network interface for use by an lx branded zone. With zonecfg, you can create a minimal zone definition, set the zone's name, set its installation path and type and include a network interface. A minimum definition requires only the branding, zone name and the installation path. The zonecfg command must be executed as the superuser. In the examples here, the shell prompt is used to illustrate from which zone a command is run. The initial example below indicates the shell is within the global zone and ready to “define” a non-global zone by the use of the zonecfg command.

Note: ZFS (denoted or hinted at by path names) is used for performance; however, it is not required. Feel free to use any appropriate directory path to build one or more zones.

# List the name of the current zone
g-zone# zonename
global

# Start the zone definition action and define it as "lx"
# SUNWlx is the Sun provided "lx" zone template.
g-zone# zonecfg -z red-zone
red-zone: No such zone configured
Use 'create' to begin a new zone configuration.
zonecfg:red-zone> create -t SUNWlx
zonecfg:red-zone> set zonepath=/zpool01/zones/red-zone
zonecfg:red-zone> add net
zonecfg:red-zone:net> set address=192.168.1.10
zonecfg:red-zone:net> set physical=e1000g0
zonecfg:red-zone:net> end
zonecfg:red-zone> commit  # (redundant)
zonecfg:red-zone> exit

# List defined(configured) and running zones
g-zone# zoneadm list -cv
  ID NAME       STATUS      PATH                     BRAND    IP
   0 global     running     /                        native   shared
   - red-zone   configured  /zpool01/zones/red-zone  lx       shared

Adjust the paths accordingly to match your local environment. Items to consider are zonepath and network values. Change these to match available storage, local network requirements and available network interface. The first command shows that execution is in the global zone. The zonecfg command defines the name of the zone, the installation path and network attributes. The final command lists all configured and running zones. Once a zone is defined, use the zonecfg command to update or delete a zone configuration.

Note that not all properties can be updated or added after a zone has been installed. Generally, properties with this restriction are ones related to native zone definitions, not lx branded zones. For properties that can be changed after a zone is installed, the zone should be in a halted state or rebooted to make the change active.

The first example shows the red-zone as configured. This means it is defined only (metadata created and saved). Two properties in the example can be used to illustrate updating properties of an already-defined zone: zonepath and the network attributes. Each of them can be changed while the zone is halted (not running). If a zone has been installed and the zonepath is changed, the operator is required to move the physical location of the old zonepath to the location of the new zonepath manually. In the next example (Listing 2), the directory red-zone needs to be renamed to red-zone-x under the /zpool01/zones directory to complete the property update.

We now have a defined zone. Use the zoneadm command to complete the OS installation into the zone named red-zone. The sub functions of zoneadm are related to the execution status of a zone. The install process of an lx branded zone requires Linux media. The media can be provided in a physical form and loaded into the system's CD-ROM drive, or you can use the “green” method and provide the image as one or more ISO files.

Once the zone installation is complete, it's time to boot it. Create two shells, and run the commands shown in Listing 4. Connect to the zone console first, then boot the zone in the second shell to get the full console experience (it's very fast, you'll not want to miss it). The example zlogin connects to the zone's console device and configures the escape (exit the zlogin) as the “#.” (pound sign then period) key sequence. This key sequence should be unique and avoid issues that the default sequence of “~.” (tilde then period) can cause when connectivity to the global zone is remote.

A non-global zone has nearly the same abilities as the global zone to provide services: login connections are not limited to text or console logins. The use of zlogin with no options (only the zone name) connects to the zone without a console, which creates a tty and invokes login. Any active zone service also can be used, such as XDM, SSH and FTP, to allow other forms of login.

We now have a zone defined, installed and running. The examples presented here illustrate some of the administrative tasks associated with zones: reboot, shutdown, halt and deletion of an lx branded zone. Pay close attention to the shell prompts to identify the zone in which each command is run.

The zone creation steps are straightforward and simple. The process may take only a few steps, but they are manual and error-prone. The zonetool.pl utility (see Resources) automates the zone creation process and includes detailed POD documentation. Run zonetool.pl without arguments or with the --help option to display usage details. Listing 7 shows an example of using zonetool.pl.

With relatively small amounts of disk and memory resources, a single physical server can host hundreds of zones. Each zone is usable by any number of users, and a single-user zone provides extreme flexibility. A single user can create more than one zone to test both server and client environments, and the applications will believe they are on unique physical hosts. A zone user may have use of the zone's unique root password or unfettered sudo access within that zone without concern for security and stability of the global zone and other non-global zones.

The lx branded zone does have its limitations. Much of the zone's power comes from securely shared resources with the global zone. The zone shares a kernel with the global zone and, therefore, places limits on kernel modules and drivers. Because zones are not full VMs, the Linux distributions that can be installed in an lx branded zone are limited. Support for other Linux releases is possible, and further interest in this technology will inspire continued development and support for additional Linux distributions. Review the Resources section of this article for more information on this and related topics.