Wednesday Nov 09, 2005

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 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


« November 2005 »