Chapter 5 Shared Resources

This chapter explains how to use Sun Update Connection – Enterprise with Shared Resources support for z/VM platforms.

On a zSeries S/390 running Virtual Systems from VM/ESA V2R4, z/VM V3R1, or later, you can create minidisks. A minidisk is allocated space consisting of consecutive cylinders on a specified DASD volume, which acts as a separate device. A minidisk is owned by one VM user; it cannot exist without the virtual user. Only one minidisk owner has read-write access at any time; other users may share it with read-only access.

Sun Update Connection – Enterprise supports sharing only of the /usr and /opt directories of the minidisks in their Linux environment. The Linux image running on a minidisk must have version 4 of RPM.

This chapter covers the following topics:

• Defining Master Hosts and Sharing Hosts

• Sharing Resources - Why and How

• Using Master Groups and Custom Groups

• Deploying Jobs With Sharing Hosts

Defining Master Hosts and Sharing Hosts

A VM user is a definition of resources, some real and some virtual, allocated for use or sharing by one username.

USER LNXDLB01 CORP 64M 128M G

00142	INCLUDE CMSPROF
00143	IUCV ALLOW
00144	IUCV ANY
00145	OPTION QUICKDSP
00146	ACCOUNT XXXXXXX CORP
00147	NOPDATA
00148	DEDICATE 5C7 5C3
00149	DEDICATE 5C8 5C4
00150	LINK MAINT 291 291 RR
00151	MDISK 0191 3390 1 1 WORK04 MR
00152	MDISK 0208 3390 001 1100 WORK0B MR
00153	MDISK 0209 3390 001 1100 WORK0C MR
00154	MDISK 0201 3390 001 1100 WORK05 MR
00155	MDISK 0203 3390 451 150 WORK02 MR

A master host is a VM user, running a Linux image that includes an Sun Update Connection – Enterprise agent, and that can share a minidisk with other Linux images.

A sharing host is a VM user, running a Linux image that includes an Sun Update Connection – Enterprise agent, that has read-only access to the minidisk that a master host shares with it.

Master hosts have full access to the resources of the Linux image of the VM user. sharing hosts have links to the resources of a master host.

Sharing Resources - Why and How

Sharing resources saves space by sharing duplicate files across a Linux network. For example, you might have 30 networked systems all running Linux. The systems are grouped by function, so some of them have directories that are almost identical to the other computers in their group. If you think of these systems as VM users on a zSeries running Linux, you can save space by not sharing directories.

To save space, and to make like systems consistent, specific directories on minidisks can be shared. Sun Update Connection – Enterprise automatically locks these directories, so that the owner of the minidisk has full access, but sharing hosts have read-only access. Automatically fulfilling this requirement saves the VM operator time and makes sure the system is secure and consistent.

Another Shared Resources requirement is that the sharing hosts have specific mount points to the shared minidisk. This is also fulfilled automatically by Sun Update Connection – Enterprise.

Mount Points for Shared Directories

Sun Update Connection – Enterprise manages software, so efficient sharing in an Sun Update Connection – Enterprise system concentrates on software-relevant directories. Sun Update Connection – Enterprise shared resources support is relevant to Linux operating system directories, not user-defined directories.

The most important shared directories are /usr and /opt.

The /usr directory contains system libraries, administrative commands and files, and the main files for installed applications. When you install an application, its main parts go in the /usr directory. Other directories hold the configuration files and data, the type of things that you want to sometimes change. Sharing the /usr directory means that multiple VM users (master host and sharing hosts) can use the same applications, although the largest part of the package is be installed only once (on the master host).

The directories that you want to share must be mounted in /proc/mounts of both the master host and the sharing hosts.

Master Host and Sharing Host Synchronization

When you install an application on a Linux image, some files are installed in directories other than /usr. Therefore, when you use Sun Update Connection – Enterprise to install an application on a master host, the same job must run on all of the sharing hosts of the master host. The application is installed only once, but every sharing host requires the dependent components installed in other directories.

Failing to maintain duplicate installation procedures between a master host and its sharing hosts causes synchronization errors. Such errors disable management on the unsynchronized sharing hosts. Sharing hosts that do not perform the same installation job as its master host cannot function as a managed host of Sun Update Connection – Enterprise.

To automatically maintain synchronization, Sun Update Connection – Enterpriselimits jobs that include sharing hosts..

The following synchronization limits apply:

• You cannot send a job to only one or some of the sharing hosts of one master host; you must send it to the master host only. Sun Update Connection – Enterprise ensures that the sharing hosts also receive the job.

• RPM jobs must be sent to a master host that is online. If the master host is down, the job fails.

• Every managed host must have either zero or one master host. It must either be a master host or have only one master.

To Create a Master Host

1. Define a VM user with read or write access to some minidisks.

2. At the end of the profile exec a file, type the line: ipl <dev #>

3. Upload Linux (with the DDR utility) onto <dev #>.

4. Start the new VM user from any 3270 emulation.

5. Change the TCP/IP of this new Linux image with the ifconfig command.

6. Fix the routing table and then connect with telnet to the new VM user.

7. Change the network configuration with YAST (5-6) to be permanent.

8. Restart Linux.

9. Copy the agent.tgz file to the new VM user Linux operating system.

10. Untar the file and type ./Install to start the agent ezInstaller.

11. After the agent is installed, view the agent configuration file.

    vi /opt/local/uce/agent/bin/uce.rc

12. Find the mf_shared_path parameter and check the value for this parameter. The value should be /usr or /opt, according to the directory that you want this sharing host to access from its master.

    If the value is incorrect, copy the entire line of this parameter to the .uce.rc file and edit the value to be the correct directory. When the Sun Update Connection – Enterprise agent is installed on this VM user, you have a master host.

To Create a Sharing Host

1. Define a VM user that, in addition to its own minidisks, has links to the minidisks of another VM user, with read-only access.

   The VM user that controls the linked resources is the master host of this sharing host.

2. At the end of the profile exec a file, type the line: ipl <dev #>

3. Upload Linux (with the DDR utility) onto <dev #>.

4. Start the new VM user from any 3270 emulation.

5. Edit the /boot/parm file: add (ro) near dev # items that are owned by the master host. Example: dasd=xxxx-yyyy, 202 (ro), zzz

6. Edit the /etc/fstab file: specify read-only mount points for the shared disks; make sure that the last two parameters on the line are “0 0”.

7. Do a silo/zilo.

8. Change the TCP/IP of this new Linux image with the ifconfig command.

9. Fix the routing table and then connect with telnet to the new VM user.

10. Change the network configuration with YAST (9-10) to be permanent.

11. Restart Linux.

12. Copy the agent.tgz file to the new VM user Linux operating system.

13. Untar the file and type ./Install to start the agent ezInstaller.

14. After the agent is installed, view the agent configuration file.

    vi /opt/local/uce/agent/bin/uce.rc

15. Find the mf_shared_path parameter and check the value for this parameter. The value should be /usr or /opt, according to the directory that you want this sharing host to access from its master.

    If the value is incorrect, copy the entire line of this parameter to the .director.rc file and edit the value to be the correct directory. When the installed agent starts, it discovers that it is running on a shared disk environment and registers its VM user as a sharing host on the system dependency server. When an agent starts, a master host writes its master signature in /<shared_path>/.aduva_master

    A sharing host attempts to write to the same path. It finds that it does not have write permissions, reads the .aduva_master file and discovers both that it is a sharing host and who is its master.

To Unregister a Sharing Host From the System Dependency Server

1. Take the sharing host offline.

2. In the Hosts window, select the host from the All Hosts Group.

3. Click Delete.

4. In the confirmation dialog box that opens, click Delete.

To Unregister a Master Host From the System Dependency Server

Before You Begin

Ensure that the master host and all of its sharing hosts are offline.

1. In the All Hosts Group, select the Master Host, then click Delete.

2. In the confirmation dialog box that opens, click Delete.

3. Select the icon for the empty Master Group, then click Delete.

Using Master Groups and Custom Groups

A group is a set of managed hosts to which you can send jobs simultaneously. There are two types of groups:

• Master Group. Contains the master host and all its sharing hosts. A job cannot be sent to only one of the hosts in a Master Group; the entire group must receive any job.

• Custom Group. Contains any set of master hosts that you choose. If the hosts do not have sharing hosts, the group can run and successfully deploy jobs. If any one of the hosts in a Custom Group has sharing hosts, jobs cannot be deployed on this group.

When you create privileged users with Permitted Groups, the groups must be complete Master Groups. You cannot assign a Custom Group as a permitted group, even it contains only hosts without sharing hosts.

The Hosts window displays icons to indicate the type of the groups and the type of managed host.

Table 5–1 Hosts Window and Groups Tab Icons

Icon	Name	Description
	Default Group	All Hosts group, or distribution groups.
	Custom Group	User-defined logical group of managed hosts. Use Custom Groups to organize the system for easy management. Custom Groups can contain the following:  A host list of any master hosts you choose Nested Custom Groups
	Master Group	Automatically created group of master host and the sharing hosts that have read-only access to the master’s resources. To maintain synchronization, use the Master Group. The Master Group must meet the following requirements:  Contain only the master and sharing hosts Cannot contain nested Custom Groups
	Master Host	An individual Linux operating system with full access to all its directories, with an installed agent, and maintaining an operational connection to the dependency manager.
	Unsynchronized Master Host	Master host has at least one sharing host that is not synchronized  Click Synchronize to fix this problem.
	Disconnected Master Host	Master host that has lost its connection to the DM.
	sharing host	A minidisk with read-only access to the directories of a master host that is configured to share its resources with this minidisk.
	Disconnected Sharing Host	A managed host that is not currently connected to the dependency manager.

---

Note –

Sun Update Connection – Enterprise creates a Master Group only after a master host has at least one sharing host. Every Master Group contains at least two managed hosts: the master host and the sharing host.

---

The Hosts window also shows a new button: Synchronize. Use this feature to create a job that runs only on sharing host, to synchronize it with its master host. This button is available only while Sun Update Connection – Enterprise is in Sharing Mode; it is enabled if you select a sharing host that is not synchronized with its master.

In the Hosts window, when you have selected either a sharing host or a Master Group, the New and Properties buttons are disabled.

Deploying Jobs With Sharing Hosts

In an Sun Update Connection – Enterprise system without sharing hosts, you can run any job on any host or any group. You can create Custom groups of any combination of master hosts.

Once you have created a sharing host, there are limitations to the jobs that you can deploy.

Job Restrictions

Synchronization between the sharing hosts and their master host must be maintained. Therefore, jobs that include sharing hosts have special limitations, to ensure and to troubleshoot synchronization.

The following limitations apply to deploy jobs with a host list that includes at least one sharing host:

• The complete Master Group must be included on the host list

• Only one job can be run on a Master Group at any time

• After the Master completes a job, all of its sharing hosts must complete the job

Job Processes

After Sun Update Connection – Enterprise confirms that the entire Master Group has been selected for a job with sharing hosts, the job begins.

1. The job is sent to the master host on the host list.

2. The agent of the Master runs the Dependency Resolver and job procedures.

3. On success:

   • If the Masters in the host list do not have sharing hosts, the job ends.

   • If it is a Simulate mode job, Sun Update Connection – Enterprise checks the sharing hosts and then the job ends.

   • If it is a Deploy job, Sun Update Connection – Enterprise checks that the sharing hosts are synchronized with their master host. If this check is successful, the sharing hosts take the job solution that the master host used and run the same tasks. sharing hosts do not try to find a new solution; they must follow the same steps that their Master took.

If a Problem Occurs

Unsynchronized Sharing Host
Situation	An error is given for a sharing host in the Status window, stating that the host is not synchronized with its Master.
Explanation	A sharing host was unable to successfully complete a job and is no longer synchronized with its master host.
Solution	1. Select the sharing host in the Hosts window. The Synchronize button is enabled. 2. Click Synchronize. A job beings that works on only this sharing host. It makes any changes necessary to make the software configuration of the sharing host compatible with the master host. The Synchronize Job feature is available only to an user with full permissions, and can be run on only one sharing host at a time.