A field guide to Zones in OpenSolaris 2008.05

I have had a busy couple of months. After wrapping up work on
Solaris 8 Containers (my teammate Steve ran the Solaris 9 Containers effort),
I turned my attention to helping the Image Packaging
team (rogue’s
gallery
) with their efforts to get OpenSolaris 2008.05 out the door.

Among
other things
, I have been working hard to provide a basic level of
zones functionality for OpenSolaris 2008.05. I wish I could have gotten
more done, but today I want to cover what does and does not work. I
want to be clear that Zones support in OpenSolaris 2008.05 and beyond will evolve
substantially
. To start, here’s an example of configuring a zone on
2008.05:

# zonecfg -z donutshop
donutshop: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:donutshop> create
zonecfg:donutshop> set zonepath=/zones/donutshop
zonecfg:donutshop> add net
zonecfg:donutshop:net> set physical=e1000g0
zonecfg:donutshop:net> set address=129.146.228.5/23
zonecfg:donutshop:net> end
zonecfg:donutshop> add capped-cpu
zonecfg:donutshop:capped-cpu> set ncpus=1.5
zonecfg:donutshop:capped-cpu> end
zonecfg:donutshop> commit
zonecfg:donutshop> exit
# zoneadm list -vc
ID NAME             STATUS     PATH                           BRAND    IP
0 global           running    /                              native   shared
- donutshop        configured /zones/donutshop               ipkg     shared

If you’re familiar with deploying zones, you can see that there is a lot which is familiar here.  But you can also see that donutshop isn’t, as you would normally expect, using
the native brand. Here we’re using the ipkg brand. The
reason is that commands like zoneadm and zonecfg have
some special behaviors for native zones which presume that you’re using
a SystemV Packaging based OS. In the future, we’ll make native less
magical, and the zones you install will be branded native as you would expect. Jerry is actually
working on that right now. Note also that I used the relatively new
CPU
Caps
resource management feature to put some resource limits on the
zone– it’s easy to do!. Now let’s install the zone:

# zoneadm -z donutshop install
A ZFS file system has been created for this zone.
Image: Preparing at /zones/donutshop/root ... done.
Catalog: Retrieving from http://pkg.opensolaris.org:80/ ... done.
Installing: (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  49/49   7634/7634 206.85/206.85
PHASE                                        ACTIONS
Install Phase                            12602/12602
Note: Man pages can be obtained by installing SUNWman
Postinstall: Copying SMF seed repository ... done.
Postinstall: Working around http://defect.opensolaris.org/bz/show_bug.cgi?id=681
Postinstall: Working around http://defect.opensolaris.org/bz/show_bug.cgi?id=741
Done: Installation completed in 208.535 seconds.
Next Steps: Boot the zone, then log into the zone console
(zlogin -C) to complete the configuration process

There are a couple of things to notice, both in the configuration
and in the install:

Non-global zones are not sparse, for now
Zones are said to be sparse if /usr, /lib,
/platform, /sbin and optionally /opt are
looped back, read-only, from the global zone. This allows a substantial
disk space savings in the traditional zones model (which is that the zones
have the same software installed as the global zone).

Whether we will ultimately choose to implement
sparse zones, or not, is an open question. I plan to bring this question to the Zones community, and to some key customers, in the near future.

Zones are installed from a network repository
Unlike with traditional zones, which are sourced by copying bits from the global
zone, here we simply spool the contents from the network repository.
The upside is that this was easy to implement; the downside is that
you must be connected to the network to deploy a zone. Getting the bits
from the global zone is still desirable, but we don’t have that implemented
yet.

By default, zones are installed using the system’s
preferred authority (use pkg authority to see what
that is set to). The preferred authority is the propagated into the
zone. If you want to override that, you can specify a different
repository using the new -a argument to zoneadm install:

# zoneadm -z donutshop install -a ipkg=http://ipkg.eng:80
Non-global zones are small
Traditionally, zones are installed with all of the same software
that the global zone contains. In the case of "whole root" zones
(the opposite of sparse), this means that non-global zones are about
the same size as global zones– easily at least a gigabyte in size.

Since we’re not supporting sparse zones, I decided to pare down
the install as much as I could, within reason: the default zone
installation is just 206MB, and has a decent set of basic tools.
But you have to add other stuff you might need. And we can even
do more: some package refactoring should yield another 30-40MB
of savings, as packagings like Tcl and Tk should not be needed
by default. For example, Tk (5MB) gets dragged in as a dependency
of python (the packaging system is written in python); Tcl (another
5MB) is dragged in by Tk. Tk then pulls in parts of X11.
Smallness yields speed: when connected to a fast package repository
server, I can install a zone in just 24 seconds!.

I’m really curious to know what reaction people will have to such
minimalist environments. What do you think?

Once you start thinking about such small environments, some new concerns surface: vim (which in 2008.05 we’re using as our vi implementation)
is 17MB, or almost 9% of the disk space used by the zone!

Non-global zones are independent of the global zone
Because ipkg zones are branded, they exist independently
of the global zone. This means that if you do an image-update
of the global zone, you’ll also need to update each of your zones,
and ensure that they are kept in sync. For now this is a manual
process– in the future we’ll make it less so.
ZFS support notes
OpenSolaris 2008.05 makes extensive use of ZFS, and enforces ZFS
as the root filesystem. Additional filesystems are created for
/export, /export/home and /opt. Non-global zones don’t yet follow this convention.
Additionally, I have sometimes seen our auto-zfs file system
creation fail to work (you can see it working properly in the example above). We haven’t
yet tracked down that problem– my suspicion is that there is a bad interaction
with the 2008.05 filesystem layout’s use of ZFS legacy mounts.

As a result of this (and for other reasons too, probably), zones don’t
participate in the boot-environment subsystem. This means that you
won’t get an automatic snapshot when you image-update your
zone or install packages. That means no automatic rollback for zones.
Again, this is something we will endeavor to fix.

Beware of bug 6684810
You may see a message like the following when you boot your zone:

zoneadm: zone 'donutshop': Unable to set route for interface lo0 to éÞùÞ$
zoneadm: zone 'donutshop':

This is a known bug (6684810); fortunately the message is harmless.

In the next month, I hope to: take a vacation, launch a discussion with
our community about sparse root zones, and to make a solid plan for
the overall support of zones on OpenSolaris. I’ve got a lot to do,
but that’s easily balanced by the fact that I’ve been having a blast
working on this project…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s