Zones are a light weight VM concept which is further development and refinement of the idea of BSD jails which

were added to FreeBSD in 1999. Zones were designed in Sun by Andrew Tucker and according to Sun have better security and better integrated into the OS. To say that zones are great would be an understatement. They completely changed Unix landscape (including Unix security landscape) and this why Solaris in the first true XXI century Unix available on the marketplace. In 2011, 12 years from invention of the concept in FreeBSD Solaris implementation of zones is still unsurpassed. It is not an accident that AIX 6 copied parts of the concept from Solaris 10: imitation is the highest form of flattery... The idea of zone is to creates an isolated process tree, preserving the common OS foundation. Processes inside the zone cannot affect processes outside. Thus, we get an environment similar to a virtual machine, but with minimal overhead, that can't be matched by any existing or foreseeable types of virtual machines (with "original" or paravirtualised guests). It is usually called a lightweight virtual machine. Unlike complete virtual machine environment like VMware or AIX 5.3 LPAR, zones are focused mainly on security. It is important to stress that they have the smallest overhead among all mainstream virtualization technologies and they have a clean and simple design. Unlike LPAR in AIX ("VM/360 style virtual machine implementation with paravirtualized guests"), zones can be used both on Intel and SPARC versions of Solaris 10. Unlike VMware you have one instance of OS (I always wondered what's so great in running ten instances of OS virtual page management on the same hardware and pay EMC additional $5K for this privilege -- IBM used to avoid this problem in VM/CMS factoring virtual memory management into VM level). The same is partially true about schedulers. In a very deep way full virtualization solutions cannot compete with light weight virtualization unless they use "minimized, castrated, OSes" in which all "extras" like memory management and scheduling are factored out to the VM level. It seems that zones are becoming the new powerful security model. Instead of one computer per server, one computer could have multiple jails for applications provided by zones, with each zone providing one service. This is especially attractive for large enterprises where "fight for privileges" between users and administrators is especially acute. Now it can be resolved by granting root access to the zone with a particular application. That's huge advance over mess that used to exist. The most important feature of zones is that this method of isolating applications from each other and from "mothership". It can be used as new, natural and powerful security paradigm for all but the most convoluted applications (I would not recommend running Oracle database in a zone if you still have some hairs on your head; at least not right now ;-). If a service in the zone is compromised, the activities of the attacker will be constrained to the zone, but also will be fully visible to the administrator, at minimal risk to the administrator. This model offers substantially enhanced monitoring in comparison with separate hardware devices like network IDS, or paravirutalised guests (like AIX LPAR, or "classic" Xen). The latter offers little reliable insight into their operation once compromised. In zoned environment global zone can be a perfect point to watch over zones. Also constraints on system calls greatly hamper the ability of the attacker in employing rootkits. Zones benefited from approximately five years of experience with FreeBSD jail technology (as I mentioned above jails were added to FreeBSD in 1999) and managed to move further along the path pioneered by FreeBSD. Solaris 10 allow separate resource allocation for each zone (See Solaris Containers-Resource Management and Solaris Zones).

Recently Sun extended the concept of a zone into more sophisticated mechanism implemented a "linux zone" which can run linux executables. Sun terminology is confusing and often it is unclear. In one place they use the term "zone" and in the other the term "container". I tend to think that zones + resource management = Solaris containers zones + resource management = Solaris containers There is also analogy between zone and Java sandbox concept. Each zone requires its own dedicated IP address and, using Solaris cinematographic analogy, represents an isolated satellite revolving around the unknown planet that can communicate with other zones and "mothership" only via network services. The number of zones that can be effectively hosted on a single system is dependent upon the total resource requirements of the application software running in all of the zones. Each zone does duplicates certain daemons (cron, syslog,etc), so there is an overhead. A minimalist zone needs approximately 50Meg of disk and 15Meg of memory. Sun recommends 100M disk space for a zone as a minimum. If each zone does not do a lot of processing or do a very similar processing (synergy like in case of multiple WEB servers) is it probably possible to host a couple of dozens of WEB servers on a typical V210 configuration with 2 CPUs and 4G of RAM. The problem with zones is not only that they add complexity, but that people often want from light-weight VM capabilities or full VM (hardware hypervisor). So there is "false expectations" promise with this technology, which probably prevented it acquiring the deserved popularity. And to withstand this barrage of customer requirements was pretty difficult, as during its last years Sun did not have good technical leadership (as a technology visionary Jonathan Schwartz was a joke; his acquisition my MySQL and the game he played with Solaris were highly questionable). With branded zones it became a complex expensive kludge and the line delineating zones and parvirtualized guests becomes somewhat fuzzy. Currently Sun is experiencing the period of "irrational exuberance" with zones: instead of just polishing the offering and clearly identifying its limitations the developers are trying to extend it in all directions. Some directions are (technically) interesting like Linux zones in recent Solaris 10 x86 (zones that are able to run unmodified Linux binaries), some are questionable like access to raw devices in the zones to run Oracle databases, but all of them are adding complexity and it is not clear what is the real return on the investment. For example, if a person wants to run unmodified Linux binaries (and this is a workstation problem mainly), in most cases (unless you are running chip tracing software or other binary with huge CPU requirements) he/she should be able to use a SunPCi card to solve the problem. I do not understand why not to make SunPCi card to work on Intel boxes and use this solution for those few cases when you have no other solution but to run Linux binaries until a native Solaris solution emerge. What exactly prevents this ? In an extremely rare case you want raw power then it should be SunPCIi with high level Opteron. In this case you main application can be isolated from the rest of the system and it also can be a Windows or Apple application not just Linux, which is probably more practically important case. I hope that this "everything is possible" activity will stop or at least slow down in late 2006 when Sun will get the feedback about the rate of zones adoption in the industry (I bet it is slow and it

additionally slowed by the problems with the initial implementation and all the new features that Sun is adding to the plate). When everything is possible nothing is easy... As a zone is a light-weight VM created within a single instance of the Solaris Operating System, you can boot zone, login into zone, etc as if this is a separate computer. The original instance of Solaris ("mother ship") is called a global zone. It always has the name global. The global zone run system-wide processes and is used for zone administrative control. A regular user of the global zone can be a root user of the zone and thus can boot the zone, add/delete users, etc. that's a nice separation of duties in a large enterprise environment. Here is the summary or local/global zone features: Global zone

Is assigned ID 0 by the system Provides the single instance of the Solaris kernel that is bootable and running on the system Contains a complete installation of the Solaris system software packages Can contain additional software packages or additional software, directories, files, and other data not installed through packages Provides a complete and consistent product database that contains information on all software components installed in the global zone Holds configuration information specific to the global zone only, such as the global zone host name and file system table Is the only zone that is aware of all devices and all file systems Is the only zone with knowledge of non-global zone existence and configuration Is the only zone from which a non-global zone can be configured, installed, managed, or uninstalled Is assigned a zone ID by the system when the zone is booted Shares operation under the Solaris kernel booted from the global zone Contains only a subset of the complete Solaris Operating System software packages Contains Solaris software packages shared from the global zone Can contain additional installed software packages, not shared from the global zone Can contain additional software, directories, files, and other data created on the nonglobal zone that are not installed through packages or shared from the global zone Has a complete and consistent product database that contains information on all software components installed on the zone, whether present on the non-global zone or shared read-only from the global zone Is not aware of the existence of any other zone(s) Cannot install, manage, or uninstall other zones, including itself Has configuration information specific to the non-global zone only, such as the nonglobal zone host name, IP and file system table

Local zones

Processes in zones are isolated from other processes: even a process running with superuser credentials in a particular zone cannot view or affect activity in other zones. A processes that are assigned to different zones are only able to communicate through network APIs. For example to share files between zones NFS or Samba can be used. 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. Zones are ideal for hosting applications which can adversely influence each other and provide a possibility to consolidate several such applications on a single server. They are perfect for hosting providers as they permit adequate level of isolation of clients without excessive and punishing penalty that is difficult to justify in a world of cut-throat competition typical for web hosting. The fact that Solaris 10 can run of a regular x86 computers (from example PowerEdge 1950 and 2950 from Dell) makes this even more attractive value proposition. The cost and complexity of managing numerous small servers that host just one application makes it more feasible to consolidate several applications on larger, more scalable servers. A zone also provides an additional abstraction layer. Each zone has one or several dedicated IP addresses. Zone cannot share IP with the "mothership" (global zone) or other zones. The global zone ("good old Unix") has a dual function. It can run process like any normal Unix system, but it can also manage satellite zones. Each zone is also given a unique numeric identifier similar to UID, which is assigned by when the zone is booted. The global zone is always has ID 0. Zone names and numeric IDs are discussed in Using the zonecfg Command. When logged as root the global zone, the administrator can monitor and control the system as a whole. All processes and all files are visible from global zones. That's a very convenient feature which permits advanced debugging of complex applications. A non-global (sattelite) zone is administered by a zone root user, which is a just a regular user of a global zone. The "global administrator" ("mothership" root) can assign the Zone Management profile to any user converting him into the zone admin. It is important to understand that zZone admin privileges are limited to the zone(s) he administer. In a global zone he is just a regular user. This is a very nice, very slick way to resolve "root hell" problem typical in large corporation when each application maintainer need root provides to perform its duties and as such encroach on turf of primary server administrators and can negatively affect him and/or other users as he has the privileges to alter any parameter of the system. See NonGlobal Zone Characteristics for more information. The following figure from Sun documentation shows a system with four zones. Each of the zones apps, users, and work is running a set of applications unrelated to the workloads of the other zones Each zone can provide a customized set of services. Each zone also has a node name that is completely independent of the zone name. The node name is assigned by the zone admin. For more information, see Non-Global Zone Node Name For more information about steps involved in creation zone, see Solaris Zone Creation Examples and man page for zonecfg Command.

Zone State Model

Zone is a light-weight VM and we should keep in mind this fact when navigating our way via obscure terminology. Sun introduced too many states into this concept with somewhat confusing names and semantic (for example, it looks like "installed" and "ready" state are more like "offline" and "online" device states ;-). See the zoneadm(1M) man page that unfortunately does not explain this issue despite the fact that this is the command that is designed for changing VM states. It looks like a zone can be in one of the following states. --Create---> Configured <--Delete-----Install--> <--Uninstall----Ready-->

fined

Installed

<--Halt--

Ready

---Boot-->

^--------------------- Shut down -------------------|

1. Undefined. This is stage where zone configuration was started but not yet

committed to storage or if the zone was deleted.

2. Configured. The zone's configuration is completely specified and committed (written to

disk). However, some elements of the zone's application environment (root password, etc) that must be specified for the boot are still missing. To change to the next (instlalled) state:
zoneadm -z

zonename install zonename uninstall

To change to the previous (undefined) state:

zoneadm -z zoneadm

3. Installed. The zone's configuration is completly configured and VM is ready to boot. The

command can be is used to verify that the configuration is bootable. zonename ready (optional) zonename boot

To change to the next ("ready") state:

zoneadm -z zoneadm -z

To change to previous (configured) state: zoneadm -z zonename uninstall

4. Ready. Transition to this state from the installed state is essentially a switching on VM

(like online button in devices). At the end the virtual platform for the zone is established. The kernel creates the zsched process, network interfaces are plumbed, file systems are mounted, and devices are configured. A unique zone ID is assigned by the system. At this stage, no processes associated with the zone have been started. So normally this is a transitional state toward ready state (see below). But in beta versions of Solaris 10 you need to explicitly change zone into this state to be able to boot it.
zoneadm -z

zonename ready and system reboot return a zone in the ready state to the installed state.

zoneadm halt

5. Running. User processes associated with the zone application environment are running.

The zone automatically enters the running state from the ready state as soon as the first user process associated with the application environment (init) is created.
zlogin

options zonename zonename reboot zonename halt returns ready zone to the installed state. and system reboot return a zone in the running state to the installed state.

zoneadm -z zoneadm -z

zoneadm halt

6. Shutting down and down. These states are transitional states that are visible while the

zone is being halted. However, a zone that is unable to shut down for any reason will stop in one of these states. If resource management features are used, it is best to align the boundaries of 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.

Your feedback is extremely important. Please send us your opinion about the page. This way you can help to improve the site. Thank you in advance for this courtesy... This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link. Google search
Top of Form

Bottom of Form

Latest

Past week

Past month

Past year

Old News ;-)

Zones and Containers FAQ (Community Group zones.faq) - XWiki

Branded zones that run an environment different that the OS release on the system

The lx branded zone introduced in the Solaris 10 8/07 release provides a Linux environment for your applications and runs on x86 and x64 machines on the Oracle Solaris 10 OS. For more information, visit the OpenSolaris Community: BrandZ.

The solaris8 and solaris9 branded zones enable you to migrate an Oracle Solaris 8 or Oracle Solaris 9 system to an Oracle Solaris 8 or Oracle Solaris 9 Container on a host running the Oracle Solaris 10 8/07 Operating System or later Oracle Solaris 10 release. A solaris8 branded zone is an environment for Oracle Solaris 8 applications on SPARC machines. A solaris9 branded zone is an environment for Oracle Solaris 9 applications on SPARC machines. Now named Oracle Solaris 8 Containers and Oracle Solaris 9 Containers, these products were introduced through a product called the Solaris 8 Migration Assistant 1.0, on October 22, 2007. For more information, see System Administration Guide: Solaris 8 Containers and System Administration Guide: Solaris 9 Containers. To download, go to Solaris Containers. [May 2008]

The Oracle Solaris 10 Container brand is available in OpenSolaris build 127. These branded zones host Oracle Solaris 10 user environments. [August 2010] [May 19, 2010] Renaming a Solaris zone I needed to rename a zone on a Solaris 10 system earlier this week and here are some notes on how I did it. The process of renaming a zone is essentially a task of renaming, editing and replacing strings in a series of (mostly XML) configuration files. All of the tasks below were carried out from the global zone on the system in question. 1. Shut down the zone to be renamed
# zoneadm -z <oldname> halt

2. Modify the configuration files that store the relevant zone configuration
# vi /etc/zones/index

Change all references of <oldname> to <newname> as appropriate

# cd /etc/zones # mv <oldname>.xml <newname>.xml # vi <newname>.xml

Change all references of <oldname> to <newname> as appropriate 3. Rename the main zone path for the zone
# cd /export/zones # mv <oldname> <newname>

Your zone path may be different than the one shown above 4. Modify (network) configuration files of new zone Depending on the applications installed in your zone, there may be several files you need to update. The essential networking files are:
# cd /export/zones/<newname>/root # vi etc/hosts # vi etc/nodename

But others containing your old host/zone name can also be found using this command:
# cd /export/zones/<newname>/root/etc # find . -type f | xargs grep <oldname>

5. Boot the new zone again

# zoneadm -z <newname> boot

[May 19, 2010] Cloning a Solaris Zone by James Mernin

Jul 11, 2007 | Martello

I tried out cloning on a Solaris Zone today and it was a breeze, so much easier (and far, far quicker) than creating another zone from scratch and re-installing all the same users, packages, port lock-downs etc. Here are my notes from the exercise: Existing System Setup SunFire T1000 with a single sparse root zone (zone1) installed in /export/zones/zone1. The objective is to create a clone of zone1 called zone2 but using a different IP address and physical network port. I am not using any ZFS datasets (yet). Procedure 1. Export the configuration of the zone you want to clone/copy
# zonecfg -z zone1 export > zone2.cfg

2. Change the details of the new zone that differ from the existing one (e.g. IP address, data set names, network interface etc.)
# vi zone2.cfg

3. Create a new (empty, unconfigured) zone in the usual manner based on this configuration file
# zonecfg -z zone2 -f zone2.cfg

4. Ensure that the zone you intend to clone/copy is not running

# zoneadm -z zone1 halt

5. Clone the existing zone

# zoneadm -z zone2 clone zone1 Cloning zonepath /export/zones/zone1... This took around 5 minutes to clone a 1GB zone (see notes below)

6. Verify both zones are correctly installed

# zoneadm list -vi ID NAME STATUS PATH 0 global running / - zone1 installed /export/zones/zone1 - zone2 installed /export/zones/zone2

7. Boot the zones again (and reverify correct status)

# zoneadm -z zone1 boot # zoneadm -z zone2 boot # zoneadm list -vi ID NAME STATUS PATH 0 global running / 5 zone1 running /export/zones/zone1 6 zone2 running /export/zones/zone2

8. Configure the new zone via its console (very important)

# zlogin -C zone2

The above step is required to configure the locale, language, IP settings of the new zone. It also creates the system-wide RSA key pairs for the new zone, without which you cannot SSH into the zone. If this step not done, many of the services on the new zone will not start and you may observe /etc/.UNCONFIGURED errors in certain log files. Summary You should now be able to log into the new zone, either from the root zone using zlogin or directly via ssh (of configured). All of the software that was installed in the existing zone was present and accounted for in the new zone, including SMF services, user configuration and security settings etc. Notes If you are using ZFS datasets in your zones, then you may see the following error when trying to execute the clone command for the newly created zone:
Could not verify zfs dataset tank/xxxxx: mountpoint cannot be inherited zoneadm: zone xxxxx failed to verify

To resolve this, you need to ensure that the mountpoint for the data set (i.e. ZFS partition) being used has been explicitly set to none. Even though the output from a zfs list command at the global zone might suggest that it does not have a mount point, this has happened to me a number of times and in each case, the following command did the trick for me:
# zfs set mountpoint=none tank/xxxxx

Easy! Working with Solaris Containers and the Solaris Service Manager -by Joost Pronk van Hoogeveen Solaris Containers and Predictive Self-Healing technologies work together by creating separate execution environments, each with its own namespace and assigned resources. Each environment can have its own self-healing personalities that can be changed, copied, and reloaded as needed. These technologies enable administrators to determine the current state of the environment, making it easier to use the Solaris OS for consolidation efforts. This article provides an inside look on what the Solaris 10 OS has to offer, as well as ideas on how to get started and put these new features to work, with technologies such as Solaris Containers, Solaris Predictive Self Healing and Solaris Service Management Facility. Emphasis is placed on illustrating how these functionalities can be used to create isolated environments customized for specific applications. Solaris Containers Technology Architecture Guide -by Jeff Victor This Sun BluePrints article is a must-read for those looking to find new ways to reduce IT infrastructure costs and better manage end user service levels. While costs from managing vast networks of servers and software components continue to escalate, existing server consolidation and virtualization techniques do not adequately provision applications and ensure shared resources are not compromised. The Solaris Containers technology addresses this void by making it possible to create a number of private execution environments within a single instance of the Solaris OS.

This paper provides suggestions for designing system configurations using powerful tools associated with Solaris Containers, guidelines for selecting features most appropriate for the user's needs, advice on troubleshooting, and a comprehensive consolidation planning example. CategorySolaris-wiki-project

Creation of sample zone in Solaris for hosting apache

SolarisContainers_HandsOn-20090414.pdf
Solaris Containers basic handson material 4/14/2009

BigAdmin Feature Article Setting Up MySQL Cluster Software Using Solaris Zones Partitioning Technology by Hashamkha Pathan, August 2008 | sun This document describes how to set up MySQL Cluster software in a Solaris Zones environment, as if it were running on independent physical servers. This setup is useful for replicating an environment in-house without using multiple physical systems. The author shows that it is also possible to extend the setup to use Solaris Zones on different physical systems. For more details, see the list of contents below. Download the document as PDF.

Contents
Introduction Steps for Setting Up MySQL Cluster Software With Solaris Zones 1. Create Solaris Zones 1.1 Create the Zones Using the Command Line 1.2 Create the Zones Using a Script 2. Install MySQL Cluster Software 2.1 Download and Install MySQL Cluster Software for the Solaris OS for x64 Platforms

2.2 Set Up the Configuration for the MySQL Server (my.cnf) 2.4 Modify root User Environment (.profile)

2.3 Verify Access to the MySQL Server 3. Configure and Test MySQL Cluster Software 3.1 Configure the Management Node 3.2 Configure the Data and SQL Nodes 3.3 Start and Stop the Cluster 3.4 Test the Cluster Operation Acknowledgments Sun Inner Circle Newsletter - Getting to the Bottom of Solaris Containers - July 2006

Running a zone require substantial memory resources: " Q: Is it true that if several Zones share the same application, then only one instance of the application needs to be installed? Is there enough isolation so that an error in one instance of the application won't affect the same application in another Zone?" A: As for your first question, it is possible for Zones to share the same application instance, but the decision to do so depends on if the administrator is installing the application in a directory that each Zone can see (for example, /usr in Apache). Otherwise each Solaris Zone will require a private copy of the application. With regards to your second question, every application in every Zone has its own instance (and processes) that are totally isolated from one another. Isolation is a prime reason why Sun built Solaris Zones the way it did.

Inner Circle July 2006 One of the key breakthrough technologies in Solaris 10, Solaris Containers has the ability to promote server consolidation, as well as improve application availability and manageability. In this interview, Inner Circle plays 20-plus questions with Sun virtualization experts Joost Pronk van Hoogeveen, Jeff Victor, and Chien-Hua Yen to more fully understand the potential, capabilities, and limitations of Solaris Containers and Solaris Zones. IC: What are the differences among Logical Domains, Solaris Zones, and Solaris Containers? Joost Pronk van Hoogeveen: Domains are a type of hardware partitioning, so the partitioning is done at the hardware level. Solaris Zones are part of Solaris Containers technology. As such, Zones manage the namespace isolation (separate IP addresses and users, for example) for Containers. Containers and Zones are a type of operating system virtualization, where the partitioning is not done at the hardware level, but rather within the operating system itself. IC: Are Zones and Containers the same thing? Jeff Victor: Not exactly. The official definition for a Solaris 10 Container is a Solaris Zone using resource management features. But in casual conversation, few people distinguish between Zones and Containers. IC: Aside from Zones, what else comprises Solaris Containers? Joost Pronk van Hoogeveen: Solaris Containers are made up of two major components: Solaris Zones and Solaris Resource Manager (SRM). SRM manages the physical system resources every Container receives, and Solaris Zones control the namespace isolation. Together, Zones and SRM form the basis for Solaris Containers. IC: What distinguishes Solaris Containers from virtual domain technologies, such as LPARs? Joost Pronk van Hoogeveen: LPARs are a typical virtual machine technology with a hypervisor layer between the hardware and the operating system, whereas Solaris Containers are a type of operating system virtualization. Virtual domains and virtual machines allow different types of operating systems to be run concurrently on the same physical machine. But, as with all virtual machine technologies, there is significant performance overhead to this approach. By contrast, Solaris Containers are very lightweight and create hardly any performance overhead. But Solaris Containers permit only a single operating system version. IC: What are the relative advantages of Solaris Containers when compared to LPARs? Jeff Victor: Solaris Containers have a number of advantages, including lower operating system licensing and support costs, lower hardware costs due to better granularity, reduced management workload, and greater application availability. IC: How do Solaris Containers compare to the virtual machine approach advocated by VMware?

Jeff Victor: Containers provide multiple isolated workload environments with strict security and resource management features. Because there is only one operating system image, the Solaris Containers method is very efficient and reduces management chores. VMware provides the ability to simultaneously host multiple operating system images, as well as the ability to choose different operating system types (Linux, Solaris, and Windows). However, as with all virtual machines, there is a performance penalty with VMware. Also, with VMware and other virtual machine technologies each operating system image must be managed separately. IC: I have installed Solaris 10 within VMware. Can I use Solaris Containers to virtualize within VMware? Joost Pronk van Hoogeveen: Yes. Solaris Containers will work within any Solaris 10 instance, so you can evaluate the benefits of operating system virtualization within virtual machines in your particular environment. IC: With regards to Solaris Zones, what is the global Zone, and are there any local Zones? Chien-Hua Yen: There are two types of Zones: global Zones and non-global Zones. The official name for a "local" Zone is a "non-global" Zone. A global Zone contains a fully functional installation of the Solaris Operating System that is bootable by the system hardware. So, an installation of the Solaris Operating System becomes the global Zone when it is booted by the system hardware. Only one global Zone runs on a system. Then, the global Zone administrator creates non-global Zones with Zonecfg(1M) and Zoneadm(1M). The global Zone controls the installation, maintenance, operation, and destruction of all non-global Zones. IC: What is the recommended maximum number of Zones a system can hold, and what are the ease-of-use considerations for a large number of Zones on a single machine? Chien-Hua Yen: The limiting factors in the maximum number of Zones a server can handle are the amount of memory and disk space available. A Zone can occupy anywhere from ~150MB to 3GB disk space depending on how the Zone is configured. Each Zone also takes some memory for system processes. Still, managing a Zone is very similar to managing a system except it is easier to manage a Zone because you can patch or backup all Zones using a single command. IC: Are the physical CPU and RAM shared among Zones? Is it possible to allocate different resources to different Zones? Jeff Victor: Solaris Zones share CPUs. An administrator can use Solaris Dynamic Resource Pools to assign one or more CPU(s) to a Solaris Zone. Also, the Solaris Fair-Share Scheduler can guarantee that a certain Solaris Zone gets a predetermined minimum amount of processing power. Plus, the Solaris Fair-Share Scheduler helps ensure that CPU power is not wasted because processing resources are only constrained once the system reaches 100 percent utilization. When it comes to RAM, Solaris Zones share the amount of physical memory available on the system. The amount of physical memory that a Zone uses cannot be constrained as it stands now, but Sun is working on a feature that will address this issue soon. IC: How easy is it to modify resource allocations on a per-Container basis so that resources are more finely managed across all Solaris Containers on a system? Joost Pronk van Hoogeveen: Resource Management assignments to a Container can be modified at any time without the need for Container reboot. For more information on resource allocation and isolation, check out an in-depth Sun BluePrints article. IC: With Solaris Containers, what kind of overhead can be expected per CPU (or per core)?

Jeff Victor: For small numbers of Containers, the overhead is hardly measurable certainly less than 1 percent. A very large configuration with hundreds of Zones sees as much as a 4 percent overhead, which is still very low by comparative standards. IC: Is it true that if several Zones share the same application, then only one instance of the application needs to be installed? Is there enough isolation so that an error in one instance of the application won't affect the same application in another Zone? Joost Pronk van Hoogeveen: As for your first question, it is possible for Zones to share the same application instance, but the decision to do so depends on if the administrator is installing the application in a directory that each Zone can see (for example, /usr in Apache). Otherwise each Solaris Zone will require a private copy of the application. With regards to your second question, every application in every Zone has its own instance (and processes) that are totally isolated from one another. Isolation is a prime reason why Sun built Solaris Zones the way it did. IC: How does patching work? Do I have to patch all the Zones or only the global Zone? Chien-Hua Yen: For details, check out patchad(1M) or an in-depth article at the Sun BigAdmin portal. In summary, it is possible to patch all Zones from the global Zone or each Zone individually from either the global Zone or the non-global Zone. IC: Do you need to take down non-global Zones when patching the global Zone? Chien-Hua Yen: No. It is not necessary to bring down the non-global Zones when patching the global Zone. However, if the job includes a kernel patch, the global Zone will need to be rebooted before the patch takes effect. And, once the global Zone is rebooted, all of the nonglobal Zones will be brought down. IC: In the event of a kernel panic, what happens to the Solaris Containers? Chien-Hua Yen: If the kernel panics, all the Zones go down with it, because there is only one kernel instance supporting all Zones. However, under normal circumstances it is possible to shut down each individual Zone without affecting other Zones. And, if a Zone crashes, the other Zones will not be affected. IC: Did Sun consider creating a graphic way to configure Containers to make them more user friendly? Joost Pronk van Hoogeveen: There is a Sun Management Center (Sun MC) add-on called the Solaris Container Manager that is a GUI for managing Containers. IC: Is it possible to run two or more Containers on one physical server with two or more Oracle database instances running inside each of those Containers? If so, how will the system handle memory management in both Containers and across all Oracle instances? Joost Pronk van Hoogeveen: Yes. It is possible to create any combination of Oracle databases and Solaris Containers just as if it were a number of database instances on separate machines. And, the Containers will isolate shared memory just as if they were separate machines. Check out this BigAdmin article for more information. IC: How do ISVs like Oracle and Informix handle license issues when enterprises are using Solaris Containers? Joost Pronk van Hoogeveen: Sun recommends that database vendors base licensing on the resource pools that are assigned to individual Solaris Containers. So far, Oracle has adopted this policy.

IC: When building processor sets for a Sun Fire T2000 server, does one assign Containers based on the number of processors or the number of threads? In other words, will a fourcore (16 thread) chip multithreading chip give me four or 16 "processors" to build sets against? Joost Pronk van Hoogeveen: On a Sun Fire T2000 server every thread is exposed as a (virtual) CPU. So, the Solaris Resource Manager can create sets on an individual thread basis meaning all 16 threads are assignable in the example cited. IC: Are there minimum server size requirements for starting to use Containers? For example, would it be feasible to use Containers on a low-end server such as the SunFire 280R? Joost Pronk van Hoogeveen: Containers can be installed on any system that supports Solaris 10 from laptops to high end servers. IC: Does any tool exist that can verify if an application is Container compliant? Chien-Hua Yen: Yes. You can download the Solaris Ready Test Suite and also access the Solaris qualification tool. The tool set consists of a DTrace script for checking privileges and device nodes that are not available in a non-global Zone, as well as a source scanning tool for checking the use of non-Zone compliant APIs. [May 16, 2007] BigAdmin Feature Article Enhancements in Solaris Container Manager 3.6.1 [May 14, 2007] docs.sun.com System Administration Guide Solaris Containers-Resource Management and Solaris Zones [May 12, 2007] OpenSolaris Forums zone migration ... Jan 20, 2006 (opensolaris.org) For those interested in zone migration, I have just submitted a fast-track through our internal architectural review process. The body of the proposal is enclosed. Let me know if there are any questions. Thanks, Jerry ---SUMMARY: This fast-track enhances the Solaris Zones [1] subsystem to address an existing RFE[2] requesting the ability to migrate an installed non-global zone from one machine to another. We will implement the concept of detaching and attaching a zone. An installed non-global zone must be detached prior to moving it from one system to another. The process of detaching the zone will create the information necessary to attach the zone on a

different system. Attaching the zone will first validate that the new machine is capable of properly hosting the zone. Patch binding is requested for the new sub-commands and the stability of these interfaces is "evolving". DETAILS: Overview Migrating a zone from one system to another involves the following steps: 1. Detaching the Zone. This leaves the zone on the originating system in the "configured" state. Behind the scenes, the system will generate a "manifest" of the information needed to validate that the zone can be successfully attached to a new host machine. 2. Data Migration. The system administrator moves the data which represents the zone to a new host system (more details below). 3. Zone Configuration. The system administrator creates the zone configuration on the new host using zonecfg(1m). 4. Attaching the zone. This will validate that the host is capable of supporting the zone before the attach can succeed. The zone is left in the "installed" state. Validation The validation will check that the exact version of the required packages and patches are installed on the new host. The algorithm to determine the packages and patches that must be validated is: For each package installed in the global zone: - ignore the package if SUNW_PKG_THISZONE is 'true' otherwise, - validate the package if a) SUNW_PKG_ALLZONES is 'true', or b) any file delivered by the package is in a file system that is inherited from the global zone. If the zone does not inherit any file systems (whole root) then (b) will be skipped. For each of the packages that is being validated we will also validate all of the associated patches.

In the future we plan to extend this so that we might upgrade the zone or add patches to the zone when we attach, but initially we will only validate the new host and inform the sys-admin if there are packages or patches that are out of sync with what was installed on the original host machine. In order to validate the package and patch versions from the original host and new host, we will read this information from the pkginfo files in /var/sadm/pkg. We will also need to read the /var/sadm/install/contents file to determine which packages are within inherited-pkg-dirs. While some of this information is public, the contents file format and the existence of the pkginfo files within /var/sadm/pkg is not. These are contract private interfaces and a contract with the Install group, to allow us to access these files, is part of this case. zoneadm Sub-Commands We will add two new sub-commands to the zoneadm command and one new option to the create subcommand within zonecfg. The syntax for detaching a zone will be: # zoneadm -z my-zone detach The zone must be halted before being detached. During detach we will generate metadata describing the versions of the packages and patches installed on the host. This will be stored in an XML file in the zonepath, alongside the root and dev directories. This facilitates easy movement of the zonepath from one system to another. We will not implement any kind of archive for a detached zone. We will document what the sys-admin must do to move the zone bits around, but they can move this any way they choose. In some cases, such as a SAN environment, the bits might not have to move at all. When we detach, we leave the zone in the configured state. The sys-admin can then delete the configured zone or attach to it later. The syntax for attaching a zone will be: # zoneadm -z my-zone attach [-F]

Attaching a zone is analogous to installing a zone. That is, you first must configure the new zone using the zonecfg command. Once you have the new zone in the configured state you can use attach to set up the zone root instead of installing. During attach we will perform the package and patch sanity checks described above. This will validate that the attach can occur. If the packages and patches don't match we will list which packages and patches are out of sync and the zone will be left in the configured state. The sys-admin can then apply any required packages or patches to the host to enable the attach to succeed. Or, they may not be able to attach to the specific host if the installed software is sufficiently incompatible with the environment on the original machine. Once the attach has completed successfully, the XML file describing the zone will be removed. If you try to install or clone to a configured zone and there is an XML description for a detached zone in the zonepath, we will give an error and won't proceed. The -F option for attach allows the sys-admin to force the attach with no validation. This is useful in certain cases such as a clustered environment or for backup/restore, but it does require that the sys-admin is certain that the system is properly configured to host the zone or undefined behavior may later occur. zonecfg create option To facilitate configuring the detached zone on a new host we will add a new '-a' option to the create subcommand within zonecfg. The subcommand for creating a new zone from the detached XML data will be: zonecfg:my-zone> create -a path_to_zone_root The -a option will used the XML description of the detached zone to configure the new zone instance. It is not required to to configure the new zone this way. That is, the new zone can be configured using the traditional zonecfg operations and then "zoneadm attach" can be used to attach the zone root. All of the validation of the zone happens during attach, not during configuration of the zone. EXAMPLE host1# zoneadm -z my-zone detach

- move the my-zone zonepath from host1 to host2 host2# zonecfg -z my-zone my-zone: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:my-zone> create -a /export/zones/my-zone zonecfg:my-zone> commit zonecfg:my-zone> exit host2# zoneadm -z my-zone attach Here is an example where some packages and patches are out of sync between the source host and the local host we are attempting to attach to. The actual syntax of the error messages will be different in the final implementation, this is just an example to give an idea of what might happen. host2# zoneadm -z my-zone attach source host packages inconsistent with local host SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch (2.6.0,REV=101.0.3.2005.12.19.21.22) SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch (11.11,REV=2006.01.03.00.45) SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch (11.11,REV=2006.01.03.00.45) NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed local host packages inconsistent with source host SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed source host patches inconsistent with local host 120081 is not installed 118844 is not installed 118344 is not installed local host patches inconsistent with source host 118669 was not installed 118668 was not installed 116299 was not installed EXPORTED INTERFACES zoneadm subcommands detach EVOLVING attach [-F] EVOLVING zonecfg create subcommand option -a path EVOLVING IMPORTED INTERFACES

/var/sadm/install/contents Contracted Unstable (LSARC/2004/464) /var/sadm/pkg/*/pkginfo Contracted Unstable A contract is part of this case. pkginfo(4) public VERSION keyword evolving (pkginfo(4)) PATCHLIST keyword public (psarc/1995/063) REFERENCES 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2. RFE: Ability to migrate zones across machines Bugid 5022513 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513 _______________________________________________ zones-discuss mailing list zones-discuss at opensolaris dot org

p>Re: zone migration Posted: Jan 20, 2006 8:45 PM in response to: gjelinek

Hi sorry but i think there is a little more work to do, >3. Zone Configuration. The system administrator creates the zone > configuration on the new host using zonecfg(1m). this should be automated and perhaps give the user a chance to edit the resulting config on the target server. It really wouldn't be much work, and it makes the whole process painless. Later someone else can do a script that does zonemove zonename zonename@remotebox maybe even load ballancing can be had for us poor folks that dont want the time and expense of having identical hardware of a cluster. James Dickens uadmin.blogspot.com On 1/20/06, Jerry Jelinek wrote: > For those interested in zone migration, I have just submitted > a fast-track through our internal architectural review process. > The body of the proposal is enclosed.

> > Let me know if there are any questions. > > Thanks, > Jerry > > ---> > SUMMARY: > > This fast-track enhances the Solaris Zones [1] subsystem > to address an existing RFE[2] requesting the ability to migrate > an installed non-global zone from one machine to another. > > We will implement the concept of detaching and attaching a zone. > An installed non-global zone must be detached prior to moving it > from one system to another. The process of detaching the zone > will create the information necessary to attach the zone on a > different system. Attaching the zone will first validate that the > new machine is capable of properly hosting the zone. > > Patch binding is requested for the new sub-commands and the stability > of these interfaces is "evolving". > > DETAILS: > > Overview > > Migrating a zone from one system to another involves the following > steps: > > 1. Detaching the Zone. This leaves the zone on the originating > system in the "configured" state. Behind the scenes, the > system will generate a "manifest" of the information needed > to validate that the zone can be successfully attached to a new > host machine. > > 2. Data Migration. The system administrator moves the data which > represents the zone to a new host system (more details below). > > 3. Zone Configuration. The system administrator creates the zone > configuration on the new host using zonecfg(1m). > > 4. Attaching the zone. This will validate that the host is > capable of supporting the zone before the attach can succeed. > The zone is left in the "installed" state. > > Validation

> > The validation will check that the exact version of the required > packages and patches are installed on the new host. The algorithm > to determine the packages and patches that must be validated is: > > For each package installed in the global zone: > - ignore the package if SUNW_PKG_THISZONE is 'true' > otherwise, > - validate the package if > a) SUNW_PKG_ALLZONES is 'true', > or > b) any file delivered by the package is in a file system > that is inherited from the global zone. > If the zone does not inherit any file systems (whole root) > then (b) will be skipped. > > For each of the packages that is being validated we will > also validate all of the associated patches. > > In the future we plan to extend this so that we might upgrade > the zone or add patches to the zone when we attach, but initially > we will only validate the new host and inform the sys-admin if there > are packages or patches that are out of sync with what was installed > on the original host machine. > > In order to validate the package and patch versions from the > original host and new host, we will read this information > from the pkginfo files in /var/sadm/pkg. We will also need to > read the /var/sadm/install/contents file to determine which packages > are within inherited-pkg-dirs. While some of this information > is public, the contents file format and the existence of the pkginfo > files within /var/sadm/pkg is not. These are contract private > interfaces and a contract with the Install group, to allow us to > access these files, is part of this case. > > zoneadm Sub-Commands > > We will add two new sub-commands to the zoneadm command and one > new option to the create subcommand within zonecfg. > > The syntax for detaching a zone will be: > > # zoneadm -z my-zone detach > > The zone must be halted before being detached. > > During detach we will generate metadata describing the versions of > the packages and patches installed on the host. This will be stored

> in an XML file in the zonepath, alongside the root and dev > directories. This facilitates easy movement of the zonepath from one > system to another. > > We will not implement any kind of archive for a detached zone. > We will document what the sys-admin must do to move the zone > bits around, but they can move this any way they choose. > In some cases, such as a SAN environment, the bits might not have > to move at all. > > When we detach, we leave the zone in the configured state. > The sys-admin can then delete the configured zone or attach to > it later. > > The syntax for attaching a zone will be: > > # zoneadm -z my-zone attach [-F] > > Attaching a zone is analogous to installing a zone. That is, you > first must configure the new zone using the zonecfg command. Once > you have the new zone in the configured state you can use attach to > set up the zone root instead of installing. > > During attach we will perform the package and patch sanity checks > described above. This will validate that the attach can occur. > If the packages and patches don't match we will list which packages > and patches are out of sync and the zone will be left in the > configured state. The sys-admin can then apply any required > packages or patches to the host to enable the attach to succeed. > Or, they may not be able to attach to the specific host if the > installed software is sufficiently incompatible with the environment > on the original machine. > > Once the attach has completed successfully, the XML file describing > the zone will be removed. If you try to install or clone to a > configured zone and there is an XML description for a detached zone > in the zonepath, we will give an error and won't proceed. > > The -F option for attach allows the sys-admin to force the attach > with no validation. This is useful in certain cases such as > a clustered environment or for backup/restore, but it does require > that the sys-admin is certain that the system is properly configured > to host the zone or undefined behavior may later occur. > > zonecfg create option > > To facilitate configuring the detached zone on a new host we will > add a new '-a' option to the create subcommand within zonecfg.

> > The subcommand for creating a new zone from the detached XML data > will be: > > zonecfg:my-zone> create -a path_to_zone_root > > The -a option will used the XML description of the detached > zone to configure the new zone instance. It is not required to > to configure the new zone this way. That is, the new zone > can be configured using the traditional zonecfg operations and > then "zoneadm attach" can be used to attach the zone root. > All of the validation of the zone happens during attach, not > during configuration of the zone. > > EXAMPLE > > host1# zoneadm -z my-zone detach > > - move the my-zone zonepath from host1 to host2 > > host2# zonecfg -z my-zone > my-zone: No such zone configured > Use 'create' to begin configuring a new zone. > zonecfg:my-zone> create -a /export/zones/my-zone > zonecfg:my-zone> commit > zonecfg:my-zone> exit > host2# zoneadm -z my-zone attach > > Here is an example where some packages and patches are out of sync > between the source host and the local host we are attempting to attach > to. The actual syntax of the error messages will be different in the > final implementation, this is just an example to give an idea of what > might happen. > > host2# zoneadm -z my-zone attach > source host packages inconsistent with local host > SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch > (2.6.0,REV=101.0.3.2005.12.19.21.22) > SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch > (11.11,REV=2006.01.03.00.45) > SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed > SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch > (11.11,REV=2006.01.03.00.45) > NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed > local host packages inconsistent with source host > SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed > SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed > source host patches inconsistent with local host

> 120081 is not installed > 118844 is not installed > 118344 is not installed > local host patches inconsistent with source host > 118669 was not installed > 118668 was not installed > 116299 was not installed > > EXPORTED INTERFACES > > zoneadm subcommands > detach EVOLVING > attach [-F] EVOLVING > zonecfg create subcommand option > -a path EVOLVING > > IMPORTED INTERFACES > > /var/sadm/install/contents Contracted Unstable > (LSARC/2004/464) > /var/sadm/pkg/*/pkginfo Contracted Unstable > > A contract is part of this case. > > pkginfo(4) public > VERSION keyword evolving (pkginfo(4)) > PATCHLIST keyword public (psarc/1995/063) > > REFERENCES > > 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris > 2. RFE: Ability to migrate zones across machines Bugid 5022513 > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513 > _______________________________________________ > zones-discuss mailing list > zones-discuss at opensolaris dot org > _______________________________________________ zones-discuss mailing list zones-discuss at opensolaris dot org Posts: 531 From: Menlo Park, CA Registered: 3/11/05 [Nov 12, 2006] The Sun BluePrints Guide to Solaris Containers: Virtualization in the Solaris Operating System (pdf)

Find out how to create, use, and integrate Solaris Containers in a new "mini-book" with detailed examples... 1. Introduction to Solaris Zones 2. Non-Global Zone Configuration (Overview) 3. Planning and Configuring Non-Global Zones (Tasks) 4. About Installing, Halting, and Uninstalling Non-Global Zones (Overview) 5. Installing, Booting, Halting, and Uninstalling Non-Global Zones (Tasks) 6. Non-Global Zone Login (Overview) 7. Logging In to Non-Global Zones (Tasks) 8. Moving and Migrating Non-Global Zones (Tasks) 9. About Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Overview) 10. Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks) 11. Solaris Zones Administration (Overview) 12. Solaris Zones Administration (Tasks) 13. Troubleshooting Miscellaneous Solaris Zones Problems [Nov 10, 2006] Virtually Speaking Sun's Virtual Expansion Solaris 10 11/06, the next build of the operating system, will be released at the end of November. The version will include new capabilities for Containers. Admins will be able to clone a Container as well as relocate it to another box, through a feature called Attach/Detach, Wake said. [Nov 10, 2006] OpenSolaris Zones Presentation (pdf) by Narayana Janga and Shivani Khosa. (BigAdmin) Presentation on Zones and OpenSolaris given at ApacheCon US 2006. [Aug 24, 2006] BigAdmin - Submitted Tech Tip Zone Replication on the Solaris 10 OS in Five Easy Steps by David Steed The following is coffeeware -- instructions rather than software. If you use this, you are obligated to buy me a coffee... at your convenience. These instructions describe a very simple method of moving a local zone from one machine to another (using the Solaris 10 OS). Given: Two physical machines, with no shared storage The same Solaris 10 version installed Machine Y with one fully populated local zone installed (and nothing inherited)

Machine Z with no zones installed (Z can also be an additional zone on the same machine)

Here are the five easy steps: 1. Log in to the console of a zone running on machine Y and create a full flash (this does not work properly with an image created from a global zone!). Example:
zonename # flarcreate -n "machineY" -S /machineY.flar (anywhere but /tmp)

2. Copy the following files from machine Y to machine Z:

The newly created flash image

/etc/zones/index

(merge it with the existing index file) (rename to machineZ.xml and edit

/etc/zones/machineY.xml

appropriately)
/export/zones/machineX/root/ (machineX /export/zones/machineX/dev/

3. Create the following:

directory with 700 perms)

4. Split the flash image (flar split machineX.flar), then move the file "archive" to /export/zones/machineX/root/, and unpack it with cpio -i.

Uncompress if necessary (mv archive archive.Z; uncompress archive.Z)

cd

to the machineX/root directory: cpio -i < /export/archive

5. Boot the machine with zoneadm -z machineZ boot and log in -- the devices will be built at that time. Sysid information is normally required at this point ... Don't forget: send an invitation for coffee to D@vidSteed.com and I will accept! Re: zone migration Posted: Jan 21, 2006 1:46 AM in response to: jamesd Reply

On Fri 20 Jan 2006 at 10:45PM, James Dickens wrote: > Hi > > sorry but i think there is a little more work to do, > > >3. Zone Configuration. The system administrator creates the zone > > configuration on the new host using zonecfg(1m). > > this should be automated and perhaps give the user a chance to edit > the resulting config on the target server. It really wouldn't be much

> work, and it makes the whole process painless. Later someone else can > do a script that does zonemove zonename zonename@remotebox maybe > even load ballancing can be had for us poor folks that dont want the > time and expense of having identical hardware of a cluster. James, doesn't the 'zonecfg create -a' subcommand which Jerry described in the document do what you want? Could you be more specific about what you'd like (i.e. a specific use case with a little more detail)? To give an example, you will be able to trivially invoke it with: # zonecfg -z newzone create -a path_to_zone_root # zoneadm -z newzone boot Or, you can invoke it interactively, and make edits: # zonecfg -z newzone zonecfg:newzone> create -a path_to_zone_root zonecfg:newzone> add net ... I'd like to better understand your concerns. Thanks, -dp -Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp [Jul 1, 2006] Techworld.com - Solaris Xen support imminent Sun will release working Xen support code in July. This code will give OpenSolaris the ability to run on Xen as a "Domain 0" (Dom0), or host, system, with support for 32-bit and 64-bit guest (DomU) Solaris systems. OpenSolaris will get full Xen support by October, which will be extended to Solaris 10 in the first half of 2007, Sun said. Under Xen, a virtualised machine is called a "domain," and operating systems must be modified at the kernel level to be fully virtualised - an approach called paravirtualisation that is designed to allow for maximum performance. The Dom0 system is fully virtualised, but has direct access to hardware, unlike DomU systems. So far, Linux operating systems such as SUSE Linux Professional 9.3, the upcoming Suse Linux Enterprise 10 and Red Hat's Fedora Core 3 and 4, have been modified for Xen support. Operating systems such as Windows can run as a host system without modifications using virtualisation technology found in newer Intel chips and upcoming AMD chips.

Virtualisation is expected to revolutionise the use of operating systems, applications and even malware once it goes mainstream. Xen, developed at the University of Cambridge, is an opensource competitor to virtualisation providers such as VMware. Sun also provides its own container technology, but said it plans to provide users with the ability to mix and match. Sun initially got Solaris working with Xen in a rudimentary form in July 2005. In February 2006 Sun released the first, early OpenSolaris-on-Xen code. "Running on Xen, OpenSolaris is reasonably stable, but it's still very much 'pre-alpha' compared with our usual finished code quality," wrote Sun engineer Tim Marsland in his blog at the time. "Installing and configuring a client is do-able, but not for the faint of heart." [Jun 26, 2006] Solaris Containers Technology Architecture Guide (pdf) provides suggestions for designing system configurations using powerful tools associated with Solaris Containers. This Sun BluePrints article also offers advice on troubleshooting and a comprehensive consolidation planning example. [Jun 15, 2006] http://www.opensolaris.org/os/community/zones/zones_design_docs/

eges for zones Integrated March 2006 in Nevada build 37This case proposes a new facility for zones: the ability to specify the set of privileges that all of the processes in a zone are limited to. Zones migration (attach/detach) Integrated March 2006 in Nevada build 36This change provides the ability to migrate an installed non-global zone from one machine to another. Add $zonename to the list of macros supported by logadm Integrated March 2006 in Nevada build 36(Contributed by Rich Lowe) This document proposes the addition of a new keyword for the logadm[1] utility, $zonename. Zones move and clone Integrated Feb 2006 in Nevada build 33.This fast-track enhances the Solaris Zones subsystem to address two existing RFEs. The first enables non-global zones to be relocated from one point on the filesystem to another; this may involve actually moving the bits and requires changing the associated metadata (the "zonepath"). The second enables administrators to rapidly provision new non-global zones, once one has been set up, by allowing installation via copying from another (non-global) zone. Zones rename Integrated Sept 2005 in Nevada build 24This case proposes a new facility for zones: rename of non-global zones.

[Jun 9, 2006] Working with Solaris Containers and the Solaris Service Manager (pdf) ...discusses technologies inside the Solaris 10 OS that enable administrators to determine the current state of the computing environment. This Sun BluePrints article explains how users can put these new features to work, simplifying consolidation efforts. [May 3, 2006] Qualification Best Practices for Application Support in Non-Global Zones shows how to qualify applications so that they will support non-global zones. The discussion is focused on the Solaris Zones feature of Solaris Containers. [Jan 26, 2006] Shadow of IBM AIX over Sun Solaris :-) Is not this a full scale virtual machines like AIX LPARs under other name or what ?

The OpenSolaris Project's new community and application framework, BrandZ, extends the Solaris Zones infrastructure to create Branded Zones, which are zones that contain non-native operating environments. For example, the lx brand enables Linux binary applications to run unmodified on the Solaris OS, within zones running a complete Linux userspace. Solaris Containers Consolidating Servers and Applications Instructs users, system administrators, and developers on how to consolidate applications onto a single server. Users are guided through the consolidation process, with code examples and illustrations. [Dec 15, 2005] Blueprint/Web Consolidation on the Sun Fire T1000 using Solaris Containers by Kevin Kelly ... Recent studies describe the challenges IT managers face administering the proliferation of x86-based servers used to run web services applications.... The combined capabilities of the Sun Fire T1000 server and Solaris Containers technology in particular offer significant promise as a web-tier consolidation platform.... This paper explores the configuration and testing of the Sun Fire T1000 server as a web-tier consolidation platform. It discusses methodologies used to consolidate multiple web servers onto a single Sun Fire T1000 server, and explains the steps used to configure the Solaris Containers. In addition, to determine the effectiveness of this approach, testing was performed to evaluate the consolidated Sun Fire T1000 system against a baseline configuration of current Xeon servers, a popular choice as web server platform. Sun BluePrints Online - Articles May 2005 Over the years businesses have been building large-scale information systems to solve business problems, with a focus on building scalable and highly available IT infrastructures that can adapt change. Providing sufficient availability and performance for business applications was the primary driver for these efforts. Today, the need to protect technology investments and provide the same service levels at a lower price point is shifting the focus to reducing IT infrastructure cost and improving end user service level management. To help this effort, the Solaris Operating System includes Solaris Containers, a mechanism that provides isolation between software applications or services using flexible, software-defined boundaries. This Sun BluePrint article discusses the challenges organizations face in dealing with resource and workload management. Solaris Containers, and their constituent technologies (projects, resource pools, Zones) are introduced and explained. Worked examples that show these technologies solving resource and workload management problems provide practical examples of how to use these technologies.
Note: This article is available in PDF Format only.

[Mar 11, 2005] Learning Solaris 10 Zones Unofficial FAQ

This FAQ is NOT coming from an official Sun Source, be careful ! Still, I hope and believe that the answers are correct and will be very happy to correct them if theyre not. Last updated : May 19 2005 Recent modifs : 1.3 Section 1 : Support

1.1 Do I need special hardware for running Zones ? 1.2 Which applications are supported to run on Zones ? 1.3 What about license costs if I run my application in a Zone on a specific number of CPUs? Section 2 : Creation - Configuration 2.1 What are these four add-inherit-pkg-dir in my zone configuration and may I remove them? 2.2 Which kind of devices may I NOT add using the zonecfg set devices command? 2.3 How do I add a special netmask for a zones IP address? 2.4 How to hide a subdirectory of a directory that is loopback mounted from the Gloabl zone? 2.5 How do I add a filesystem to my non-global zone? Section 3 : Administration 3.1. Why is snoop not working in a non-global zone? 3.2. How do I block traffic between non-global zones? 3.3. What is the patches story in non-global zones? Section 4 : Integration with other Solaris features 4.1 : Zones & IPFilter? 4.2 : Zones & ZFS? 4.3 : Zones & IPQoS? 4.4 : Zones & IPsec? 4.5 : Zones & IPMP? 4.6 : Zones & DTrace? 4.7 : Zones & SunCluster? 4.8 : Zones & Solaris Volume Manager? 4.9 : Zones & Process Rights Management? Section 6: files, commands & daemons 6.1 The zoneadmd daemon 6.2 The zsched daemon 6.3 The zcons driver 6.4 The zonecfg command 6.5 The zoneadm command 6.6 The zlogin command 6.7 The /etc/zones/my-zone.xml file 6.8 The /etc/zones/index file 6.9 The /etc/zones/SUNWdefault.xml file 6.10 The /etc/zones/SUNWblank.xml file

[Apr 5, 2005] BigAdmin Feature Article Consolidation Demo Using Solaris Containers The goal is to demonstrate the capabilities of the Solaris 10 Operating System, using the Solaris Zones feature and Solaris Containers technology in an everyday situation, to facilitate and encourage customer adoption.
Equipment (Minimum)

System based on UltraSPARC or x86 processor, with one CPU (two or more preferred) 256 Mbyte of RAM (1 GB preferred) 20-Gbyte hard disks (two or more hard disks preferred) Solaris 10 Operating System build 63 (Solaris Express 8/04) MySQL 3.23 (other RDMBS may be substituted) Apache Web Server 1.3 (or Sun Java System Web Server)

Two zones are configured to be used as containers for an RDBMS and a web server. Some parameters are modified for each zone, to control the CPU and other resources in use, according to each application. The demo is carried out simulating the load from the web server that is accessing information contained in the database. These two applications were selected because they solve a real business problem, but their different natures make them unsuited to share resources inside a traditional server or partition.
Steps Preparations: Before installing the OS, prepare three IP addresses and CDs with Solaris 10 build 63, MySQL, and the Apache web server. Note: You can get the Solaris 10 OS from the web site of the Sun Software Express program, and the other software from SunFreeware. If you need to simulate the load on the applications to check the boundaries of the containers, use the "CPU spinner" as described in Step 8 of the following Cookbook section.

1. Install the Solaris OS. 2. Configure the system after installation. 3. Create the structure to hold the zones. 4. Create and install two new zones. 5. Update the resources for each zone including the global zone. 6. Install and configure the RDBMS. 7. Install and configure the web server. 8. Create workloads. 9. Monitor performance and manage resources. Dan Price Blog: The View from the Moon Remote, Secure Zone Console Login I have heard from a number of customers that folks would like remote login to zone consoles. In particular, they would rather not give out logins to the global zone in order to allow zone logins. (Really: I don't spend all of my time on the zones console...). Fortunately, we can handle this in a nice way already. (Disclaimer: Please note that as stated by the script, the following techniques have not been subject to a rigorous security audit. I believe this technique to be sound, but neither I nor Sun warrant it to be so.) To start, we'll add a user account to /etc/passwd for each zone we want to set up this way:
# cat >> /etc/passwd z1:x:999999:999999:xanadu-z1:/tmp:/opt/extras/zoneshell ^D # pwconv # passwd z1 New Password: xxxyyy Re-enter new Password: xxxyyy passwd: password successfully changed for z1

In this case, the zone name is xanadu-z1 and we've picked a nice large UID and group ID. You could use whatever you like (but not a UID in use for something else! and never 0); you'll want a

separate UID for each zone. In this case, /opt/extras/zoneshell is set as the z1 user's shell. We picked 'z1' as the account name because UNIX systems are typically limited to 8 letter account names (LOGNAME_MAX); since xanadu-z1 is 9 characters long (and zone names may be up to 64 characters long), we need to pick a convention to shorten things. The zoneshell script is here; the script itself is very simple: it looks up the entry in /etc/passwd and executes zlogin -C for the zone named in the GECOS field. Finally, we need to give the z1 account the ability to run zlogin; we do that by modifying the RBAC attributes for the z1 user.
# cat >> /etc/user_attr z1::::profiles=Zone Management ^D

So, here's what it looks like:

$ ssh -l z1 xanadu Password:xxxyyyy Last login: Tue Jan 25 13:54:01 2005 from xxx warning: using experimental, unsupported 'zoneshell' [Connected to zone 'xanadu-z1' console]

I'd appreciate any feedback on whether this is helpful, or not! docs.sun.com System Administration Guide Solaris Containers-Resource Management and Solaris Zones Using patchadd in the Global Zone To add a patch to the global zone and to all non-global zones, run patchadd as the global administrator in
the global zone. When patchadd is used in the global zone, the following conditions apply:

The patchadd utility is able to add the patch(es) to the global zone and to all non-global zones only. This is the default action. The patchadd utility cannot add the patch(es) to the global zone only or to a subset of the non-global zones.

When you add a patch to the global zone and to all non-global zones, you do not have to consider whether the patch affects areas that are shared from the global zone.
The following steps are performed by the patchadd utility:

The patch is added to the global zone. The patch database on the global zone is updated. The patch is added to each non-global zone. The patch database on each non-global zone is updated.

[Mar 22, 2005] Solaris Forums - zones and patching

Re: zones and patchingAuthor: Darren_Dunham Mar 22, 2005 3:46 PM (reply 1 of 2) > Hi, I'm fairly new to Solaris so sorry for possible > dumb question. > When I do patch OS in global zone are those changed

> reflected in sub-zones as well ? I do assume they are > not, right ? Actually, they usually are. If the patch doesn't apply to another zone (usually due to package differences), then it won't be applied. Otherwise it is. In a few cases, you can patch a non-global zone, but only if the packages allow it. The docs have quite a bit of information on this.

http://docs.sun.com/app/docs/doc/817-1592/6mhahuoqn?a=view [Mar 25, 2005] Solaris Forums - Log Files

Re: Log Files Author: Darren_Dunham Mar 23, 2005 11:50 AM (reply 1 of 2) > If for example you have 5 zones installed will the > global zones /var/adm/messages show up in the 5 zones > log files No. The general philosophy is that someone on a non-global zone should not have visibility into other zones or the global zone (without it being explicitly done). Having /var/adm/messages visible into another zone could release information that you don't want. So each has their own syslog. -Darren Re: Log Files Author: emacs-user Mar 25, 2005 8:23 AM (reply 2 of 2) Yes, /var/adm/messages will show up in each zone, and they will be separate files. However, if you want to have integrated logging, use syslog to send the syslog output from each zone to the global zone's syslog.

[Mar 14, 2005] Solaris Forums - Enforcing non-global zone auditing from global zoneEnforcing non-global zone auditing from global zone Author: vladgrama Hello, You have two choices for configuring auditing with zones: either you have one daemon in the global zone auditing everything or you configure per-zone audit daemons (by setting the perzone policy) What wasn't clear from documentation, but I realized in practice is that even if there is just one audit daemon in the global zones, the events that are audited in the non-global zones are the ones specified in the audit_control file from the non-global zone. This means that root in a non-global zone can alter the audit_control file and practically disable auditing for the zone by removing all flags. I would like to have an option where the global zone has full control over what events are logged from a non-global zone. So that root in the non-global zone can't change that. A workaround for me was to make /etc/security an inherit-pkg-dir thus the audit_control file can no longer be modified from nonglobal zones. However I think a cleaner solution would be desirable in the future.

Vlad. [Mar 16, 2005] Re: Zones and projects Author: izfromsun
Do you know about 'prctl' ? http://docs.sun.com/app/docs/doc/816-5165/6mbb0m9p5?a=view zones are a natural extension of projects (i.e. a secure containment for projects, if you will). The header for 'prctl' man page doesn't include zones:

prctl get or set the resource controls of running processes, tasks, and projects ...but some of the parameters do accept 'zone' as an argument. Could that help ? the other thing may be worth trying is to create a pool ,then a pset, then associate a pool with a pset (all with 'poolcfg') [ wrapped around with 'pooladm(1M)' ] then... 'poolbind' the zoneid to the resource pool like so: 'poolbind -p zone_pool -i zoneid 2' (where zoneid is seen from: 'zoneadm list -vi') -Isaac [Mar 17, 2005] Re: rcapd and zones. Author: vladgrama
I've just found the answer for my "limiting zone RSS" question in topic http://forum.sun.com/thread.jspa?threadID=22407&tstart=15 I quote from there:

David.Comay: There isn't yet support for something like zone.max-rss but it's indeed something that we're looking at doing. At the moment, the non-global zone administrator can configured rcapd(1M) inside the zone but the global zone administrator does not have a way of limiting an individual zone's memory usage. For now, for me it's enough that I can use rcapd inside a zone. Maybe explicitely saying this in the docs/man pages would be useful. [Mar 11, 2005] BigAdmin Feature Meet the Architects Software Express for Solaris (Solaris 10) Andrew Tucker -- Solaris Zones Architect Solaris Zones (a component of the N1 Grid Container functionality) is a new feature for maximizing the use of your Solaris systems, and getting "better bang for the buck." Zones allow unrelated applications to be run on the same system in a way that isolates each application from the rest, avoiding the security and configuration problems that can occur when running applications together. Each zone is an application environment that includes a set of processes, a part of the file system hierarchy, and one or more network interfaces. To an application or user in a zone, it looks like they have a full Solaris system to themselves -- when in fact they may be

sharing it with a number of other zones on the same system. Zones also allow delegated administration: Each zone can have a different root password, and the root user in one zone isn't able to affect anything outside his or her zone. The original idea for zones started a number of years ago when we were talking with customers about server consolidation. At the time, we had added a number of resource management features to the Solaris OS, allowing an administrator to control how CPUs were allocated to different applications. Customers were interested in improving the utilization of their servers, but were unable to "stack" or consolidate multiple applications on the same box. Some of reasons for this were related to resource allocation, but many were due to the need to isolate applications in terms of configuration, security, and administration. We developed zones as a way to address these problems. Now, multiple applications running on the same system (but in different zones) can be completely isolated --- even if someone gains super-user access in one zone due to a security hole they won't have access to the rest of the zones in the system. And we can do this in a way that is lightweight and flexible. There's still only one operating system instance to patch, back up, monitor, and so on. And you can use zones on anything from a single-CPU 1U server to a 72-CPU Sun Fire 15K server. [Mar 7, 2005] System Administration Guide- Solaris Containers [PDF] Jan 2005 update. This is a large old guide (334 pp). Contains an example of zone creation. [Mar 7, 2005] Solaris Forums - Solaris Zones Zone Best Practice Author: birkbeck01 I am wondering how best to use zones and if Sun says that there is no (or little) performance lost using zones should we be using zones for all software. i.e. Give no user access to the global zone. Possible setup: 1) Set up Solaris 10 and Global zone with no USER Access and no real software installed/running (unless it is need for zones)!! 2) Set up 1 or more zones where you run all your applications and user access. and of course the leading question should you have 1 zone or many zones e.g. a zone runs one piece of software (oracle, ldap server, computer server, http) Andrew Solaris 10 for Experienced System Administrators :: SA-225-S10 Has a zone lab that creates one network zone. It also discusses configuring resource pools (poolcfg), fair share scheduling (FSS) and resource capping (memory cap, etc). Peter's Solaris Zone -- A minimalist zone needs about 50Meg of disk and 15Meg of memory to support 10 processes. My favourite feature in Solaris 10 is zones. (I don't care what Sun marketing call 'em this week, either. They're zones.) Isolated containers that give the appearance of a separate system to applications while being hosted by a master system. This little test was inspired by the desire to be able to run individual applications in isolated managed environments. I'm thinking of servers such as tomcat or mysql, where you only want

enough support to run the one application, and you only need a single network port to gain access. One of the problems with mysql, tomcat, and other similar servers, is that you can generally only run one instance on a machine. Yes, you can hack it so that you can fiddle port numbers and the like to get multiple copies running, but the idea here was to run the applications inside their own zones. That way, they think they have the machine to themselves and the multiple instances don't conflict with each other. You only need to communicate from the global zone, so you can send all traffic over the loopback. Big Bubbles (no troubles) Running WebSphere in a Solaris zone "My new rule of thumb is that absolutely no Internet facing service be run in anything but a non-global zone. Anything less is being reckless." - Jarod Jenson, Aeysis OK, right, that's the new paradigm, is it? Let's see if we can make IBM WebSphere Application Server run inside a non-global zone then. There ought to be a number of advantages to this architecture: The base WebSphere installation should only be installed once in the global zone and then shared between the other zones. Following from that, if the local zones are compromised, perhaps via a rogue web application, then the WebSphere executables and libraries can't be modified, since they will be read-only. This is a major security win. Patches and WebSphere fixes can be applied once to the global zone and will immediately update all the local zones (but see note below). Theoretically, new zones/WebSphere instances can be quickly provisioned, duplicated or migrated (although some of this functionality isn't easily realised with the current Zones functionality). Some of this may help the flow of a new application release through development, acceptance testing, staging and production environments. Developers can have full access to particular WebSphere zones without impacting other instances. Because zones are independent, it will be easier (and more robust) to run multiple instances of a particular web application. For example, the application I look after uses a standard log4j configuration, logging to a local file. Having two application instances in the same environment would cause both to write to the same log file, which results in corruption and missed entries. However, in separate zones each could have the exact same configuration but the output files would actually be different (zone-specific). A multi-node WebSphere topology (separate web/application/database servers) can be simulated on a single host. At present, it's expensive to create a test site that mirrors the distributed topology of a production site, yet without this an application cannot be properly qualified.

Jimmy Andriambao's Weblog Weblog What is a Solaris Zone ? How to set it quickly ? A Zone is what you can imagine as a virtual machine. You can install another Solaris operating system into and from the same host. It means that the main operating system, named

"Global Zone" will host one or more OSes. You can see it like if the main OS is the father of many children. But each child process are and behave like if they were installed on a different host. The Global Zone has access to the hosted (runned) zones but the zones themselves have no access to the host (Global Zone). Remember Vmware ? its a true virtual computer, ok ? Well, Solaris 10 provide you almost the same thing but the differences are big! Both have one same main host. You can launch or reboot any zones without rebooting the main OS (Global Zone). Each of them will have a different IP address but can/will use the network hardware interface you want. So you can launch Apache from a single zone or in each zones you run. Also you can run a zone with a different patches level than the Global Zone has. From the Global Zone, you can ssh to one of the zones or remote serial login in. Its wonderful, many things are possible. How to set it ? Prerequisites The zone will use the files from the Global Zone Understand ? it means you dont need a big file system. Thats very useful. So what you need are :

2 hours of time (it depends of your machine, of course! Mine was the U10 with latest OBP release) 300 Mb of RAM, at least, A Solaris 10 already installed OS. (SPARC/X86-X64), The disk size is not very important (as its virtual, it does not really consume the FS space), A free IP address (if the network is needed).

For our test, I used an ULTRA 10 Sparc computer, so the 1st real network interface is named : hme0. Take care to use a free IP address. I prefered to use an IP address which is on the same subnet. Also note that by using hme0 this IP address will be binded to the real hme0 (from the Global Zone : At the end of the document, you can see my ifconfig output from the main OS) Zones a better alternative for virtualization While Xen does sound interesting, for production virtualization, I think Solaris Zones is a much better alternative. It still gives you a secure environment, but it saves a lot of memory and disk space. You don't have to run and maintain a full-blown OS for each service you run. And, Zones let you create multiple-cpu containers, unlike Xen (currently).
Zones a better alternative for virtualization 2005-02-21 08:02:45 Sysadmn [Reply | View] The other way-cool part of Solaris Zones versus UML, BSD Jails, or Xen is that they're tied to resource limits. I hope Xen picks this up - it's great to be able to tell a virtual machine, "If things get busy, you get at most 1/2 a CPU and 512 MB of memory. If no one else is busy, use all you want." We can put 10 dev instances on a machine - each developer thinks they have their own machine (including reboots, root password, etc). The only thing they can't do is load testing - but that's what QA is for, right?

Brad's Blog Zone Creation. blastwave.org have an (older) article about creating zones in Solaris 10.

Google Groups comp.unix.solaris Following: http://docs.sun.com/app/docs/doc/816-5166/6mbb1kql9?a=view I did a `zonecfg -z my-zone3` and then a # zoneadm -z my-zone3 install ERROR: zones not available on this system zoneadm: zone 'my-zone3': '/usr/lib/lu/lucreatezone' failed with exit code 71. # uname -a SunOS not 5.10 s10_72 sun4u sparc SUNW,UltraAX-i2 # pkginfo | grep -i zone application SUNWluzone system SUNWzoner system SUNWzoneu # pkginfo | grep -i Live application SUNWlur application SUNWluu application SUNWluzone

Live Upgrade (zones support) Solaris Zones (Root) Solaris Zones (Usr)

Live Upgrade (root) Live Upgrade (usr) Live Upgrade (zones support)

I think all the packages that should be loaded are. The Live update seems to work by its self. Any idea what is wrong?

Recommended Links
In case of broken links please try to use Google search. If you find the page please notify us about new location
Top of Form

Bottom of Form

Internal pages updates by age: Latest : Past week : Past month : Past year New

OpenSolaris Zones Presentation (pdf) - Resources Presentation on Zones and OpenSolaris given at ApacheCon US 2006. Authors: Narayana Janga and Shivani Khosa.

Sun BluePrints Online - Articles May 2005 Over the years businesses have been building large-scale information systems to solve business problems, with a focus on building scalable and highly available IT

infrastructures that can adapt change. Providing sufficient availability and performance for business applications was the primary driver for these efforts. Today, the need to protect technology investments and provide the same service levels at a lower price point is shifting the focus to reducing IT infrastructure cost and improving end user service level management. To help this effort, the Solaris Operating System includes Solaris Containers, a mechanism that provides isolation between software applications or services using flexible, softwaredefined boundaries. This Sun BluePrint article discusses the challenges organizations face in dealing with resource and workload management. Solaris Containers, and their constituent technologies (projects, resource pools, Zones) are introduced and explained. Worked examples that show these technologies solving resource and workload management problems provide practical examples of how to use these technologies.
Note: This article is available in PDF Format only.

docs.sun.com System Administration Guide Solaris Containers-Resource Management and Solaris Zones BigAdmin Feature Article Consolidation Demo Using Solaris Containers [Jul 2, 2005] Learning Solaris 10 Zones Unofficial FAQ Sun Microsystems - BigAdmin Solaris Zones -links, links, links System Administration Guide- Solaris Containers [PDF] -- Jan 2005 update. This is a large old guide (334 pp) Solaris Zones: Operating System Support for Consolidating Commercial Workloads (pdf - 236K) System Administration Guide: Solaris Containers--Resource Management and Solaris Zones docs.sun.com System Administration Guide Solaris Containers-Resource Management and Solaris Zones [PDF] Microsoft PowerPoint - solaris-zones-1.ppt fintanr's weblog Zones, Message Queues and preliminary setup on a benchmark -- step by step instruction on how to use Solaris 10 zone facilities to create a zone. Fair Share Scheduler and Zones Sample zone creation script zones Remote, Secure Zone Console Login Clearing up confusion about zlogin, zones, consoles, and terminal types Documentation: Zones and Resource Controls. Small demo of Resource Management, Contracts and Service Management Framework Solaris Zones - What is a Solaris Zone ? How to set it quickly?

Top:

Onward to Zonedtrace land ... [PDF] Solaris 10: Leapfrog the rest with DTrace, Zones, and many more! Saurabh Mishra's Weblog A variant of zone creation (without network) IBM Tivoli software Training - IBM Tivoli Provisioning Manager Create VM using Solaris Zones; Automate Solaris Zone VM Provisioning [DOC] Virtual Machines and Solaris Containers

Other collections

pwo.de - Virtual Home of Peter W. Osel - Links - Solaris -- nice collection of links, many about zones... Technorati Tag OpenSolaris

Reference
Zones and Containers FAQ at OpenSolaris.org

zonecfg

command

The global administrator configures a zone by specifying various parameters for the zone's virtual platform and application environment. The zonecfg command is used to create this configuration. 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 global administrator can log into the installed zone by using the zlogin command. At first login, the internal configuration for the zone is completed. The zoneadm command is then used to boot the zone. For information on zone configuration, installation, and login, see

Chapter 17, About Zone Configuration (Overview), Chapter 19, About Installing, Halting, and Uninstalling Non-Global Zones (Overview), Chapter 21, About Non-Global Zone Login (Overview).

Man Pages
PDF

getzoneid.3c getzoneidbyname.3c getzonenamebyid.3c zcons.7d zlogin.1 zoneadm.1m zonecfg.1m zonename.1

zones.5

Text: Commands: ppriv(1) - inspect or modify process privilege sets and attributes zlogin(1) - Enter a zone zonename(1) - print name of current zone zoneadm(1M) - administer zones zoneadmd(1M) - zones administration daemons zonecfg(1M) - Set up zone configuration Library Functions: getzoneid(3C) - map between zone id and name getzoneidbyname(3C) - map between zone id and name getzonenamebyid(3C) - map between zone id and name priv_str_to_set(3C) - privilege name functions File Formats and Mscellany privileges(5) - the Process Rights Management privilege model zones(5) - Solaris application containers zcons(7D) - Zone console device driver

Forums
Solaris Forums - Solaris Zones

Scripts
The Clingan Zone

Zone replication
BigAdmin - Submitted Tech Tip Zone Replication on the Solaris 10 OS in Five Easy Steps

Zone Replication on the Solaris 10 OS in Five Easy Steps

David Steed, June 2006 The following is coffeeware -- instructions rather than software. If you use this, you are obligated to buy me a coffee... at your convenience.

These instructions describe a very simple method of moving a local zone from one machine to another (using the Solaris 10 OS). Given: Two physical machines, with no shared storage The same Solaris 10 version installed Machine Y with one fully populated local zone installed (and nothing inherited) Machine Z with no zones installed (Z can also be an additional zone on the same machine)

Here are the five easy steps: 1. Log in to the console of a zone running on machine Y and create a full flash (this does not work properly with an image created from a global zone!). Example:
zonename # flarcreate -n "machineY" -S /machineY.flar (anywhere but /tmp)

2. Copy the following files from machine Y to machine Z:

The newly created flash image

/etc/zones/index

(merge it with the existing index file) (rename to machineZ.xml and edit appropriately) directory with 700 perms)

/etc/zones/machineY.xml

3. Create the following:

/export/zones/machineX/root/ (machineX /export/zones/machineX/dev/

4. Split the flash image (flar split machineX.flar), then move the file "archive" to /export/zones/machineX/root/, and unpack it with cpio -i.

Uncompress if necessary (mv archive archive.Z; uncompress archive.Z)

cd

to the machineX/root directory: cpio -i < /export/archive

5. Boot the machine with zoneadm -z machineZ boot and log in -- the devices will be built at that time. Sysid information is normally required at this point ...

Zone migration
docs.sun.com System Administration Guide Solaris Containers-Resource Management and Solaris Zones You must be the global administrator in the global zone to perform this procedure. 1. Become superuser, or assume the Primary Administrator role. To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
2. Halt the zone to be migrated, my-zone in this procedure.

host1# zoneadm -z my-zone halt

3. Detach the zone.

host1# zoneadm -z my-zone detach

4. The detached zone is now in the configured state.

5. Move the zonepath for my-zone to the new host.

See How to Move the zonepath to a new Host for more information. 6. On the new host, configure the zone.

host2# zonecfg -z my-zone

7. You will see the following system message:

my-zone: No such zone configured Use 'create' to begin configuring a new zone.

8. To create the zone my-zone on the new host, use the zonecfg command with the
-a

option and the zonepath on the new host.

zonecfg:my-zone> create -a /export/zones/my-zone

9. (Optional) View the configuration.

zonecfg:my-zone> info zonename: my-zone zonepath: /export/zones/my-zone autoboot: false pool: inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr net: address: 192.168.0.90 physical: bge0

10. (Optional) Make any required adjustments to the configuration.

For example, the network physical device might be different on the new host, or devices that are part of the configuration might have different names on the new host.

zonecfg:my-zone> select net physical=bge0 zonecfg:my-zone:net> set physical=e1000g0 zonecfg:my-zone:net> end

11. Commit the configuration and exit.

zonecfg:my-zone> commit zonecfg:my-zone> exit

12. Attach the zone on the new host. Attach the zone with a validation check.

host2# zoneadm -z my-zone attach

The system administrator is notified of required actions to be taken if either or both of the following conditions are present: Required packages and patches are not present on the new machine. The software levels are different between machines. Force the attach operation without performing the validation.

host2# zoneadm -z my-zone attach -F

Caution

The -F option allows you to force the attach with no validation performed. This is useful in certain cases, such as in a clustered environment or for backup and restore operations, but it does require that the system be properly configured to host the zone. An incorrect configuration could result in undefined behavior later.

OpenSolaris Forums zone migration ... Jan 20, 2006 (opensolaris.org) For those interested in zone migration, I have just submitted a fast-track through our internal architectural review process.

The body of the proposal is enclosed. Let me know if there are any questions. Thanks, Jerry ---SUMMARY: This fast-track enhances the Solaris Zones [1] subsystem to address an existing RFE[2] requesting the ability to migrate an installed non-global zone from one machine to another. We will implement the concept of detaching and attaching a zone. An installed non-global zone must be detached prior to moving it from one system to another. The process of detaching the zone will create the information necessary to attach the zone on a different system. Attaching the zone will first validate that the new machine is capable of properly hosting the zone. Patch binding is requested for the new sub-commands and the stability of these interfaces is "evolving". DETAILS: Overview Migrating a zone from one system to another involves the following steps: 1. Detaching the Zone. This leaves the zone on the originating system in the "configured" state. Behind the scenes, the system will generate a "manifest" of the information needed to validate that the zone can be successfully attached to a new host machine. 2. Data Migration. The system administrator moves the data which represents the zone to a new host system (more details below). 3. Zone Configuration. The system administrator creates the zone configuration on the new host using zonecfg(1m). 4. Attaching the zone. This will validate that the host is capable of supporting the zone before the attach can succeed. The zone is left in the "installed" state.

Validation The validation will check that the exact version of the required packages and patches are installed on the new host. The algorithm to determine the packages and patches that must be validated is: For each package installed in the global zone: - ignore the package if SUNW_PKG_THISZONE is 'true' otherwise, - validate the package if a) SUNW_PKG_ALLZONES is 'true', or b) any file delivered by the package is in a file system that is inherited from the global zone. If the zone does not inherit any file systems (whole root) then (b) will be skipped. For each of the packages that is being validated we will also validate all of the associated patches. In the future we plan to extend this so that we might upgrade the zone or add patches to the zone when we attach, but initially we will only validate the new host and inform the sys-admin if there are packages or patches that are out of sync with what was installed on the original host machine. In order to validate the package and patch versions from the original host and new host, we will read this information from the pkginfo files in /var/sadm/pkg. We will also need to read the /var/sadm/install/contents file to determine which packages are within inherited-pkg-dirs. While some of this information is public, the contents file format and the existence of the pkginfo files within /var/sadm/pkg is not. These are contract private interfaces and a contract with the Install group, to allow us to access these files, is part of this case. zoneadm Sub-Commands We will add two new sub-commands to the zoneadm command and one new option to the create subcommand within zonecfg. The syntax for detaching a zone will be: # zoneadm -z my-zone detach The zone must be halted before being detached. During detach we will generate metadata describing the versions of

the packages and patches installed on the host. This will be stored in an XML file in the zonepath, alongside the root and dev directories. This facilitates easy movement of the zonepath from one system to another. We will not implement any kind of archive for a detached zone. We will document what the sys-admin must do to move the zone bits around, but they can move this any way they choose. In some cases, such as a SAN environment, the bits might not have to move at all. When we detach, we leave the zone in the configured state. The sys-admin can then delete the configured zone or attach to it later. The syntax for attaching a zone will be: # zoneadm -z my-zone attach [-F] Attaching a zone is analogous to installing a zone. That is, you first must configure the new zone using the zonecfg command. Once you have the new zone in the configured state you can use attach to set up the zone root instead of installing. During attach we will perform the package and patch sanity checks described above. This will validate that the attach can occur. If the packages and patches don't match we will list which packages and patches are out of sync and the zone will be left in the configured state. The sys-admin can then apply any required packages or patches to the host to enable the attach to succeed. Or, they may not be able to attach to the specific host if the installed software is sufficiently incompatible with the environment on the original machine. Once the attach has completed successfully, the XML file describing the zone will be removed. If you try to install or clone to a configured zone and there is an XML description for a detached zone in the zonepath, we will give an error and won't proceed. The -F option for attach allows the sys-admin to force the attach with no validation. This is useful in certain cases such as a clustered environment or for backup/restore, but it does require that the sys-admin is certain that the system is properly configured to host the zone or undefined behavior may later occur. zonecfg create option To facilitate configuring the detached zone on a new host we will

add a new '-a' option to the create subcommand within zonecfg. The subcommand for creating a new zone from the detached XML data will be: zonecfg:my-zone> create -a path_to_zone_root The -a option will used the XML description of the detached zone to configure the new zone instance. It is not required to to configure the new zone this way. That is, the new zone can be configured using the traditional zonecfg operations and then "zoneadm attach" can be used to attach the zone root. All of the validation of the zone happens during attach, not during configuration of the zone. EXAMPLE host1# zoneadm -z my-zone detach - move the my-zone zonepath from host1 to host2 host2# zonecfg -z my-zone my-zone: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:my-zone> create -a /export/zones/my-zone zonecfg:my-zone> commit zonecfg:my-zone> exit host2# zoneadm -z my-zone attach Here is an example where some packages and patches are out of sync between the source host and the local host we are attempting to attach to. The actual syntax of the error messages will be different in the final implementation, this is just an example to give an idea of what might happen. host2# zoneadm -z my-zone attach source host packages inconsistent with local host SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch (2.6.0,REV=101.0.3.2005.12.19.21.22) SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch (11.11,REV=2006.01.03.00.45) SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch (11.11,REV=2006.01.03.00.45) NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed local host packages inconsistent with source host SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed

source host patches inconsistent with local host 120081 is not installed 118844 is not installed 118344 is not installed local host patches inconsistent with source host 118669 was not installed 118668 was not installed 116299 was not installed EXPORTED INTERFACES zoneadm subcommands detach EVOLVING attach [-F] EVOLVING zonecfg create subcommand option -a path EVOLVING IMPORTED INTERFACES /var/sadm/install/contents Contracted Unstable (LSARC/2004/464) /var/sadm/pkg/*/pkginfo Contracted Unstable A contract is part of this case. pkginfo(4) public VERSION keyword evolving (pkginfo(4)) PATCHLIST keyword public (psarc/1995/063) REFERENCES 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2. RFE: Ability to migrate zones across machines Bugid 5022513 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513 _______________________________________________ zones-discuss mailing list zones-discuss at opensolaris dot org

p>Re: zone migration Posted: Jan 20, 2006 8:45 PM in response to: gjelinek

Reply Hi

sorry but i think there is a little more work to do, >3. Zone Configuration. The system administrator creates the zone > configuration on the new host using zonecfg(1m). this should be automated and perhaps give the user a chance to edit the resulting config on the target server. It really wouldn't be much work, and it makes the whole process painless. Later someone else can do a script that does zonemove zonename zonename@remotebox maybe even load ballancing can be had for us poor folks that dont want the time and expense of having identical hardware of a cluster. James Dickens uadmin.blogspot.com On 1/20/06, Jerry Jelinek wrote: > For those interested in zone migration, I have just submitted > a fast-track through our internal architectural review process. > The body of the proposal is enclosed. > > Let me know if there are any questions. > > Thanks, > Jerry > > ---> > SUMMARY: > > This fast-track enhances the Solaris Zones [1] subsystem > to address an existing RFE[2] requesting the ability to migrate > an installed non-global zone from one machine to another. > > We will implement the concept of detaching and attaching a zone. > An installed non-global zone must be detached prior to moving it > from one system to another. The process of detaching the zone > will create the information necessary to attach the zone on a > different system. Attaching the zone will first validate that the > new machine is capable of properly hosting the zone. > > Patch binding is requested for the new sub-commands and the stability > of these interfaces is "evolving". > > DETAILS: > > Overview

> > Migrating a zone from one system to another involves the following > steps: > > 1. Detaching the Zone. This leaves the zone on the originating > system in the "configured" state. Behind the scenes, the > system will generate a "manifest" of the information needed > to validate that the zone can be successfully attached to a new > host machine. > > 2. Data Migration. The system administrator moves the data which > represents the zone to a new host system (more details below). > > 3. Zone Configuration. The system administrator creates the zone > configuration on the new host using zonecfg(1m). > > 4. Attaching the zone. This will validate that the host is > capable of supporting the zone before the attach can succeed. > The zone is left in the "installed" state. > > Validation > > The validation will check that the exact version of the required > packages and patches are installed on the new host. The algorithm > to determine the packages and patches that must be validated is: > > For each package installed in the global zone: > - ignore the package if SUNW_PKG_THISZONE is 'true' > otherwise, > - validate the package if > a) SUNW_PKG_ALLZONES is 'true', > or > b) any file delivered by the package is in a file system > that is inherited from the global zone. > If the zone does not inherit any file systems (whole root) > then (b) will be skipped. > > For each of the packages that is being validated we will > also validate all of the associated patches. > > In the future we plan to extend this so that we might upgrade > the zone or add patches to the zone when we attach, but initially > we will only validate the new host and inform the sys-admin if there > are packages or patches that are out of sync with what was installed > on the original host machine. > > In order to validate the package and patch versions from the > original host and new host, we will read this information

> from the pkginfo files in /var/sadm/pkg. We will also need to > read the /var/sadm/install/contents file to determine which packages > are within inherited-pkg-dirs. While some of this information > is public, the contents file format and the existence of the pkginfo > files within /var/sadm/pkg is not. These are contract private > interfaces and a contract with the Install group, to allow us to > access these files, is part of this case. > > zoneadm Sub-Commands > > We will add two new sub-commands to the zoneadm command and one > new option to the create subcommand within zonecfg. > > The syntax for detaching a zone will be: > > # zoneadm -z my-zone detach > > The zone must be halted before being detached. > > During detach we will generate metadata describing the versions of > the packages and patches installed on the host. This will be stored > in an XML file in the zonepath, alongside the root and dev > directories. This facilitates easy movement of the zonepath from one > system to another. > > We will not implement any kind of archive for a detached zone. > We will document what the sys-admin must do to move the zone > bits around, but they can move this any way they choose. > In some cases, such as a SAN environment, the bits might not have > to move at all. > > When we detach, we leave the zone in the configured state. > The sys-admin can then delete the configured zone or attach to > it later. > > The syntax for attaching a zone will be: > > # zoneadm -z my-zone attach [-F] > > Attaching a zone is analogous to installing a zone. That is, you > first must configure the new zone using the zonecfg command. Once > you have the new zone in the configured state you can use attach to > set up the zone root instead of installing. > > During attach we will perform the package and patch sanity checks > described above. This will validate that the attach can occur. > If the packages and patches don't match we will list which packages > and patches are out of sync and the zone will be left in the

> configured state. The sys-admin can then apply any required > packages or patches to the host to enable the attach to succeed. > Or, they may not be able to attach to the specific host if the > installed software is sufficiently incompatible with the environment > on the original machine. > > Once the attach has completed successfully, the XML file describing > the zone will be removed. If you try to install or clone to a > configured zone and there is an XML description for a detached zone > in the zonepath, we will give an error and won't proceed. > > The -F option for attach allows the sys-admin to force the attach > with no validation. This is useful in certain cases such as > a clustered environment or for backup/restore, but it does require > that the sys-admin is certain that the system is properly configured > to host the zone or undefined behavior may later occur. > > zonecfg create option > > To facilitate configuring the detached zone on a new host we will > add a new '-a' option to the create subcommand within zonecfg. > > The subcommand for creating a new zone from the detached XML data > will be: > > zonecfg:my-zone> create -a path_to_zone_root > > The -a option will used the XML description of the detached > zone to configure the new zone instance. It is not required to > to configure the new zone this way. That is, the new zone > can be configured using the traditional zonecfg operations and > then "zoneadm attach" can be used to attach the zone root. > All of the validation of the zone happens during attach, not > during configuration of the zone. > > EXAMPLE > > host1# zoneadm -z my-zone detach > > - move the my-zone zonepath from host1 to host2 > > host2# zonecfg -z my-zone > my-zone: No such zone configured > Use 'create' to begin configuring a new zone. > zonecfg:my-zone> create -a /export/zones/my-zone > zonecfg:my-zone> commit > zonecfg:my-zone> exit > host2# zoneadm -z my-zone attach

> > Here is an example where some packages and patches are out of sync > between the source host and the local host we are attempting to attach > to. The actual syntax of the error messages will be different in the > final implementation, this is just an example to give an idea of what > might happen. > > host2# zoneadm -z my-zone attach > source host packages inconsistent with local host > SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch > (2.6.0,REV=101.0.3.2005.12.19.21.22) > SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch > (11.11,REV=2006.01.03.00.45) > SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed > SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch > (11.11,REV=2006.01.03.00.45) > NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed > local host packages inconsistent with source host > SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed > SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed > source host patches inconsistent with local host > 120081 is not installed > 118844 is not installed > 118344 is not installed > local host patches inconsistent with source host > 118669 was not installed > 118668 was not installed > 116299 was not installed > > EXPORTED INTERFACES > > zoneadm subcommands > detach EVOLVING > attach [-F] EVOLVING > zonecfg create subcommand option > -a path EVOLVING > > IMPORTED INTERFACES > > /var/sadm/install/contents Contracted Unstable > (LSARC/2004/464) > /var/sadm/pkg/*/pkginfo Contracted Unstable > > A contract is part of this case. > > pkginfo(4) public > VERSION keyword evolving (pkginfo(4)) > PATCHLIST keyword public (psarc/1995/063)

> > REFERENCES > > 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris > 2. RFE: Ability to migrate zones across machines Bugid 5022513 > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513 > _______________________________________________ > zones-discuss mailing list > zones-discuss at opensolaris dot org > _______________________________________________ zones-discuss mailing list zones-discuss at opensolaris dot org Posts: 531 From: Menlo Park, CA Registered: 3/11/05 [Nov 12, 2006] The Sun BluePrints Guide to Solaris Containers: Virtualization in the Solaris Operating System (pdf) Find out how to create, use, and integrate Solaris Containers in a new "mini-book" with detailed examples... 1. Introduction to Solaris Zones 2. Non-Global Zone Configuration (Overview) 3. Planning and Configuring Non-Global Zones (Tasks) 4. About Installing, Halting, and Uninstalling Non-Global Zones (Overview) 5. Installing, Booting, Halting, and Uninstalling Non-Global Zones (Tasks) 6. Non-Global Zone Login (Overview) 7. Logging In to Non-Global Zones (Tasks) 8. Moving and Migrating Non-Global Zones (Tasks) 9. About Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Overview) 10. Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks) 11. Solaris Zones Administration (Overview) 12. Solaris Zones Administration (Tasks) 13. Troubleshooting Miscellaneous Solaris Zones Problems [Nov 10, 2006] Virtually Speaking Sun's Virtual Expansion

Solaris 10 11/06, the next build of the operating system, will be released at the end of November. The version will include new capabilities for Containers. Admins will be able to clone a Container as well as relocate it to another box, through a feature called Attach/Detach, Wake said. [Nov 10, 2006] OpenSolaris Zones Presentation (pdf) by Narayana Janga and Shivani Khosa. (BigAdmin) Presentation on Zones and OpenSolaris given at ApacheCon US 2006. [Aug 24, 2006] BigAdmin - Submitted Tech Tip Zone Replication on the Solaris 10 OS in Five Easy Steps by David Steed The following is coffeeware -- instructions rather than software. If you use this, you are obligated to buy me a coffee... at your convenience. These instructions describe a very simple method of moving a local zone from one machine to another (using the Solaris 10 OS). Given: Two physical machines, with no shared storage The same Solaris 10 version installed Machine Y with one fully populated local zone installed (and nothing inherited) Machine Z with no zones installed (Z can also be an additional zone on the same machine)

Here are the five easy steps: 1. Log in to the console of a zone running on machine Y and create a full flash (this does not work properly with an image created from a global zone!). Example:
zonename # flarcreate -n "machineY" -S /machineY.flar (anywhere but /tmp)

2. Copy the following files from machine Y to machine Z:

The newly created flash image

/etc/zones/index

(merge it with the existing index file) (rename to machineZ.xml and edit

/etc/zones/machineY.xml

appropriately)
/export/zones/machineX/root/ (machineX /export/zones/machineX/dev/

3. Create the following:

directory with 700 perms)

4. Split the flash image (flar split machineX.flar), then move the file "archive" to /export/zones/machineX/root/, and unpack it with cpio -i.

Uncompress if necessary (mv archive archive.Z; uncompress archive.Z)

cd

to the machineX/root directory: cpio -i < /export/archive

5. Boot the machine with zoneadm -z machineZ boot and log in -- the devices will be built at that time. Sysid information is normally required at this point ... Don't forget: send an invitation for coffee to D@vidSteed.com and I will accept! Re: zone migration Posted: Jan 21, 2006 1:46 AM in response to: jamesd Reply

On Fri 20 Jan 2006 at 10:45PM, James Dickens wrote: > Hi > > sorry but i think there is a little more work to do, > > >3. Zone Configuration. The system administrator creates the zone > > configuration on the new host using zonecfg(1m). > > this should be automated and perhaps give the user a chance to edit > the resulting config on the target server. It really wouldn't be much > work, and it makes the whole process painless. Later someone else can > do a script that does zonemove zonename zonename@remotebox maybe > even load ballancing can be had for us poor folks that dont want the > time and expense of having identical hardware of a cluster. James, doesn't the 'zonecfg create -a' subcommand which Jerry described in the document do what you want? Could you be more specific about what you'd like (i.e. a specific use case with a little more detail)? To give an example, you will be able to trivially invoke it with: # zonecfg -z newzone create -a path_to_zone_root # zoneadm -z newzone boot Or, you can invoke it interactively, and make edits: # zonecfg -z newzone zonecfg:newzone> create -a path_to_zone_root zonecfg:newzone> add net ...

I'd like to better understand your concerns. Thanks, -dp -Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp