System information

Sharing and maintaining SLES 10 SP2 Linux under z/VM 53
6. Test the read-only root system.
7. When both systems are fully tested copy them to the gold read-write disks via MNT2GOLD
and RO2GOLD.
Now the change should be reflected in any new Linux system that is cloned, be it read-write
or read-only. Of course this does not affect any of the Linux systems already in existence.
Updating the cloned servers
Performing maintenance on existing Linux servers is a little more difficult. The following
approach is just one option. This is very similar to the approach being used at Nationwide.
Assume the gold disks are now at version 2. Assume the Linux clones are still at version 1
and that the read-write directories have changed. These changes must be accounted for.
The first step in the update process should be to make a copy of each cloned server to be
updated, allowing for fallback if necessary. After the update, these disks should be preserved
for a suitable period of time.
Next, create duplicate minidisks for the read-write data. In this paper, that would mean the
minidisks 1B5 and 1B6. Temporarily put them at different addresses, for example 5B5 and 5B6.
Copy the contents of the version 2 gold disks to these new disks.
The next step is to merge the contents of the cloned server’s read-write disks (1B5->5B5,
1B6->5B6). New files that did not exist in version 1 of the gold disks are now on the new
disks. Files on the old minidisks (1B1,1B6) but not on the new version (5B1,5B6) should be
copied onto the new. Finally, review the files that are in common between the two read write
volumes, but have been updated by maintenance. These steps can be accomplished via the
rsync and diff commands. When these changes have been made, the server can use the
updated read-only root minidisks. If there is any problem, the system can be rolled back to the
previous version of gold minidisks.
1.7.2 A more detailed maintenance methodology
This methodology was implemented at Penn State University. It adds a second NOLOG user ID,
S10GOLD2, which contains a set of minidisks for another read-only golden Linux image. This
second user ID stores the next Linux system that is to be rolled out while the current system
remains stored on S10GOLD. Individual read-only Linux systems can be migrated to the new
system simply by modifying the disks they link to.