9.3 Creating images

As a server farm grows, day-to-day administration can become cumbersome. With Linux on the mainframe, you can plan your installation with a view to ease installation and administration of new servers. z/VM gives you unique possibilities to create virtual Linux servers in a matter of minutes.

Before you install Linux, you can benefit from planning ahead. List your Linux images and decide what categories they fit in, and think about whether you want to take advantage of code sharing. Code sharing can be direct, by having a read-only disk that all images can access, or by copying from one golden image. z/VM can support all these choices.

Creating a virtual Linux server is a two-stage affair. You first create a virtual machine, then you can install a Linux image to run in it.

Normally, the system administrator logs on to a CMS guest console and uses the control program functions to configure the virtual hardware for the new virtual machine (guest). Each virtual machine, or guest, in z/VM is known by a unique ID that is used as part of the logon process. In the Linux usage of z/VM, we refer to this logon ID as the guest name. The software and data that reside on disks are then made available to the new guest.

These disks are typically of two types: system disks that contain the system executable libraries and system parameters and data disks that contain the unique data to be used by the Linux image while it is running its applications.

Then the administrator can boot the Linux image that resides on a disk defined to the new guest. (The booting of the Linux image is called Initial Program Load (IPL) in the mainframe world.) z/VM isolates the guests from each other (see 8.2.4, "Virtual security") so that if one guest should crash, the others are not impacted.

You can create the virtual machine and define disk or minidisks with z/VM's DirMaint or a similar program product. DirMaint allows you to use profiles and prototype files, so you can create hundreds of virtual servers quickly and easily with no conflicts of resources. (See Linux on IBM zSeries and S/390: ISP/ASP Solutions for detailed instructions.)

Having created a virtual machine, you can proceed to install a Linux image in it. For a small number of images, you could install each Linux guest from scratch, as you would with a set of CDs from one physical server to the next. If you require a large number of images, then some Linux distributions offer a means of repeated installs (such as the YaST shortcuts in SuSE and the mkkickstart utility in Red Hat). However, using z/VM, there is another simple way to avoid such repeated installs.

Without even having a single Linux image running, the z/VM utilities allow you to copy and duplicate a guest's disks. Companies can install and configure one Linux image; and when they are satisfied with that image, they use the z/VM copy utilities to create a master copy, called the golden image. The golden image is then copied to produce the next Linux image. This process of copying is often referred to as cloning Linux images. See Figure 9-2.

Figure 9-2. Cloning Linux images

When cloning Linux images, a small number of modifications must be made in order for the new image to be useful. For example, the host name and IP address must be changed. An efficient cloning scheme keeps these changes to a minimum. Even if more changes are needed, it can simplify setup to use the golden image as a base. However, an image with many modifications, for example, a different application suite or a different level of glibc, is not strictly a clone, but a new unique image. Each unique image requires separate administration effort. Keeping the number of unique images down saves administration cost.

When cloning z/VM Linux images, you need to copy the virtual machine definition and the disks. Typically, the disks that contain the system executable libraries and much of the system parameters are cloned, while the local data disks are just defined and initialized. The new guest must have a unique identity. Hence z/VM unique items (such as the guest name and local disks, on the one hand) and Linux items (such as the host name, IP address and root password, on the other hand) need to be changed.

Figure 9-3 shows a guest being cloned into another guest. The first ("golden") guest has two disks with system data and one disk with image-specific data. For example, A000 could contain the kernel and glib, A001 could contain data that needs customizing (such as the IP address) and A002 could contain the applications or databases. In the copy process, the system data are copied over. The second disk will need some customization pertaining to the new image. The third will be filled by the owner of the guest and is separate from the cloning process.

Figure 9-3. Cloning Linux images by using VM guests

Cloning with z/VM gives you a unique opportunity to save disk space. When you create Linux images by copying minidisks, if you were to place the system data on one minidisk and then for each image simply define a read-only link to it, you in effect have only one real instance. This is shown in Figure 9-4. Hundreds of users can then share the disk. In addition to saving disk space, having a read-only disk makes it easier to administer the environment and control change. You must, however, check your particular distribution for what parts of the file system can easily be shared.

Figure 9-4. Saving disk space by linking read-only disks

9.3.1 Disk space requirements and file system layout

Almost all currently available Open Source executable programs fit in less than 4 GB of disk space. The file system is usually organized into a hierarchy, depending on the files. Concentrating files that need read-only access in one file system makes it possible to save disk space by sharing the file system among Linux guests. Some typical directories found in a Linux file system are:

/usr	The /usr directory contains commands and applications. This directory is a candidate for sharing among Linux guests.
/opt	The /opt directory typically contains additional software packages, such as KDE3 or gnome. The benefit of installing applications under a separate file system is that you can upgrade Linux without re-installing the applications, and vice versa. This directory is a candidate for sharing among Linux guests.
/var	The /var directory is often allocated as a separate file system (not under /). A separate /var file system can help avoid a system halt due to overflowing log, spool, or mail files. Such problems are easier to track and take corrective action when /var is a separate file system. Also, it is possible to set certain file system parameters for the /var file system in order to speed up creation and deletion of file blocks. This directory cannot be shared among Linux guests.

A planned code hierarchy simplifies setup of servers and helps simplify both a cloning process and software maintenance. A more detailed description of the Linux directory structure is in 20.2, "Overview of Linux directory structure."

9.3.2 Example Linux guest directory

The example Linux guest directory below shows the standard definition used by ISPCompany. The standard guest has 256 MB of storage, a Guest LAN, a HiperSockets connection, links one read-only disk, and defines two read-write minidisks. Customization for this directory is limited to changing the user ID (or guest name) and passwords. For ISPCompany, these changes can easily be done (for example, over the phone, while the customer is waiting).

 USER LINUXE XXXXXX 256M 1024M G    INCLUDE LINDFLT                         /Links standard DIRMAINT definitions    SPECIAL EE00 QDIO 3 SYSTEM LINQDIO      /Adapter for QDIO Guest LAN    SPECIAL FF00 HIPER 3 SYSTEM LINHIPER    /Adapter for Hipersocket Guest  LAN    LINK LINUX0 A000 A000 RR                /Link the read-only common disk    MDISK A001 3390 1 2000 LIN008 MR RXXX WXXX MXXXX      /Define minidisk A001    MDISK A002 3390 1 2000 LIN009 MR RXXX WXXX MXXXX      /Define minidisk A002 

Standard settings that are common across all the Linux guest directory entries can be made available through the INCLUDE command.