Solaris-Zones: Linux IT Marbles Get a New Bag
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:
zonecfg: define a zone (metadata only).
zoneadm: install/uninstall, boot and query.
zlogin: log in to a zone or connect to its console.
zonename: prints the name of the zone executed within.
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.
Listing 1. Defining an lx Zone
# 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.