Common First Time Mistakes - Containers

Containers in Solaris 10 features an interesting virtualization technology called zones. Local zones are amazingly easy to configure and install, but there are a few things that can trip you up the first few times.
  1. Local zones require system identification
    Since each local zone has its own /etc, it can have a different identity from that of the global zone (timezone, locale, root password). So we need to supply some basic configuration information about the local zone. If you are experienced with Solaris you will recognize the system identification process that runs at first boot. Solaris 10 adds the NFS V4 domain mapping question which must be answered in addition to supplying an /etc/sysidconfig file. We'll deal with that later.

    The complication presented by local zones is that you can use zlogin(1) to enter a local zone before it has completed it's system identification. This is not possible for the global zone, nor a prior Solaris release - so you may not even consider this a possibility when diagnosing your first few zones configuration problems.

    The symptoms are that you can enter the zone using zlogin(1), but nothing else works. You cannot get in via ssh, rlogin, or telnet even through they have been configured properly (or so you believe at this point). Your first step in diagnosis should be an svcs -a and you will see service states of unitialized. This is the clue!

    If you look all the way back in the service states you will see there is a service called sysidtool (that calls the service script /lib/svc/method/sysidtool-system). This is where system identification is done (and if you look at the method you will discover how to answer the NFSV4 question).

    The resolution is simple - connect to the local zone console using zlogin -C and answer the identification questions.

    If you are using the Java Desktop System then terminal type 12 (xterms) will provide the best results.

    You will also experience this problem if your sysidconfig file contains an error. The most common errors are incorrect specifications of the timezone and root password.

  2. Failure to answer the NFS V4 question
    You can script the creation of a local zone and supply default identification through the use of an /etc/sysidconfig file. Experienced Solaris adminstrators will recognize this method from unattended jumpstart installs. Solaris 10 requires one additional configuration item that isn't satisfied by /etc/sysidconfig: the NFS V4 domain mapping question.

    Automating the NFS V4 configuration requires 2 steps. First, specify the value of NFSMAPID_DOMAIN in $zonepath/root/etc/default/nfs. Finally, you need to create a file called $zonepath/root/etc/.NFS4inst_state.domain to let sysidtool know that you have answered the question.

  3. The local zone root directory is $zonepath/root
    If the lab equipment is sufficiently fast then we have a little competition in the Containers workshop. The challenge is to completely automate the installation of a local container and provision an application (typically Apache or MySQL) as well as set up root access via telnet, rlogin, or ssh - but do it in a single script with no intervention. Run the script and the next step is to connect to the provisioned service.

    After 10 minutes of scripting work, and another 10 minutes for a local zone to install, there are always a few exclamation of "Doh" as the student realized that they dropped in a sysidconfig to $zonepath/etc rather than $zonepath/root/etc.

  4. Make sure the mountpoints exit for all file system being supplied by zoneadmd
    Supplying lofs file systems via the zone configuration file (see zonecfg man page) is a convenient way to share files between zones (including the global zone). The advantage of this method is that zoneadmd performs the loopback mount from the privileged global zone as it readies the local zone, thus the local zone isn't permitted to undo this mount. If the mount point (in the local zone) does not exist then the zone will fail to boot.

  5. Network not being plumbed will cause a local zone to fail to boot
    This one is rather unique to the mobile user. For convenience you may have your global zone boot without networking configured. Once you log in then you can run a simple script to plumb up your network interfaces based on how you need to connect (fixed IP address at home or in a lab, DHCP in a hotel, etc). If your local zones have network resources, which is typically the case, the network interfaces must be plumbed up in the global zone prior to booting the local zone. This one has gotten me more than once in a customer demonstration.

Technocrati Tags:

Bob, This is some good information. I took your Solaris 10 Boot Camp in St. Louis a few months back. I can't wait to see the deep dive come to St. Louis. Any way, I've been unable to find any good information on setting up the /etc/sysidconfig file to do a fully automated install of a zone. You also mentioned there was a contest going on to create a single script to automate the zone creation. Do you by chance have a copy of this script to share or a copy of a sysidconfig file that can be used as a template? Thanks, Dan Fayette

Posted by Dan Fayette on January 05, 2006 at 01:11 AM CST #

Hi Bob, really enjoyed the Solaris boot camp at UTD last month. And now I'm finally getting around to building some zones on my sparc. One question... I've got a single nic with a static address. Can't get any more static addresses. Is it possible to config the local zone to be a dhcp client. I've been digging around the docs and can't find anything that indicates either way. thanks, Robert Smith

Posted by Robert Smith on February 20, 2006 at 07:44 AM CST #

Hey Dan,
Sorry it's taken me so long to get back to you on your question. It would be lot easier if you had the entire Containers in a Day workshop, but rather than wait until my last edits are complete, I've posted the relevent section from the lab at

The next time I hold a workshop I'll collect all the scripts and post the best ones, but for now this should be able to help you get a working sysidcfg and answer the NFSv4 question.

And I just got word that the St. Louis Solaris Deep Dive is confirmed for March 23 (don't know the venue or how to register, but I'll post that as soon as I get the information). Hope to see you there!

Posted by Bob Netherton on February 21, 2006 at 02:48 AM CST #

Hey Robert,
Didn't get a chance to say hello, but did see you in the crowd. Thanks for coming!

At present, zoneadmd will not make a DHCP request at the time it readies the local zone, so address bindings are rather fixed. I know there has been some discussion about providing this capability, but I haven't been keeping up with it.

One really clever solution is to use the global zone for Network Address Translation (NAT). See Mike Ditto's blog entry at to see how to do this.

If you really had to get a DHCP address for your local zone, I suppose you could do this manually from the global zone using ifcconfig -zone to dynamically add an interface to a running zone, but that is rather ugly and the sort of thing that might lead to breakage in the future.

If you want to follow this discussion (or instigate it ) I would encourage you to hop over to the OpenSolaris zones community.

Hope this helps.

Posted by Bob Netherton on February 21, 2006 at 03:05 AM CST #

Post a Comment:
  • HTML Syntax: NOT allowed

Bob Netherton is a Principal Sales Consultant for the North American Commercial Hardware group, specializing in Solaris, Virtualization and Engineered Systems. Bob is also a contributing author of Solaris 10 Virtualization Essentials.

This blog will contain information about all three, but primarily focused on topics for Solaris system administrators.

Please follow me on Twitter Facebook or send me email


« July 2016