OMEGAMON XE for. z/vm and Linux v4.3.0

Transcription

1 OMEGAMON XE for z/vm and Linux v4.3.0 Installation and Configuration Cook Book Document version 1.2 John Harris IBM Corporation All rights reserved

2 SPECIAL NOTICES This document is presented As-Is and IBM does not assume responsibility for the statements expressed herein. It reflects the opinions of the IBM Cloud and Smarter Infrastructure organization and these opinions are based solely on the authors experiences. If you have questions about the contents of this document, please contact the author at Trademarks The following are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. IBM, the IBM logo, Candle, DB2, developerworks, iseries, Passport Advantage, pseries, Redbooks, Tivoli Enterprise Console, WebSphere, z/os, xseries, zseries, System z, z/vm, AIX. A full list of U.S. trademarks owned by IBM may be found at NetView, Cloud and Smarter Infrastructure and TME are registered trademarks and TME Enterprise is a trademark of Tivoli Systems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, Internet Explorer, and the Windows logo are registered trademarks of Microsoft Corporation in the United States and/or other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. Intel and Pentium are registered trademarks and MMX, Pentium II Xeon and Pentium III Xeon are trademarks of Intel Corporation in the United States and/or other countries. Other company, product and service names may be trademarks or service marks of others. ii

3 CONTENTS Special Notices... ii Revision History...1 Acknowledgments Introduction Architectural Overview IBM Tivoli Monitoring Components Pre-requisites Version SmartCloud Monitoring pre-requisites Summary of z/vm Commands used in this Cook Book Defining & Configuring the DCSS on z/vm (Required z/vm v5.2) Defining the required DCSS...12 Log onto the Performance Toolkit virtual machine (user account)...12 Calculate the DCSS storage requirements...12 Define a new DCSS Enable CP Monitoring Domains on the Performance Toolkit Enabling Sample and Event data collections Starting and Stopping monitor data collections Determining the current monitor interval...17 iii

4 7.4. Automating the collecting of the monitoring data Start the data collection on the PERFOUT DCSS Verifying the Status of the Monitor Collectors Configure TCPIP on z/vm Modify the TCPIP guest s directory entry...21 Logon to the MAINT virtual machine Modify TCPIP Profile...21 Logon to the TCIP virtual machine Enable APPLMON on z/vm Linux guest machines Modify the Linux guests directory entry Configure the DCSS Device Driver on Linux Identify the PERFOUT DCSS Start and End Addresses Defining the Linux guests storage gaps...24 Logon to the Linux guest virtual machine (userid) Extending the Linux address range Loading the DCSS Device Driver Add the PERFOUT DCSS to the Linux guest Loading the PERFOUT DCSS at start-up (Optional) Determining the DCSS Naming scheme Install the z/vm System data collecting agent...29 iv

5 13.1. Installing the Agent Configuring the agent Start/Stop the Tivoli Monitoring Agent for z/vm Take Action Commands (Optional)...30 Running under Linux as a non-root user...31 Loading the vmcp device driver...32 Verify that Take Action commands are being issued Enable a Linux guest machines data collection Start the collection of the User Appldata at the Linux guest...34 Setting the sampling interval Automating the collection of Linux data at start-up Enable Dynamic Workspace Linking (DWL) on the Linux guest machines Modify the lz.ini file Recycle the Tivoli Monitoring Agent for Linux OS Installing the OMEGAMON Command Server on z/vm (Optional) Installation Pre-requisites Upload the product envelope file (if not using a tape unit)...39 FTP the file to z/vm by entering the following commands...40 On z/vm, Copy and unpack the envelope file Installation Planning...40 Logon to 5698A36D virtual machine...40 Create a PROFILE EXEC for accessing MAINT s minidisks...40 Attach a tape device to 5698A36D...41 v

6 Load OMEGAMON product control files to MAINT s 51D minidisk...41 Obtain OMEGAMON resource planning information Installing OMEGAMON Command Processor...43 Logon to 5698A36D virtual machine...43 Install Command Processor...43 Update the Build Status Table for OMEGAMON Copy OMEGAMON files into Production...45 Access the production minidisks...45 Update the VMSES/E PARTCAT file...45 Copy local sample files to the OMEGACMD A (191) minidisk Take Action Commands (Optional) Appendix A - Problem Determination Appendix B - Applying Maintenance to OMEGAMON Command Server on z/vm (Optional) Prepare to receive service...58 Logon to 5698A36D virtual machine (userid)...58 Attach a tape device to 5698A36D...58 Receive the documentation...59 Set up the product access order...59 Merge previously applied service to ensure a clean APPLY disk Receive the service Apply the service Update the Build Status Table Build the service objects Copy OMEGAMON service files into Production...62 Access the production minidisks...62 vi

7 Update the VMSES/E PARTCAT file Appendix C Installation Quick Reference Guide z/vm Tasks Linux Tasks...64 vii

8 REVISION HISTORY Date Version Revised By Comments 2 July JH Created v4.3.0 document 1 August JH Updated with additional v4.3.0 content 18 Sept JH Updated for DCSS restrictions 1

9 ACKNOWLEDGMENTS Thanks to the following person(s) for their invaluable assistance. Robert (Bob) Neill and William (Bill) Maddox IBM Tivoli OMEGAMON XE for z/vm and Linux developers. This document can be found on the web at Search for author s name under the category of White Papers. 2

10 1. Introduction The primary focus of this document is to provide a reader who has a limited knowledge of z/vm and/or Linux with a simple process in order to install and configure an operational OMEGAMON XE on z/vm and Linux agent environment. It is the assumption of this author that OMEGAMON XE for z/vm and Linux version (Product Code 5698A36) is being installed. Note: Version 4.3 supersedes v4.2.0.x as well as all previous versions. Any previously installed versions will be upgraded to v4.3. This current release supports a reduced set of functionality on z/vm v5.4 and it is recommended that the z/vm system be upgraded to a minimum of v6.2. z/vm v6.1 is no longer in service. The OMEGAMON XE on z/vm and Linux monitoring agent is installed and runs as a process on a z/vm Linux guest. This agent obtains z/vm and Linux data from a Discontiguous Saved Segment (DCSS), which is populated by the z/vm Performance Toolkit. The acquired data is displayed in the Tivoli Enterprise Portal and includes the ability to dynamically link from the z/vm workspaces to the underlying Linux guest systems. This capability drastically reduces the mean time to resolution (MTTR) for problem determination enabling support personnel to more easily work across platform boundaries. There are two agents required for monitoring z/vm and its Linux guest virtual machines One agent which monitors the z/vm environment, namely The OMEGAMON XE on z/vm and Linux monitoring agent is installed and runs as a process on a Linux guest. The agent obtains the data from the Performance Toolkit running on z/vm via the DCSS. The other agent monitors each Linux guest machine via the provided Linux Operating System agent. This operating system agent needs to be installed on all the Linux guests that need to be monitored. What is not covered in this document is the installation of the Tivoli Management Services (TMS) infrastructure components, namely the Tivoli Enterprise Monitoring Services (TEMS), Tivoli Enterprise Portal Server (TEPS) including dependent database, Tivoli Enterprise Portal (TEP), Tivoli Data Warehouse (TDW) and the Tivoli Monitoring for Distributed Systems (Linux OS agent). It is assumed that all the above TMS components have all been previously installed and that this installation will be done using z/vm mini-disks rather than the Shared File System (SFS). The following steps will be performed: z/vm Configuration Tasks 1. Install OMEGAMON Command Processor (Optional) 2. Define and Configure DCSS (Required on z/vm v5.2) 3

11 3. Configure TCPIP on z/vm 4. Enable CP Monitoring Domains 5. Enable APPLMON on Linux guest machines 6. Start data collect on PERFOUT DCSS Linux Configuration Tasks 7. Configure DCSS Device Driver on Linux 8. Install and Configure the z/vm data collecting (vl) agent 9. Enable a Linux guest machine data collection 10. Enable Dynamic Workspace linking For a complete description of the agent attributes, see the IBM Tivoli OMEGAMON XE on z/vm and Linux User's Guide. This document and related information on OMEGAMON XE for z/vm and Linux as well as the other products on the OMEGAMON family can be found on the following links. Wiki : Online Documentation : This Document : 4

12 2. Architectural Overview The following figure depicts the OMEGAMON XE on z/vm and Linux monitoring architecture. The environment includes a Conversational Monitor System (z/vm CMS) guest running the Performance Toolkit, which in-turn collects the data from the z/vm system and writes it out to the default (z/vm v5.3+) PERFOUT discontiguous saved segment (DCSS). The data is then read by the OMEGAMON XE on z/vm and Linux monitoring agent using the z/vm DCSS device driver support in Linux and displayed in the TEP. Another z/vm guest is used as a z/vm command server, which receives command requests from the TEP Client by means of the Take Action feature which is used in order to execute z/vm commands on the z/vm system. The data from both the z/vm DCSS and each monitored Linux guest system is displayed in the TEP Client GUI via the TEMS and TEPS components. 5

13 3. IBM Tivoli Monitoring Components The IBM Tivoli Monitoring components consists of the following as shown in the diagram below. Tivoli Enterprise Portal (client GUI environment) Tivoli Enterprise Portal Server Tivoli Enterprise Management Server(s), either HUB or Remote(s) which are the destination point to which an agent would connect to Tivoli Data Warehouse for the long-term data repository 6

14 4. Pre-requisites In order to maximize the use of your time during the installation and configuration process, ensure that the following pre- requisites are in place beforehand: A minimum of IBM Tivoli Monitoring v6.2.3 and above infrastructure (TEMS, TEPS and DB2) including the support version of DB2 is required and currently installed and configured beforehand. The minimum hardware and software requirements can be found in the ITM documentation System programmer has access to z/vm MAINT, PERFKIT and TCPIP virtual machines. For details on the relevant APAR(s) and their corresponding PTF(s) requirements as well as instructions for installing Service (Program Directory) to the Performance Toolkit see the support page documenting the formatted output collectors of the Performance Toolkit located at the following address: Ensure that the Linux guest, required by the OMEGAMON XE on z/vm and Linux agent itself is defined and active and that the system administrator has root authority to this Linux guest account, The following guest operating systems are supported OS must be SLES 9 for System z FP3+ in 31-bit or 64-bit modes) SLES v10/v11 for System z 64-bit mode RHEL v4 Update Level 6+ in 31-bit or 64-bit mode RHEL v5/v6 for System z in 64-bit mode For RHEL v5, the IBM Runtime Java Environment (RJE) for Linux on System z depends on shared libraries that are not installed by default. The installation of this monitoring agent, the Linux OS as well as the infrastructure components (TEMS/TEPS) require the following libraries to be installed o libxp (all platforms) o compat-libstdc o compat-libstdc (System z) The Linux version must also support the Korn shell (ksh) for installation of the monitoring agent. The Linux system to be used for the OMEGAMON VL agent should have a minimum of 1GB of memory available to it (RHEL does not load with less than 512MB while SLES can load in 256MB) 7

15 5698A36D and OMEGACMD are the default user IDs and can be changed. They should be defined beforehand using the site preferred mechanism (directly modifying USER DIRECT or via a tool such as DIRMAINT) o 5698A36D - used for installing and apply service to the Command Processor facility o OMEGACMD Command Processor userid used for executing VM commands on behalf of TEPS users, etc. The Linux Operating system agent needs to be installed on each Linux guest system that needs to be monitored and must have Linux Monitor stream support enabled which is provided by Linux Kernel and later. A pre-requisite checker can be run in order to verify the system prior to installation and can be found in the <install_media>/unix/prereqchecker directory. From a Linux terminal session navigate to the directory and issue the following command which will display a PASS or FAIL message../prereq_checker.sh "KVL" detail 4.1. Version Version contains the following enhancements: o Autonomous Agent support Each agent can emit SNMP traps and Event Integration Facility events to an event server for agent specific events without the need to be connected to monitoring server. o The Monitoring agent now supports the Self Describing Agent (SDA) functionality associated with the ITM infrastructure o Single System Image (SSI) support Each z/vm LPAR requires it own agent instance o Live Guest Relocation (LGR) support o SCSI Emulated FBA device support o Cognos reports New Performance and Capacity management reports o IBM Dashboard Application services Hub support (Jazz for Service Management) o OMEGAMON XE for z/vm and Linux v4.3.0 is not supported on z/vm v6.1 OMEGAMON XE for z/vm and Linux v4.2.0.fix Pack 5 or later must be installed instead. o Monitoring agent requires ITM v6.2.3 Fixpack 3 (TEP, TEPS, TEMS) or later o SmartCloud for z/vm Dashboards requires ITM v6.3 (TEP, TEPS, TEMS) or later o Updates to this function are now delivered as part of the normal service stream for Performance Toolkit for z/vm and is supported on z/vm v5.4, z/vm v6.2 and z/vm v6.3. The latest version of the Performance Toolkit must be installed. 8

16 4.2. SmartCloud Monitoring pre-requisites If you are installing the OMEGAMON XE on z/vm and Linux agent for use with IBM SmartCloud Monitoring which uses the Portal server attribute groups for the OMEGAMON XE on z/vm and Linux agent, make sure that the following prerequisites are installed: o IBM Tivoli Monitoring v6.3 with dashboard data provider enabled in the portal server configuration o OMEGAMON XE on z/vm and Linux agent V4.3.0 o Monitored z/vm system that is configured as specified in Enabling the CP Monitor domains To link from the z/vm SmartCloud Monitoring dashboards to the operating system dashboards (Linux on System z), the following steps are required: o Make sure that the operating system dashboards are installed o Enable Linux Application monitor data collection in the guests that you want to monitor from z/vm. o For information on enabling the collection of data, enable the collection of Linux data as defined below 9

17 5. Summary of z/vm Commands used in this Cook Book The following list of commands is used during the various installation and configuration steps documented below: ACCESS Connects a real or logical device to a userid ATTACH Assigns a real device (rdev) to a virtual device (vdev) CPFMTXA Formats a device DEFSEG Defines a new file for a saved segment DEF STOR Changes the storage/memory size of a virtual machine (userid) DIRECTXA Verify control statements and/or update the user directory DIRM Runs the IBM directory maintenance utility LINK Access another user s files on a particular mini-disk MONITOR Controls the selection, collection, and reporting of data from the host system QUERY DISK Display the currently accessed minidisks QUERY TAPE Display the currently accessed tape devices QUERY MONITOR INTERVAL Displays the current monitoring interval in effect on z/vm QUERY NSS ALL Display a list of the all the currently defined saved segments QUERY NSS ALL MAP Display a list of the all the currently defined saved segments including their size, starting and ending addresses and number of users currently using the saved segment QUERY NSS NAME PERFOUT Displays the same inform as the ALL option but only for the PERFOUT saved segment QUERY NSS NAME PERFOUT MAP Displays the same inform as the ALL MAP option but only for the PERFOUT saved segment QUERY NSS USERS PERFOUT Display a list of the current users connected to/using the PERFOUT saved segment QUERY TAPES ATTACHED * Displays a list of tape devices attached to the current user QUERY VIRTUAL STORAGE Display a list of the current named saved segments SAVSEG Saves the page range areas previously specified by a DEFSEG command VMFCOPY VMSES/E REXX module to copy source files to target files VMFINS VMSES/E REXX module used for planning/installing software VMFREC VMSES/E REXX module to receive service file(s) from tape VMFSETUP VMSES/E REXX module to setup the product access order VMFVIEW VMSES/E REXX module to view message log files 10

18 XEDIT OBEYFILE VM/CMS based editor Dynamically apply TCPIP configuration changes 11

19 6. Defining & Configuring the DCSS on z/vm (Required z/vm v5.2) The Performance Toolkit collects both the z/vm hypervisor and Linux guest s data which is then written to a DCSS. This DCSS must be defined to z/vm v5.2 and below prior to use by either the Performance Toolkit or the monitoring agent. This is not required on z/vm v5.3+ as a default DCSS called PERFOUT is provided with the Performance Toolkit. The size of the default DCSS PERFOUT provided by z/vm v5.3+ is large enough to meet the needs of your specific environment and therefore you can skip to Section 8, otherwise the following sections defines the required PERFOUT DCSS using z/vms defaults. Actual commands that will be issued during the sections below are highlighted in blue Defining the required DCSS The Performance Toolkit collects the z/vm data as well as the Linux guests data which is then written to the PERFOUT discontiguous saved segment (DCSS). This DCSS must be defined to z/vm prior to use by either the Performance Toolkit or the OMEGAMON vl agent. Log onto the Performance Toolkit virtual machine (user account) You need to log onto this virtual machine (userid) as the DCSS sizing executable is provided by the Performance Toolkit. Ensure that this virtual machine has the authority (Privilege Class : E) in order to create a DCSS. It is assumed that the only the MAINT user account has the correct authority to define a new DCSS. Calculate the DCSS storage requirements The default size of the product provided DCSS called PERFOUT should be sufficient size in order to meet your needs. This section will verify that your production environment does indeed fit into that memory address range. You can verify that the product defined DCSS called PERFOUT has been created by issuing the following command: QUERY NSS NAME PERFOUT 12

20 This will return something similar to the following information *NSS 0038 NSS A /21 12:00:31 PERFOUT DCSS OMEGAZVM In order to identify the page address associated with the PERFOUT DCSS, enter the following command. QUERY NSS NAME PERFOUT MAP This will return something similar to the following information 0038 PERFOUT DCSS N/A 08A00 08FFF SN A N/A N/A In order to list all the current saved segments defined within the z/vm environment issue the following command. QUERY NSS MAP If you are defining your own DCSS then record the values below and use them when prompted by size calculator, which will prompted for the following information, where you do not have a specific value for the item enter a 1 at the prompt. Defined LPARs Monitored disk devices Paging and SPOOLing areas Logged-on users (include all service machines) HiperSockets devices Network virtual switch devices Network server virtual machines Network users Linux virtual machines LPAR processor engines z/vm channels LPAR channels FICON channels Enter the following command in order to run the calculator: FCXSEGSZ After entering values for each of the above listed items It is recommended that a DCSS of at least 6MB should be defined in order to cater for the future growth of the system and avoid having to continually redefine a new DCSS. The following lines are sample output for a 16MB DCSS. Minimum SEGOUT segment allocation needed (bytes, in decimal): Minimum SEGOUT segment allocation needed (pages, in decimal): 4096 Minimum SEGOUT segment allocation needed (bytes, in hexadecimal):

21 Minimum SEGOUT segment allocation needed (pages, in hexadecimal): 1000 If you are satisfied that the currently predefined PERFOUT DCSS is sufficient size to meet your needs continue onto Section 7. below. Define a new DCSS This section will verify that your production environment does indeed fit into that memory address range. The new DCSS is limited to fitting within a 2GB memory range. Use the size of pages in hexadecimal provided by the running the calculator program above. Minimum SEGOUT segment allocation needed (pages, in hexadecimal): 256 Review the output of the QUERY NSS MAP command in order to identify a non-overlaying address range for the new saved segment Note : Ensure that the DCSS address range does not overlap any of the previously defined saved segments, especially the CMS and MONDCSS segments. This can be verified by issuing the following command and checking for any possible memory overlaps QUERY NSS MAP It is recommended that the new DCSS be defined above the memory address of the z/vm Linux guest in the guest is less than 2GB in size. Delete the existing PERFOUT DCSS using the following commands QUERY NSS USERS PERFOUT verify no users connected PURGE NSS NAME PERFOUT delete actual DCSS Create the new DCSS by entering the following command DEFSEG PERFOUT Begpage-Endpage SN PERFOUT is the default name for the new saved segment Begpage is the starting address in hex of the new DCSS Endpage is the ending address in hex of the DCSS, calculated as (Begpage + size -1) Example : Define a 6MB saved segment starting at 8A00 extending to 8FFF (138MB-144MB) DEFSEG PERFOUT 8A00-8FFF SN Once the segment has been defined, save it by entering the following command SAVSEG PERFOUT 14

22 7. Enable CP Monitoring Domains on the Performance Toolkit The data records written to the DCSS are based on the types of records with which they are associated. You must enable the CP Monitor domains for each type of data that needs to be collected and must be performed on the z/vm system where the Performance Toolkit is running. This enables the various types of data to be able to be written to the DCSS and displayed in the Tivoli Enterprise Portal for this monitoring agent. If a domain is disabled, no data for that particular domain is written to the DCSS. The use of the CP MONITOR SAMPLE and EVENT commands requires privilege class E. The MONITOR SAMPLE and/or MONITOR EVENT domains that must be enabled for each type of data to be collected are included below. The SYSTEM and MONITOR domains are enabled for sample monitoring at all times and cannot be disabled from sample data collection Enabling Sample and Event data collections Logon to the Performance Toolkit virtual machine Monitor information for Channels, LPARs, HiperSocket devices, Spin Locks, System Health, Processor and Minidisk Cache are part of the SYSTEM domain as does not need to be separately activated. You can elect to enable all the EVENT and SAMPLE counters with a single command which includes all the required OMEGAMON counters #CP MONITOR EVENT ENABLE ALL #CP MONITOR SAMPLE ENABLE ALL The performance Toolkit collects all the data that it can and this can cause a considerable load on the system if EVENT data has been enabled for all users in a large system. In order to reduce the overhead use the USERID user1 user2 usern parameter in place of ALL in you only want to monitor data from specific virtual machines. Alternatively issue the following commands individually for the various domains. Monitor information for Network Server and Users (TCPIP) and Linux guest workloads. Use the above USERID parameter in order to limit the data to specific VM guest machines. #CP MONITOR SAMPLE ENABLE APPLDATA ALL #CP MONITOR EVENT ENABLE APPLDATA ALL Monitor information for I/O. Use the CLass, DEVice TYpe or VOLumea parameters to limit the data in order to reduce the overhead that would be generated in installations with 1000s of devices. 15

23 #CP MONITOR SAMPLE ENABLE I/O ALL Monitor information for Processor information #CP MONITOR SAMPLE ENABLE PROCESSOR #CP MONITOR EVENT ENABLE PROCESSOR Monitor information for Paging and Spooling areas and Virtual disks (CP-owned mini-disks) #CP MONITOR SAMPLE ENABLE STORAGE Monitor information for Live Guest Relocation information #CP MONITOR EVENT ENABLE USER ALL Monitor information for Logged on Users. Use the USERID parameter in order to limit the data to specific VM guest machines #CP MONITOR SAMPLE ENABLE USER ALL Monitor information for Single System Image (SSI) installations #CP MONITOR SAMPLE ENABLE SSI In order to disable the collecting of the Event and Sample monitoring data replace the ENABLE parameter with DISABLE in the above commands 7.2. Starting and Stopping monitor data collections Start the actual sample monitoring for the enabled domains and elements defined above by issue the follow command: #CP MONITOR EVENT START #CP MONITOR SAMPLE START or #CP MONITOR START Stop collecting the monitoring data: #CP MONITOR EVENT STOP #CP MONITOR SAMPLE STOP or #CP MONITOR STOP 16

24 7.3. Determining the current monitor interval Issue the following command in order to determine what the current monitoring interval value is #CP QUERY MONITOR INTERVAL 7.4. Automating the collecting of the monitoring data Add the commands defined above to the PROFILE EXEC of the PERFSVM machine before the line starting the Performance Toolkit E.g. - Do Not include the.. as that denotes additional commands that might exist in the file. /* Performance Toolkit Profile EXEC */ /* Monitor Sample/Event Collectors */ #CP MONITOR SAMPLE ENABLE APPLDATA ALL #CP MONITOR EVENT ENABLE APPLDATA ALL #CP MONITOR SAMPLE ENABLE I/O ALL #CP MONITOR SAMPLE ENABLE PROCESSOR #CP MONITOR SAMPLE ENABLE STORAGE #CP MONITOR SAMPLE ENABLE USER ALL /* Start Monitor */ #CP MONITOR SAMPLE START #CP MONITOR EVENT START /* Start Performance Toolkit */ PERFKIT 17

25 8. Start the data collection on the PERFOUT DCSS Now that the saved segment has been defined (z/vm v5.2) or available (z/vm v5.3+) it is necessary to issue a Performance Toolkit subcommand in order to turn on the formatted output collectors. Issue the following command after logging onto the Performance Toolkit virtual machine. FCONTROL MONCOLL SEGOUT ON PERFOUT The above command assumes that you are using PERFOUT as the default name of your DCCS otherwise substitute the name of your installations DCSS. The command should be included in the initialization profile FCONX $PROFILE file so that the collection of the data is activated every time the Performance Toolkit service machine is restarted. Verify that the Performance Toolkit is writing to the DCSS by logging onto the Performance Toolkit machine and issue the following command from the PerfKit console: FC MONCOLL SEGOUT QUERY The above command should return the following response if the data collection on the PERFOUT DCSS is active FCXOMC772I SEGOUT data collection is active. Using segment: PERFOUT 18

26 9. Verifying the Status of the Monitor Collectors Once the above steps have been performed you can verify that the required monitor Sample and Event counters have been enabled correctly. Perform either of the following options 1. Perform the following steps on z/vm in order to enable and configure TCPIP data. Logon to the Performance Toolkit (PERFSVM virtual machine) and select option E as shown below 19

27 The following screen will highlight the status of the Monitor Collectors in the Event and Sample columns 2. Alternatively the status of the above required collectors and be seen in the Tivoli Portal as shown below in the Collector Status column. 20

28 10. Configure TCPIP on z/vm Perform the following steps in order to enable and configure TCPIP data Modify the TCPIP guest s directory entry Logon to the MAINT virtual machine The TCPIP virtual machine must be authorized to create monitor data records and you need to ensure that the guest s directory entry includes the APPLMON option. This can be done by using a directory maintenance utility such as DIRMAINT or if done manually by editing the USER DIRECT file from the MAINT virtual machine (userid). Ensure that the APPLMON option is added to the current OPTIONs or insert a new line into the guest s directory entry as indicated for user TCPIP below: USER TCPIP IUCV ALLOW MACHINE XA OPTION APPLMON If you have manually edited the file, save the changes and issue the following command. DIRECTXA USER DIRECT (EDIT The EDIT option enables you to verify of the directory control statements. If this returns without any error, re-issue the command without the EDIT option. DIRECTXA USER DIRECT Modify TCPIP Profile The PROFILE TCPIP file normally resides on the TCIPIP machines 198 minidisk, which is normally accessed by a filemode of D. If the PROFILE TCPIP file contains the MONITORRECORDS ALLRECORDS statement, you do not need to update the PROFILE TCPIP file. However, be aware that the MONITORRECORDS ALLRECORDS statement yields data that is not used by the monitoring agent, and could result in excessive data collection. It might be prudent to change it to MONITORRECORDS MOSTRECORDS (default). 21

29 Logon to the TCIP virtual machine Edit the file PROFILE TCIP using the z/vm editor XEDIT PROFILE TCPIP Search for a current MONITORRECORDS definition F MONITORRECORDS If the above text already exists with either ALLRECORDS or MOSTRECORDS then exit by entering QQ, otherwise add the following statement to the file by issuing the commands on the command line and press Enter after each command. BOTTOM INPUT MONITORRECORDS MOSTRECORDS FILE If changes need to be made to the PROFILE TCPIP file then restart the TCPIP Virtual Machine or issue the following command which will dynamically add the changes to the TCPIP environment without requiring a stop/start of the TCPIP service machine. OBEYFILE filename [filetype] [filemode] [TCP server] where filename filetype filemode reflects the name of a CMS file that contains TCP/IP configuration statements, use the original PROFILE TCPCIP file to ensure that changes will be permanent on the next restart of the TCPIP service machine. The file type defaults to TCPIP and the file mode defaults to A. TCP server reflects the user ID of the TCP/IP virtual machine whose configuration you want to change. If this option is not used, OBEYFILE addresses the TCP/IP machine identified in the TCPIP DATA file. Note The OBEYFILE command is issued from CMS. It instructs TCP/IP to read a new configuration information file (the obey file) while it is running. In order to issue this command, your user ID must be included in the OBEY list in the configuration file. 22

30 11. Enable APPLMON on z/vm Linux guest machines Data collection for the KVLUser ApplData attribute group which displays the Linux memory usage, workload activity and network utilization data must be enabled on each Linux guest system that is to be monitored Modify the Linux guests directory entry Before any User ApplData can be collected for this attribute group you need to ensure that the guest s directory entry includes the APPLMON option. This can be done by using a directory maintenance utility such as DIRMAINT or if done manually by editing the USER DIRECT file from the MAINT virtual machine. Ensure that the APPLMON option is added to the current OPTIONs or insert a new line into the guest s directory entry as indicated in the subset of a dummy user s directory entry below: USER DUMUSER DEMOVM BG INCLUDE LINDFLT IUCV ALLOW MACHINE XA OPTION APPLMON DEDICATE FCC0 FCC0 DEDICATE FCC1 FCC1 DEDICATE FCC2 FCC2 If you have manually edited the file, save the changes and issue the following command DIRECTXA USER DIRECT (EDIT The EDIT option enables you to verify of the directory control statements. If this returns without any error, re-issue the command without the EDIT option. DIRECTXA USER DIRECT 23

31 12. Configure the DCSS Device Driver on Linux These steps are associated with the Linux guest system that will be running the OMEGAMON XE on z/vm and Linux (product code vl) agent only. Before configuring the device driver the required DCSS must have been previously defined, see Identify the PERFOUT DCSS Start and End Addresses Before the PERFOUT DCSS device driver can be configured on the Linux guest, you need to know the start and end addresses of the DCSS defined on z/vm. This can be done by issuing the command QUERY NSS NAME PERFOUT MAP The above command will give you the start and end addresses of the defined DCSS in units of 4KB pages and the out returned will be similar to the following: FILE FILENAME FILETYPE MINSIZE BEGPAG ENDPAG TYPE CL #USERS PARMREGS VMGROUP 0038 PERFOUT DCSS N/A 08A00 08FFF SW A N/A N/A The parameters of interest are indicated above in red. They need to be converted to megabytes (MB) using the formula: ((No_Pages (decimal) / 256) 8A00 = 138MB 8FFF = 144MB If the start address of the DCSS falls within the z/vm Linux guest s memory range, proceed to Step 12.2 below. If the start address of the DCSS falls above the z/vm Linux guest s memory range, proceed to Step 12.3 below Defining the Linux guests storage gaps As the start address of the DCSS falls within the Linux Guest s storage/memory address range, you need to ensure that the Linux guest steps around the DCSS and does not overwrite the contents on this memory address range. This task is performed on the actual z/vm virtual machine representing the Linux guest prior to starting the Linux operating system. 24

32 Logon to the Linux guest virtual machine (userid) Using the information provided under Step 8.1 above, the following command can be used to ensure that the Linux guest system excludes the DCSS address range. DEFINE STORAGE CONFIG 0.Gap_start Gap_end.Storage_above_gap Gap_start Gap_end Storage_above_gap defines the lower limit of the storage gap defines the upper limit of the storage gap defines the amount of storage above the gap (Total Linux guest storage size Gap_start) The above values can be suffixed with M to provide values in MB. Once the above command has be successfully applied, re-ipl the Linux operating system and then proceed to Step 8.4. Example: Make a 6MB DCSS that starts at 138MB and ends at 144MB accessible to a z/vm guest with 512MB guest storage. Here I am giving it an extra 2MB at the START and 1MB at the END of the DCSS for a total gap of 9MB: DEFINE STORAGE CONFIG 0.136M 145M.376M On z/vm v5.3+ the above command can be added to the USER DIRECT using the COMMAND instruction. In order to facilitate this add the following line to the user s entry in the user directory file for above example. USER LINXSVR01 LNXSVR01 512M 512M G INCLUDE LNXDFL COMMAND DEFINE STORAGE CONFIG 0.136M 145M.376M Note: These commands are executed before the virtual machine is IPLed. Multiple COMMAND statements may be included in a virtual machine's directory definition. They are performed in the order they are defined in the directory entry. The COMMAND statements must precede any device statements for the virtual machine. COMMAND statements may be included in directory profiles, in which case they will be executed for each virtual machine which uses the profile. If a virtual machine has additional COMMAND statements in its own user definition, the commands in the profile will be executed first and then the user's defined commands. Commands are case-sensitive, which implies that any command operand parsed by CP must be in the required (usually upper) case. Operands not parsed by CP, such as the message text for a MESSAGE command, may use mixed case. Any form of a command may be invoked using this mechanism, regardless of the command privilege class of the virtual machine. That is, the command is executed as if 25

33 the virtual machine is authorized for all privilege classes. The syntax used for the command must take this into account. The COMMAND statement is only supported in z/vm5.3 and above. Issue the DIRECTXA USER DIRECT command in order to load the change. Logoff to the Linux Guest machine, shutting down Linux OS first, and then log back on in order to activate the new memory settings. Proceed to Section 12.4 below Extending the Linux address range Even though the start address of the DCSS falls above the Linux Guest s storage/memory address range, you will need to make the DCSS s storage/memory range accessible to the Linux system. This is done by adding a parameter to the /etc/zipl file. The Linux command referenced below requires root authority and it is recommended that you log onto this Linux system as root before processing any command or use the Linux su facility. Using your preferred editor, add the following command to the parameters keyword/line in [ipl] section of the /etc/zipl.conf file and save the changes: mem=<address> <Address> is an address at or above the upper limit of the DCSS and can be in either KB (K suffix) or MB (M suffix). By default add 2MB to the value specified. CAUTION: Be extremely careful when editing the /etc/zipl.conf file. Any typographical errors made while editing the /etc/zipl.conf file will disable your Linux system, rendering it unbootable. Once the above change has been made issue the following command in order to save the configuration zipl and re-boot the Linux guest system. Example: Reserve storage for a DCSS that starts at 138MB and ends at 144MB accessible to a z/vm guest with 128MB guest storage, the parameter would be mem=146m The resultant parameters keyword/line would look something like the following: parameters = "root=/dev/disk/by-id/ccw- IBM cd part1 26

34 TERM=dumb mem=146m" You can review /proc/cmdline file for the mem=xxxx parameter in order to ensure that the configuration change has been updated correctly. This can be done by issue the following command: cat /proc/cmdline Loading the DCSS Device Driver Logon onto the z/vm Linux guest as root and perform the following steps to load and configure the DCSS device driver /sbin/modprobe dcssblk Note: If you intend to use the automatic start-up process as described in Section 11.6 below, DO NOT modify the ownership of above file as the start-up process runs under the root ID. If the agent is running under another user other than root, change the ownership of the DCSS device to that user to the agent access to the DCSS. E.g. if the agent is running user the itmuser ID, issue the following command: chown itmuser /dev/dcssblk Add the PERFOUT DCSS to the Linux guest Run the following command to add the PERFOUT DCSS to the Linux guest: echo PERFOUT > /sys/devices/dcssblk/add Loading the PERFOUT DCSS at start-up (Optional) Configure the Linux guest to automatically load the PERFOUT DCSS at system start-up by adding the following commands to the /etc/rc.d/boot.local file on SUSE or /etc/rc.d/rc.local file on RedHat using your preferred editor: /sbin/modprobe dcssblk echo PERFOUT > /sys/devices/dcssblk/add 27

35 Save the file Determining the DCSS Naming scheme A major number is automatically allocated when a DCSS device driver is loaded. Enter the following command it to display the major number for your DCSS: ls l /dev/dcss* When you add a DCSS, a minor number is assigned to it. Unless you use dynamically created device nodes as provided by udev, you might need to know the minor device number that has been assigned to the DCSS. The standard device names are of the form dcssblk<n>, where <n> is the corresponding minor number. The first DCSS device that is added is assigned the name dcssblk0, the second dcssblk1, and so on. When a DCSS is removed, its device name and corresponding minor number are free and can be reassigned. A DCSS that is added always receives the lowest free minor number. 28

36 13. Install the z/vm System data collecting agent The following steps are required in order to collect and report the z/vm hypervisor s data in the Tivoli Enterprise Portal. This agent needs to be installed on the Linux guest system that will be running the OMEGAMON XE on z/vm and Linux (product code vl) agent Installing the Agent Install the OMEGAMON XE on z/vm and Linux image from the product CD. This step assumes that IBM Tivoli Monitoring, ITM v6.2.x+ infrastructure has been previously installed. If you re installing as a non-root user, you will be prompted for the root password to update the auto start script. If you have the root password, enter it now. If you don t have the root password, press Enter when prompted for the root password. You will get an error message stating that the system is unable to update the auto restart script. Updating the auto restart script requires root authority. If you want the agent to start up automatically when the system is initialized, the root password is required. Run the following command from the directory where you extracted the product files:./install.sh Continue with the configuration of the monitoring agent by following the instructions presented on the console. During configuration of this monitoring agent, you will be prompted to enter the name of the DCSS. If you are using the default PERFOUT DCSS, press Enter. Otherwise, enter the name of the DCSS that you have previously defined. You may also be prompted to enter values associated with the following environment variables KVL_CMDUSERID Set this environment variable with the z/vm guest user ID of the system where the Command Processor was installed (OMEGACMD). If the z/vm guest user ID is not specified, the Command Processor will be disabled. Take Action events initiated by situations or submitted by you using the Take Action feature will not be processed. KVL_MSGTYPE This variable describes the type of message being used to process the commands. If a value is not specified, the Take Action feature is disabled otherwise you can set this environment variable to a value of either msg The monitoring agent uses the CP MSG command to send Take Action commands to the Command Processor virtual machine smsg 29

37 The monitoring agent uses the CP SMSG command to send Take Action commands to the Command Processor virtual machine The results of the Take Action commands can be viewed in the KVL log file, located on the guest system where the monitoring agent is installed Configuring the agent Change to ITM_HOME which is the directory where the OMEGAMON XE for z/vm and Linux agent was installed, normally /opt/ibm/itm cd <ITM_HOME>/bin Start the agent./itmcmd config A vl Provide the necessary responses to the questions Start/Stop the Tivoli Monitoring Agent for z/vm Change to ITM_HOME which is the directory where the OMEGAMON XE for z/vm and Linux agent was installed, normally /opt/ibm/itm cd <ITM_HOME>/bin Start the agent./itmcmd agent start vl Stop the agent./itmcmd agent stop vl Take Action Commands (Optional) The following requirements for Take Action commands pertain to the Linux guest hosting the OMEGAMON XE on z/vm and Linux monitoring agent: 1. Supported operating systems where the z/vm agent is running SUSE Linux Enterprise Server 9 for zseries, with Service Pack 3 or later Red Hat Enterprise Linux 4 Update 5 for zseries or later 2. The z/vm CP interface device driver (vmcp) must be available on the Linux guest on which the monitoring agent is running. The vmcp driver allows the monitoring agent to 30

38 issue CP commands, thus ensuring that Take Action commands are sent to the designated z/vm CMS guest user for processing. 3. sudo, the superuser do utility for Linux-based systems, is required for the monitoring agent to run with temporary root authority to send Take Action commands to the Command Processor virtual machine. The sudo utility must be available and configured on the Linux guest on which the monitoring agent is running. This utility allows a nonroot Linux guest user to run vmcp without having root authority. The sudo utility is generally pre-installed and available as part of the Linux operating system. Any working version is sufficient. Running under Linux as a non-root user In the following sections, we are assuming that the non-root user is named tivoli. If your nonroot user is named otherwise, please edit the commands accordingly Perform the following steps on the Linux system where you installed this monitoring agent: SUSE Linux Enterprise Server 9 Modify the file called /etc/sudoers. Using only visudo edit the file and add an entry for the Linux user specifying the command that this user is allowed to run as root as follows tivoli ALL=NOPASSWD:/usr/bin/vmcp SUSE Linux Enterprise Server 1. If installing and running as root or as a non-root user, modify the vl.ini file. Perform the following steps on the Linux system where you installed this monitoring agent: This file is located in the ITMinstall_dir/config directory, where: ITMinstall_dir is the directory where you installed IBM Tivoli Monitoring. Locate the PATH= environment variable for the non-root user and append the following statement to it: :/sbin 2. Modify the file called /etc/sudoers. Using only visudo edit the file and add an entry for the Linux user specifying the command that this user is allowed to run as root as follows tivoli ALL=NOPASSWD:/sbin/vmcp 3. Restart the monitoring agent by issuing the command /ITM_Home/bin/itmcmd agent start vl 31

39 Red Hat Enterprise Linux 1. If installing and running as root or as a non-root user, modify the vl.ini file. This file is located in the ITMinstall_dir/config directory, where: ITMinstall_dir is the directory where you installed IBM Tivoli Monitoring. Locate the PATH= environment variable for the non-root user and append the following statement to it: :/sbin 2. Modify the file called /etc/sudoers. Using only visudo edit the file and add an entry for the Linux user specifying the command that this user is allowed to run as root as follows tivoli ALL=NOPASSWD:/sbin/vmcp 3. Restart the monitoring agent by issuing the command /ITM_Home/bin/itmcmd agent start vl Review the IBM Tivoli OMEGAMON XE on z/vm and Linux Planning and Configuration Guide for details on enabling Take Action commands. Loading the vmcp device driver In order to load the vmcp device driver, issue the following command: /sbin/modprobe vmcp In order to automatically load the vmcp device driver at system start-up add the following commands to the /etc/rc.d/boot.local file on SUSE or /etc/rc.d/rc.local file on RedHat using your preferred editor. Use the full path name of the commands as the environment does not get defined by the boot strap process, but by each individual user that logs onto the system /sbin/modprobe vmcp Verifying that sudo is available by issuing the following command sudo vmcp q userid If sudo is active and loaded, this command sends the q userid command to the hosting virtual machine, which queries the user ID for the guest. Verify that Take Action commands are being issued In order to verify that the monitoring agent is sending commands to the Command Processor, issue the following command at the Linux guest: sudo vmcp smsg <userid> <TEP userid> cmd=<commandname> Where: 32

40 userid user ID of the z/vm guest (OMEGACMD) where the Command Processor is running TEP user ID user ID of the person authorized to issue Take Action commands in the Tivoli Enterprise Portal CommandName identifier for the command that the Command Processor must execute See the Planning and Configuration Guide for guidelines for issuing Take Action Commands NOTE If Self Describing Agent support is not enabled at the TEMS or the version of the monitoring agent Is lower than v4.3.0, be sure to install and enable the application support for this monitoring agent on the Tivoli Enterprise Monitoring Server (TEMS), Tivoli Enterprise Portal Server (TEPS) as well on any Tivoli Enterprise Portal Desktop (TEPD) systems. See Section 17 Appendix A - Problem Determination section, items 5 & 6, for related issues when applying the application support files to the TEMS/TEPS on Linux based host system. 33

41 14. Enable a Linux guest machines data collection Data collection for KVLUser ApplData attribute group needs to be enabled at each Linux guest system that is to be monitored. This will define the workgroup as a Linux workgroup and links are then displayed on a table that queries the systems in the Linux workgroup. This needs to be performed for every Linux system that needs to be monitored and it is assumed that the Tivoli Monitoring for Linux OS has already been installed and configured on those Linux systems. Log onto each Linux system machine as root or as the userid that owns the Tivoli resources and perform the following steps: Start the collection of the User Appldata at the Linux guest Issue the following commands (in blue) to start the data collection process: Load the collecting drivers /sbin/modprobe appldata_os /sbin/modprobe appldata_mem /sbin/modprobe appldata_net_sum Enable collecting echo 1 > /proc/sys/appldata/os echo 1 > /proc/sys/appldata/mem echo 1 > /proc/sys/appldata/net_sum Enable timer echo 1 > /proc/sys/appldata/timer Enable timer interval echo > /proc/sys/appldata/interval Note : Every Linux system should include the following statements at a minimum. echo 1 > /proc/sys/appldata/os echo 1 > /proc/sys/appldata/timer echo > /proc/sys/appldata/interval Setting the sampling interval The sampling interval determines how frequently new data is provided to the CP monitor. Setting the interval the Linux guest independently of the CP monitor sample interval provides a mechanism to provide a compromise between performance and current data. The format of the command to control the sampling interval is as follows: echo <milliseconds> > /proc/sys/appldata/interval 34

42 where <milliseconds> indicates the actual sampling interval to be used in milliseconds of CPU time. The value of above is the default sampling period of once every 10 seconds Automating the collection of Linux data at start-up In order to automatically enable the collection of Linux data at system start-up add the following commands to the /etc/rc.d/boot.local file on SUSE or /etc/rc.d/rc.local file on RedHat using your preferred editor. Use the full path name of the commands as the environment does not get defined by the boot strap process, but by each individual user that logs onto the system. /sbin/modprobe appldata_os /sbin/modprobe appldata_mem /sbin/modprobe appldata_net_sum /bin/echo 1 > /proc/sys/appldata/os /bin/echo 1 > /proc/sys/appldata/mem /bin/echo 1 > /proc/sys/appldata/net_sum /bin/echo 1 > /proc/sys/appldata/timer /bin/echo > /proc/sys/appldata/interval Save the file and the changes will be automatically applied each time the Linux guest is IPLed (re-booted) 35

43 15. Enable Dynamic Workspace Linking (DWL) on the Linux guest machines This step assumes that the Tivoli Monitoring Agent for Linux OS is installed and configured. In order to configure the ability to link from the OMEGAMON XE for z/vm and Linux monitoring agent workspaces to the Tivoli Monitoring Agent for Linux OS workspaces, you must add an environment variable to the Tivoli Monitoring Agent for Linux OS configuration file (lz.ini). This needs to be performed for every Linux system that needs to be monitored and it is assumed that the Tivoli Monitoring for Linux OS has already been installed and configured on those Linux systems. Log onto each Linux system machine as root or as the userid that owns the Tivoli resources and perform the following steps: Modify the lz.ini file Change to ITM_HOME which is the directory where the Linux agent was installed. cd <ITM_HOME>/config Edit the lz.ini file using an available editor such as the vi editor. vi lz.ini Add the following lines to the file using the editor s line commands by pressing the I (insert) key. KLZ_SETLPARVMID=Y KVL_USE_VMSYSID=Y If you are running ITM v620+, comment out the line containing the variable CTIRA_HOSTNAME Press the ESC key and exit the edit and save the file with the following command :wq Recycle the Tivoli Monitoring Agent for Linux OS Change to ITM_HOME which is the directory where the OMEGAMON XE for z/vm and Linux agent was installed, normally /opt/ibm/itm cd <ITM_HOME>/bin 36

44 Stop the agent./itmcmd agent stop lz Start the agent./itmcmd agent start lz 37

45 16. Installing the OMEGAMON Command Server on z/vm (Optional) Note : This step is optional only if you need to issue TAKE ACTION commands from within the TEP or as automated responses to a trigger alert/situation on the target z/vm system. If this is not required, e.g. during a POC, etc proceed to Step 6. Configure TCPIP on z/vm below. Installation of the OMEGAMON product uses the VMSES/E (equivalent of zos SMP/E) facility. In order to simplify the installation process VM mini-disks will be the target for the installation software rather than a Shared File System (SFS). The default virtual machines (userids) 5698A36D and OMEGACMD are used as the targets in this document rather than custom userids in order to reduce the work involved in creating a PPF override file. Actual commands that will be issued during the installation process(es) below are highlighted in blue Installation Pre-requisites While any userid can be used for the Installation Planning section, I would suggest using the 5698A36D userid to minimize the number of virtual machines (userids) utilized. To that end I have increased the required number of cylinders for 5698A36D s 191 minidisk to 5 CYLS. Certain default minidisks are added by default to most virtual machines (userids) within a z/vm environment in order to provide access to the system commands and help files. Each and each user should have read only LINK statements to MAINT s 190, 19D and 19E minidisks. With the assistance of the z/vm System programmer create the virtual machines (userids) indicated below in bold, either manually by editing the USER DIRECT file from the MAINT account or via a directory maintenance facility such as DIRMAINT. 5698A36D cyls 2A2 1 cyl 2B2 2 cyls 2C2 2 cyls 2D2 2 cyls 2A6 1 cyls cyls cyls OMEGACMD cyls include a MULTI password 38

46 All minidisks must be CMS formatted prior to use and this can done using the CPFMTXA command. The command processor userid must have the necessary privileges required for the Take Action commands that will be permitted. The following comprises a list of MAINT s minidisks used during the installation planning process. Write the passwords in the spaces provided, which can be obtained by reviewing the USER DIRECT file by issuing the following command from the MAINT user account. BROWSE USER DIRECT MAINT 190 RR System/Product executables MAINT 19D RR System/Product Help Files MAINT 19E RR System/Product executables MAINT 51D MR Software Inventory MAINT 5E5 RR VMSES/E Code As the installation process requires access to the above minidisks and it is recommended that you add access to the VM userid s directory entry via the LINK command for userid 5698A36D. LINK MAINT RR * CMS system disk LINK MAINT 019D 019D RR * help disk LINK MAINT 019E 019E RR * Product code disk LINK MAINT 051D 051D MR * VMSES/E software inventory disk LINK MAINT 05E5 05E5 RR * VMSES/E code And for userid OMEGACMD LINK MAINT RR * CMS system disk LINK MAINT 019D 019D RR * help disk LINK MAINT 019E 019E RR * Product code disk LINK 5698A36D RR * OMEGAMON product disk Enter the following command to exit the editor QUIT or FILE in order to save any changes Upload the product envelope file (if not using a tape unit) If you intend installing the product from an envelope file uploading the file as follows 39

47 FTP the file to z/vm by entering the following commands bin quote site fixrec 1024 put 5698A36D.PACKED quit On z/vm, Copy and unpack the envelope file COPYFILE 5698A36D PACKED A = SERVLINK A (UNPACK Continue the installation process as described in the Program Directory Installation Planning Ensure that you have obtained the necessary passwords for MAINT s minidisks, which you can do by reviewing the USER DIRECT file described above and the required virtual machines (userids) have been created. Logon to 5698A36D virtual machine Create a PROFILE EXEC for accessing MAINT s minidisks Enter the following command XEDIT PROFILE EXEC At command prompt, enter the following commands modifying the xxxxx with MAINT s multi-write password obtained in Section input /* */ input access 190 S input access 19E Y/S input access 19D Z input link MAINT 5E5 5E5 input access 5E5 B input link MAINT 51D 51D MR xxxxx input access 51D D file 40

48 Run the above PROFILE EXEC in order to access the minidisks PROFILE The STAT column should indicate that the minidisk is accessed in R/W mode. If not enter, have the user who has it linked as R/W to release it or access it as R/O and then re-enter the above command Verify that are linked to the user account by issuing the following command Verify that you have read access to MAINT s 190, 19D and 19E minidisks and write access to MAINT s 51D minidisk by issuing the following command: QUERY DISK Attach a tape device to 5698A36D Obtain the real device number for a locally attached tape unit (cartridge).this might require MAINT to perform this task if the userid has not been granted the necessary authority Enter the following command ATT if you have the authority on 5698A36D or ATT 589 to 5698A36D as 181 Attach rdev (589) to userid as 181 from the MAINT user account Load OMEGAMON product control files to MAINT s 51D minidisk Enter the following command VMFINS INSTALL INFO (NOMEMO The above command should return with the message(s) VMFINS276I VMFINS processing started VMFINS19 9I VMFINS PRODLIST created on your A-disk VMFINS276I VMFINS processing completed successfully Ready; 41

49 If the above command is not found or does not end successfully, verify that MAINT s 5E5 and 51D minidisks have been accessed with the correct permissions. This can be done via the QUERY DISK command. Obtain OMEGAMON resource planning information Enter the following command VMFINS INSTALL PPF 5698A36D {OMCMDPRC} (PLAN NOMEMO The above command will prompt you with the following response VMFINS2767I Reading VMFINS DEFAULTS B for additional options VMFINS276I VMFINS processing started VMFINS261R Do you want to create an override for :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC? Enter 0 (No), 1 (Yes) or 2 (Exit) Enter 0 and press Return The following message(s) should be returned VMFINS26 3I Processing product :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC VMFREQ19 9I 5698A36D PLANINFO created on your A-disk VMFREQ28 5I Product :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC has passed requisite checking VMFINT26 3I Planning for the installation of product :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC VMFRMT276 I VMFRMT processing started VMFRMT276 I VMFRMT processing completed successfully VMFINS276 I VMFINS processing completed successfully Review the install message log ($VMFINS $MSGLOG) by entering the following command: VMFVIEW INSTALL Review the message log file and correct any problems before continuing. 42

50 16.4. Installing OMEGAMON Command Processor The assumption is that user account has been correctly defined with access to MAINT s minidisks and that the installation will be performed from an attached tape system. Logon to 5698A36D virtual machine Install Command Processor The following assumes that a tape device is still attached or has been attached to current user as virtual device (vdev) 181. You can verify this by entering the following command QUERY TAPES ATTACHED * You may be prompted for additional information during the install process, please refer to the z/vm System Programmer. Enter the following command: VMFINS INSTALL PPF 5698A36D {OMCMDPRC} (NOMEMO NOLINK The NOLINK option indicates that you do not want to VMFINS to link to the appropriate minidisk but only access them if they are not currently accessed. The above command will prompt you with the following response VMFINS2767I Reading VMFINS DEFAULTS B for additional options VMFINS276I VMFINS processing started VMFINS261R Do you want to create an override for :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC? Enter 0 (No), 1 (Yes) or 2 (Exit) Enter 0 and press Return The following message(s) should be returned VMFINS26 3I Processing product :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC VMFREQ28 5I Product :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC has passed requisite checking VMFINT26 3I Installing product :PPF 5698A36D OMCMDPRC :PRODID 5698A36D%OMCMDPRC VMFSET276 I VMFSETUP processing started for 5698A36D OMCMDPRC VMFUTL22 5I Minidisk Directory Assignments: String Mode Stat Vdev Label/Directory ST:VMFUTL22 5I LOCALSAM E R/W 2C2 SAMPLE ST:VMFUTL22 5I APPLY F R/W 2A6 APPLY1 43

51 ST:VMFUTL22 5I G R/W 2A2 APPLY ST:VMFUTL22 5I DELTA H R/W 2D2 DELTA ST:VMFUTL22 5I BUILD I R/W 3 BUILD ST:VMFUTL22 5I BASE J R/W 2B2 BASE ST:VMFUTL22 5I A R/W 3BA NEI3BA ST:VMFUTL22 5I B R/O 5E5 MNT5E5 ST:VMFUTL22 5I D R/W 51D SESINV ST:VMFUTL22 5I S R/O 19 CMS22 ST:VMFUTL22 5I Y/S R/O 19E YDISK ST:VMFSET276 I VMFSETUP processing completed successfully ST:VMFREC276 I VMFREC processing started ST:VMFREC1852I Volume 1 of 1 of INS ENVELOPE 6 ST:VMFREC1851I (1 of 7) VMFRCAXL processing AXLIST ST:VMFRCX2159I Loading part(s) to DELTA 2D2 (H) ST:VMFREC1851I (2 of 7) VMFRCPTF processing PARTLIST ST:VMFRCP2159I Loading part(s) to DELTA 2D2 (H) ST:VMFREC1851I (3 of 7) VMFRCCOM processing DELTA ST:VMFRCC2159I Loading 1 part(s) to DELTA 2D2 (H) ST:VMFREC1851I (4 of 7) VMFRCALL processing APPLY ST:VMFRCA2159I Loading part(s) to APPLY 2A6 (F) ST:VMFRCA2159I Loaded 1 part(s) to APPLY 2A6 (F) ST:VMFREC1851I (5 of 7) VMFRCALL processing BASE ST:VMFRCA2159I Loading part(s) to BASE 2B2 (J) ST:VMFRCA2159I Loaded 7 part(s) to BASE 2B2 (J) ST:VMFREC1851I (6 of 7) VMFRCALL processing BUILD ST:VMFRCA2159I Loading part(s) to BUILD 3 (I) ST:VMFRCA2159I Loaded 1 part(s) to BUILD 3 (I) ST:VMFREC1851I (7 of 7) VMFRCALL processing SYSSAMP ST:VMFRCA2159I Loading part(s) to LOCALSAM 2C2 (E) ST:VMFRCA2159I Loaded 3 part(s) to LOCALSAM 2C2 (E) ST:VMFREC276 I VMFREC processing completed successfully ST:VMFINT26 3I Product installed VMFINS276 I VMFINS processing completed successfully Review the install message log ($VMFINS $MSGLOG) by entering the following command: VMFVIEW INSTALL Review the message log file and correct any problems before continuing. Update the Build Status Table for OMEGAMON Enter the following command: 44

52 VMFINS BUILDPPF 5698A36D {OMCMDPRC} (SERVICED NOLINK Review the message log file and correct any problems before continuing Copy OMEGAMON files into Production The assumption is that you are still logged onto the 5698A36D user account and that it access to MAINT s minidisks. Access the production minidisks Enter the following commands on separate lines pressing the Enter key after each command ACCESS 300 E ACCESS 301 F Update the VMSES/E PARTCAT file Enter the following command onto a single line and press Enter. VMFCOPY * * E = = F2 (PRODID 5698A36D%OMCMDPRC OLDDATE REPLACE The above command copies the files from the E minidisk to the F minidisk, replacing any existing files while retaining their original date/time stamp. Copy local sample files to the OMEGACMD A (191) minidisk ` Enter the following commands on separate lines pressing the Enter key after each command. ACCESS 2C2 E LINK OMEGACMD W ACCESS 291 F VMFCOPY * * E = = F (PRODID 5698A36D%OMCMDPRC OLDDATE REPLACE The above command copies the files from the E minidisk to the F minidisk, replacing any existing files while retaining their original date/time stamp. 45

53 The VMFCOPY command will update the VMSES PARTCAT file on the OMEGACMD A- disk. If the link command fails, it is most likely because the OMEGACMD virtual machine is logged on. In order to complete this step the OMEGACMD virtual machine must be logged off, or have its 191 disk detached. The Tivoli OMEGAMON XE on z/vm and Linux Command Server component is now installed and built on your system Take Action Commands (Optional) The command processor consists a configuration file called KVL CONFIG can be modified to include a list of the allowed user IDs that are allowed to perform Take Action commands. The following parameters are required. Other parameters are AGENT_ID = LINUXUID A list of the z/vm user IDs of the Linux guest where the monitoring agent is running. CMDS=LOGOFF includes a list of the commands that are not allowed The output from the commands can be logged to a file LOG_SIZE=<number of lines> The log size range is lines. The default number of lines is 5000 lines LOG_COUNT=<number> the log cycles through as many times as you specify in this setting. e.g KVL 1, KVL 2, and so on. A maximum of five active log files is retained. LOG_RESP=Y or N specify whether or not the results of the processed commands are written to the log file. The default is N Important: Turning results logging on will result in significantly larger log files. Modify the settings to meet the needs of your environment. The log file generated is called KVL <number>, where number is the number of times the log file has been generated. 46

54 17. Appendix A - Problem Determination 1. z/vm #CP MONITOR SAMPLE ENABLE PROCESSOR command fails. The above command fails with the following message CP6263I : CPU-Measurement Facility counter collection was not enabled because the basic counter set is not authorized. Problem Not being able to enable the CP MMONITOR SAMPLE ENABLE Processor prevents processor information from being collected and displayed in the applicable Tivoli Enterprise Portal workspace. Cause CPU-Measurement Counter Facility counters are not collected. Collection of other monitor data is unaffected. The system determined that the basic counter set in the CPU-Measurement Counter Facility has not been authorized. If you enable collection of monitor sample records in the PROCESSOR domain (MONITOR SAMPLE ENABLE PROCESSOR command), the system makes no attempt to activate or to collect CPU-Measurement Counter Facility counters. User Response To authorize the basic counter set, perform authorization in the LPAR activation profile or through the Change LPAR Security task on the Support Element. See image below 47

55 The screen above is accessed from the HMC console: Configuring the Server to collect CPU Measurement Facility Data If all the required settings are checked, proceed to activate the image. Otherwise, when the user attempts to start HIS Data Collection, the user will encounter an error message such as this one: HIS026I MODIFY HIS COMMAND CANNOT BE PROCESSED. BASIC COUNTER SET IS UNAUTHORIZED. Note In order to collect CPU Measurement Facility Data on a z10 server, Driver D76D Bundle #11 or higher is required. In the activation profile for the user s LPAR, access the security tab and verify that ALL of the following settings are checked. 48