Home About BC DR HA Support Training Download
You are here: Home/ GlobalSysAdmin/ Power5/ Please Login or Register

-
Current Location
-

js
  GlobalSysAdmin
    Power5
-
AIX Admin Methodology
Global Consolidation Project
All AIX admins should join
www.aixexpert.com

Join our LinkedIn Group
AIX Advanced Technical Experts
Contract Opportunities
www.LinkedIn.com
-
digg Digg this page
del.icio.us Post to del.icio.us
Slashdot Slashdot it!

LPAR Leasing
Lease an AIX / i5 LPAR
Reduce your costs
www.mtxia.com

Server Leasing
Lease a Server off-site
Reduce your costs
www.mtxia.com

Data Center Automation
Business Continuity and DR
Virtualization/Consolidation
www.mtxia.com

HMC Service
Hardware Management Console
Manage Remote AIX / i5 LPARs
www.siteox.com

Business Web Site Hosting
$3.99 / month includes Tools,
Shopping Cart, Site Builder
www.siteox.com

Disaster Recovery
Small Business Oriented
Off-Site Facilities
www.mtxia.com

IBM pSeries / iSeries
Reduce your Costs
Off-Site Server Hosting
www.mtxia.com

Table of Contents

  1. Documentation

    1. Policies

      1. Frames

      2. MicroCode

      3. Storage

      4. Hostname/Alias

      5. HMC

      6. VIO Server

      7. PLM

      8. LPAR

      9. NIM

      10. Resource Group

      11. WLM AIX 433

      12. WLM AIX 5

      13. VG Name

      14. LV Name

      15. JFS Logs

      16. FS Mt Point

      17. User/UID

      18. Group/GID

      19. Security

      20. HACMP

      21. Installation

      22. Monitoring

      23. Patch Management

    2. Guidelines

      1. Frames

      2. MicroCode

      3. Storage

      4. Hostname/Alias

      5. HMC

      6. VIO Server

      7. PLM

      8. LPAR

      9. NIM

      10. Resource Group

      11. WLM AIX 433

      12. WLM AIX 5

      13. VG Name

      14. LV Name

      15. JFS Logs

      16. FS Mt Point

      17. User/UID

      18. Group/GID

      19. Security

      20. HACMP

      21. Installation

      22. Monitoring

      23. Patch Management

    3. Standards

      1. Frames

      2. MicroCode

      3. Storage

      4. Hostname/Alias

      5. HMC

        1. Config VEthnet

        2. Config VSCSI

      6. VIO Server

        1. VIO VLAN ID

        2. VIO SCSI ID

      7. PLM

      8. LPAR

      9. NIM

      10. Resource Group

      11. WLM AIX 433

      12. WLM AIX 5

      13. VG Name

      14. LV Name

      15. JFS Logs

      16. FS Mt Point

      17. User/UID

      18. Group/GID

      19. Security (DRAFT)

      20. HACMP

      21. Installation

      22. Monitoring

      23. Patch Management

    4. Procedures

      1. Frames

      2. Microcode

      3. Storage

      4. Hostname/Alias

      5. HMC

        1. Virtual Processor Size

      6. VIO Server

        1. VIO WLM Enable

        2. VIO HDLM Parms

      7. PLM

        1. PLM Config

      8. LPAR

        1. VIO Procedures

        2. VIO VLAN ID

        3. VIO SCSI ID

      9. NIM

      10. Resource Group

      11. WLM AIX 433

      12. WLM AIX 5

      13. VG Name

      14. LV Name

      15. JFS Logs

      16. FS Mt Point

      17. User/UID

      18. Group/GID

      19. Security

      20. HACMP

      21. Installation

      22. Monitoring

        1. VIO WLM Enable

        2. WLM AIX 433

        3. WLM AIX 5

      23. Patch Management

Documentation

Consolidated view of policies, guidelines, standards and procedures

The documentation referenced here describes the policies, guidelines, standards and procedures for insuring business continuity for the business function supported using IBM's Power 5 architecture. This architecture supports the ability to provide capacity on-demand and virtual I/O. The ability to micro-partition using pieces of a processor and dynamically allocate and deallocate memory is supported in this environment as well.

The Power 5 architecture provides the ability to define LPAR's and Virtual LPAR's. The difference between an LPAR and a Virtual LPAR is the implementation of the virtualization features. The Power 5 architecture allows the sytem administrator to configure logical partitions with dedicated resources such as processors, memory, and I/O adapters. The system administrator may also configure logical partitions utilizing shared processors, memory, and virtualized I/O adapters. The virtual I/O adapters are configured and made available to the LPAR's via the VIO server. The VIO server provides the ability to reduce the number of adapters required to support multiple LPAR's by virtualizing the hardware and allowing multiple LPAR's to share the same hardware I/O adapters.

Additional documents of interest

  • Migration from Power4 to Power5 using alt-disk-install
    This procedure is used to migrate from the existing IBM Power4 architecture running the EGATE Pre-Production environment on 6M2 machines, to the new IBM Power5 architecture running on the p590 machines. This procedure is required because EGATE requires AIX 5.2 and will not run on AIX 5.3. The lowest version of AIX that will run on the p590 Power5 architecture is AIX 5200-05 and EGATE is currently running on AIX 5200-02.

  • Calculating the size of a Virtual Processor
    This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation does not fully describe how the size of a virtual processor is determined, this document clarifies this process. A description of the HMC input fields for the processor tab is included.

  • p590 Frame 9119-590-51A971E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • p590 Frame 9119-590-51A972E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • p590 Frame 9119-590-51A973E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • p590 Frame 9119-590-51A974E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • Network information for all p590 Frames
    This spreadsheet contains all network configuration information for all LPAR's configured in all p590 frames.

  • Basics of Partition Load Manager Setup
    This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup on Friday May 13, 2005. Ron's email address is rfbarker@us.ibm.com and his phone number is: 817.962.5199.
  • ppt
  • pdf

    • Table of Contents

    Documentation

    Consolidated view of policies, guidelines, standards and procedures

    The documentation referenced here describes the policies, guidelines, standards and procedures for insuring business continuity for the business function supported using IBM's Power 5 architecture. This architecture supports the ability to provide capacity on-demand and virtual I/O. The ability to micro-partition using pieces of a processor and dynamically allocate and deallocate memory is supported in this environment as well.

    The Power 5 architecture provides the ability to define LPAR's and Virtual LPAR's. The difference between an LPAR and a Virtual LPAR is the implementation of the virtualization features. The Power 5 architecture allows the sytem administrator to configure logical partitions with dedicated resources such as processors, memory, and I/O adapters. The system administrator may also configure logical partitions utilizing shared processors, memory, and virtualized I/O adapters. The virtual I/O adapters are configured and made available to the LPAR's via the VIO server. The VIO server provides the ability to reduce the number of adapters required to support multiple LPAR's by virtualizing the hardware and allowing multiple LPAR's to share the same hardware I/O adapters.

    Additional documents of interest

  • Migration from Power4 to Power5 using alt-disk-install
    This procedure is used to migrate from the existing IBM Power4 architecture running the EGATE Pre-Production environment on 6M2 machines, to the new IBM Power5 architecture running on the p590 machines. This procedure is required because EGATE requires AIX 5.2 and will not run on AIX 5.3. The lowest version of AIX that will run on the p590 Power5 architecture is AIX 5200-05 and EGATE is currently running on AIX 5200-02.

  • Calculating the size of a Virtual Processor
    This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation does not fully describe how the size of a virtual processor is determined, this document clarifies this process. A description of the HMC input fields for the processor tab is included.

  • p590 Frame 9119-590-51A971E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • p590 Frame 9119-590-51A972E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • p590 Frame 9119-590-51A973E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • p590 Frame 9119-590-51A974E
    This spreadsheet contains configuration information for all LPAR's configured on this frame, including network and cabling.

  • Network information for all p590 Frames
    This spreadsheet contains all network configuration information for all LPAR's configured in all p590 frames.

  • Basics of Partition Load Manager Setup
    This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup on Friday May 13, 2005. Ron's email address is rfbarker@us.ibm.com and his phone number is: 817.962.5199.
  • ppt
  • pdf

    • Table of Contents

    Policies

    Policies

    • The policies described here are specific to the Power 5 LPAR environment.
    • Standards defined here will apply to LPAR's and Virtual LPAR's.
    • Each entity defined in this environment will be configured with an enterprise wide unique identifier so that it may be moved or reconfigured anywhere in the environment.
    • The Network Information Manager (NIM) is utilized for providing access to all operating system components.
    • The configuration and implementation of all components comprising each LPAR is documented with both hard and soft copies of the documentation.

    Table of Contents

    Frames

    Frame Policies

    • All frames will be configured with redundant architecture for high availability. This includes power, network, and storage attachment.
    • Frame Maintenance windows (outages) will be scheduled quarterly at a minimum.
    • Each new Frame shall be entered into the Configuration Management Database (CMDB) upon installation.

    Table of Contents

    MicroCode

    Microcode Policies

    • The microcode for all system components will be checked for newer revisions monthly and implemented quarterly. If revisions are available, they will be considered for implementation during the next available outage for a system. Recommendations for microcode implementation will be recorded in the system log.
    • IBM systems with release dates less than one year shall implement microcode as soon as possible after release.
    • IBM systems with release dates greater than one year shall implement microcode no newer than three months.

    Table of Contents

    Storage

    Storage Policies

    • All disk storage shall be external to the system, including bootable volumes.
    • Only the operating system shall be stored in the "rootvg" volume group. All data and applications shall be stored separately from the "rootvg".
    • No striping, RAID, mirroring, etc shall be performed by the operating system. All storage management shall be performed by the external disk storage subsystem.
    • All disk storage will be accessible through redundant paths.
    • All Tier 1 applications shall be on core switches as opposed to edge switches.

    Table of Contents

    Hostname/Alias

    Hostname Policies

    • Hostnames shall be enterprise wide unique identifiers.

    Table of Contents

    HMC

    HMC Policies

    • Each frame introduced into the MtXia environment shall be managed by a Hardware Management Console (HMC).
    • Where a single HMC manages one or more systems for multiple customers, redundant HMC's will be implemented.

    Table of Contents

    VIO Server

    Virtual I/O Server Policies

    • Redundant VIO servers shall be configured for each frame introduced into MtXia's environment. Each VIO server shall be configured with 50% of the frame's resources.

    Table of Contents

    PLM

    Partition Load Manager Policies

    • CPU and memory resources for all application LPAR's will be managed by a Partition Load Manager (PLM).
    • At least one PLM shall be operational in each data center, with a policy file for each frame managed by the PLM.

    Table of Contents

    LPAR

    Logical Partition Policies

    • Shared CPU and memory resources shall be configured for all new LPAR's.
    • Virtual SCSI and Ethernet adapters shall be configured for all non-production LPAR's. Virtualization of production LPAR's is dependent upon SLA tier and expected applicaiton load.
    • Initial minimum values shall be used for configuration of CPU and memory, adjustments will be controlled by the Partition Load Manager (PLM).
    • Each LPAR will be accessible through two networks, application and management.
    • Each LPAR will be accessible through the MtXia Administration network.

    Table of Contents

    NIM

    Network Installation Manager Policies

    • At least one Network Installation Manager (NIM) Server shall be maintained in each data center.
    • All AIX and application installation processes shall be managed by the NIM server.
    • NIM servers shall be synchronized between data centers.
    • NIM servers shall always be maintained at the latest OS level to ensure functionality with all managed systems.
    • NIM servers shall have communication with all networks within a data center.

    Table of Contents

    Resource Group

    Resource Group Name Policies

    • All system resources will be divided into logical resource groups, each resource group shall have an enterprise wide unique name. The resource group name shall be the basis of numerous naming structures and policies.
    • Resource groups will be defined for standalone and high availability systems. All systems will be designed as though they participate in a high availability environment, regardless of whether or not they actually do. This does not mean that all systems will have HACMP or other automated high availability software installed.
    • A centralized repository shall contain a list of all configured resource groups enterprise wide. New resource groups shall be entered into this repository.

    Table of Contents

    WLM AIX 433

    Workload Manager for AIX 4.3.3.0 Policies

    • Workload Manager shall be implemented in passive mode only.

    Table of Contents

    WLM AIX 5

    Workload Manager for AIX 5L Policies

    • Workload Manager shall be implemented in passive mode only.

    Table of Contents

    VG Name

    Volume Group Name Policies

    • All data and applications will be stored separately from the "rootvg" volume group. Additional volume groups will be configured as necessary.
    • Volume group names shall be enterprise wide unique values based on the resource group name.

    Table of Contents

    LV Name

    Logical Volume Name Policies

    • Each logical volume shall have an enterprise wide unique name for the purpose of eliminating naming conflicts during manual, HACMP, or Disaster Recovery failovers.

    Table of Contents

    JFS Logs

    JFS Log Logical Volume Name Policies

    • Each volume group that contains file systems will require at least one JFS log. The name of the JFS Log shall be an enterprise wide unique value.

    Table of Contents

    FS Mt Point

    File System Mount Point Directory Name Policies

    • Every application filesystem shall have an enterprise wide unique mount point directory. The purpose is to eliminate conflicts during manual, HACMP, disaster recovery, or consolidation failovers.

    Table of Contents

    User/UID

    User Name Policies

    • All individual users will have an enterprise wide unique user names.
    • Administration user names may be dictated by application requirements.
    • The UID number associated with each user name shall be an enterprise wide unique identifier.
    • LDAP shall be implemented as a centralized User/UID management system.

    Table of Contents

    Group/GID

    Group Name Policies

    • Group names may be dictated by application requirements. The GID number associated with each group name shall be an enterprise wide unique identifier.
    • LDAP shall be implemented as a centralized Group/GID management system.

    Table of Contents

    Security

    Security Policies

    • Each user shall be assigned an enterprise wide unique name.
    • Each user shall be assigned an enterprise wide unique UID number.
    • Each group shall be assigned an enterprise wide unique GID number.
    • MtXia Corporate security policy shall be observed and adhered to. This policy can be reviewed by contacting the MtXia security officer.
    • Internal security audits shall minimally be performed quarterly on all Unix Systems.
    • Administration passwords shall be changed according to MtXia's security standards.

    Table of Contents

    HACMP

    HACMP Policies

    • HACMP shall be implemented across frames in the p590 environment for high availability, maintenance, and redundancy.

    Table of Contents

    Installation

    Installation Policies

    • All installations of operating system or application components shall be performed using the Network Installation Manager (NIM).
    • All operating system or application components must be capable of remote installation without the use of original media.
    • Application installation requiring Administrator level access will be performed by system engineers.
    • All Operating Systems, Databases, and/or Applications shall be at a supported level by the vendor. A support contract must be active before implementation of any hardware, operating system, application or daatabase. The support contract must be maintained for the duration of the services provided by MtXia.
    • Current valid licenses shall be obtained and maintained for all software.
    • Each new LPAR shall be entered into the Configuration Management Database (CMDB) upon installation.

    Table of Contents

    Monitoring

    Monitoring Policies

    • Each system shall be monitored by Tivoli TEC.
    • All systems will be monitored for Up/Down status.
    • All hardware shall be monitored for failures.
    • All filesystems will be monitored for full conditions.
    • Any custom monitors outside of Tivoli TEC should integrate their information into Tivoli TEC's alerting mechanism.
    • Automated documentation describing a systems configuration and status will be generated and stored on "eperf".

    Table of Contents

    Patch Management

    Patch Management Policies

    • Microcode, AIX, and application updates will be analyzed quarterly and updates will be scheduled. Outages will be required and must be factored into the SLA's.

    Table of Contents

    Guidelines

    Table of Contents

    Frames

    Frame Guidelines

    Table of Contents

    MicroCode

    Microcode Guidelines

    • Even though it is policy that monthly checks be performed for microcode updates, that does not necessarily mean that microcode must be updated on a monthly basis. If after examining the microcode documentation, it is determined the revised microcode does not fix or enhance any significant features, then a recommendation may be made by the system engineer NOT to update the microcode.
    • Just because a microcode update is available, does not mean it must be implemented.
    • Inventory Scout should be used to perform the microcode analysis on a monthly basis whether performed via HMC or local to host.

    Table of Contents

    Storage

    Storage Guidelines

    • External boot is for systems running AIX 5.2+

    Table of Contents

    Hostname/Alias

    Hostname Guidelines

    • Users should NOT access application services via the hostname identifier. All access to application services should be provided through the use of aliases.

    Table of Contents

    HMC

    HMC Guidelines

    Table of Contents

    VIO Server

    Virtual I/O Server Guidelines

    • Resources dedicated to an LPAR may be excluded from the VIO Server.
    • WLM will be used to monitor/manage the VIO resources.

    Table of Contents

    PLM

    Partition Load Manager Guidelines

    • The Partition Load Manager (PLM) Server should be a standalone machine dedicated for this purpose.
    • A secondary PLM should be implemented for each data center and contain the policy files from the primary PLM, ready to be activated.

    Table of Contents

    LPAR

    Logical Partition Guidelines

    • CPU and Memory values may be augmented after installation based on software requirements.
    • I/O Adapters in production environments may be dedicated to an LPAR based on bandwidth requirements.

    Table of Contents

    NIM

    Network Information Manager Guidelines

    • Alternate NIM master servers may be configured in each data center, but are not required.

    Table of Contents

    Resource Group

    Resource Group Name Guidelines

    • Each system will host one or more resource groups.
    • There should be a unique DNS entry based on each resource group name. These names may or may not have unique associated IP addresses.

    Table of Contents

    WLM AIX 433

    Workload Manager for AIX 4.3.3.0 Guidelines

    Table of Contents

    WLM AIX 5

    Workload Manager for AIX 5L Guidelines

    Table of Contents

    VG Name

    Volume Group Name Guidelines

    • Where possible, create volume groups with a unique major number.

    Table of Contents

    LV Name

    Logical Volume Name Guidelines

    • The logical volume name should be based on the resource group name.

    Table of Contents

    JFS Logs

    JFS Log Logical Volume Name Guidelines

    • More than one JFS log may be configured for a volume group if necessary, dependent upon filesystem load.

    Table of Contents

    FS Mt Point

    File System Mount Point Directory Name Guidelines

    • In order to ensure successful installation of an application into unique mount points, the application team must work closely with the system engineer.

    Table of Contents

    User/UID

    User Name Guidelines

    • Administrators usually have a user name structure different than normal users, so they are easily identifiable.

    Table of Contents

    Group/GID

    Group Name Guidelines

    Table of Contents

    Security

    Security Guidelines

    • Where possible all users should be managed by LDAP.
    • Each client or business unit should have independent organizational units within LDAP.

    Table of Contents

    HACMP

    HACMP Guidelines

    Table of Contents

    Installation

    Installation Guidelines

    • New installations should be updated to the latest level.
    • Multiple installation should be performed via mksysb from the NIM server.
    • The 64 bit AIX OS should be installed wherever possible.

    Table of Contents

    Monitoring

    Monitoring Guidelines

    • Application monitoring will be provided by application teams to Tivoli TEC.
    • Filesystem monitors (other than root filesystems) will be based on applicaiton requirements.

    Table of Contents

    Patch Management

    Patch Management Guidelines

    • Microcode, AIX, and application updates will be evaluated for installation, but updates are not necessary required.
    • As a minimum, the system should be rebooted on a quarterly basis.

    Table of Contents

    Standards

    This document references the standards implemented by MtXia to ensure business continuity for all business functions implemented on the AIX Power 5 architecture. Many of these standards are not specific to the Power5 architecture but are intended as enterprise wide standards for all AIX systems.

    These standards have been developed over many years of supporting standalone, high availability, and disaster recovery environments. The purpose of these standards is to ensure business continuity during normal system maintenance, planned and unplanned outages, hardware and software failures, network and communication failures, and/or a disaster recovery implementation.

    A design aspect of these standards is they can be implemented in a standalone, high availability, or disaster recovery scenario. Recognize that there are not multiple standards, one for each scenario, there is one single standard that is portable across all scenario's. This reduces support and training costs, and increases efficiency, supportability, recoverability, and availability.

    Some of the basic concepts of these standards:

    • Business functions are not tied to a specific machine.
    • Hardware resources can be shared or distributed among associated business functions.
    • Any system can act as a failover for any other system.
    • Any data center can act as a disaster recovery site for any other data center.

    Table of Contents

    Frames

    Frame Standards

    A Frame is the Entire system that houses LPARS. A P590 is a frame as well as a 6M2. Frame Names will consist of the Model and Serial number: - e.g. p590-51A971E

    Table of Contents

    MicroCode

    Microcode Management

    Systems without an HMC

    Use IBM's Microcode Discovery Service at the following URL to determine what microcode should be updated, to retrieve the microcode, and the instructions for installing the microcode.

    https://techsupport.services.ibm.com/server/aix.invscoutMDS

    Normally the "java applet" is used to peform the microcode discovery which requires the password for the user "invscout" to be set. This also requires internet communication from the system over port 808. To use the java applet perform the following steps on the target system:

    1. Set the password for the user "invscout"

      2. passwd invscout

    2. Clear the password administration flags on the user "invscout" 

      pwdadm -c invscout

    3. Start the "invscout" daemon 

      invscoutd

    4. The system is now ready for microcode discovery via the java applet
    5. The microcode discovery service will require several pieces of information to be able to perform the survey:

      • Fully qualified hostname of the system
      • Password for the user "invscout"
      • Port number (default: 808)
      • System Model Number 

        lsattr -El sys0 -a modelname -F value

      • System Serial Number 

        lsattr -El sys0 -a systemid -F value

    Systems with an HMC

    Use the facilities built into the HMC for performing microcode updates to all managed systems.

    Table of Contents

    Storage

    Storage Standards

    All operating system, application, and data storage in the MtXia environment shall be configured external to the system. The purpose of this is to increase the recoverability of the system, reduce hardware related outages, and to centralize the management of storage.

    All systems will have multiple hardware paths to the storage, those paths may be physical or virtual.

    Multiple volume groups shall be created in the AIX environment. The operating system volume group, called "rootvg", will contain only operating system related applications and files. The "rootvg" will contain a minimum amount of storage.

    The standard "rootvg" will contain a single 9 GB disk that exists on the SAN and is mirrored by the SAN environment. Multiple paths to the "rootvg" disk are configured using IBM's Multi-Path I/O (MPIO) device driver. Optionally, the "rootvg" may have an "alt_disk" that exists on internal storage. The "alt_disk" is used to perform Operating System updates.

    All non-operating system related programs and data will be stored in volume groups other than "rootvg". The Volume group names will be created in accordance with MtXia's VG naming standards and will contain storage as required by the supported business function.

    All non-rootvg volume groups residing on Hitachi SAN based storage will utilize the latest HDLM driver and multiple hardware paths to the SAN. The HDLM driver is updated on a regular basis.

    Further information regarding MtXia's storage standards can be obtained from the following document: Unix-Storage-Presentation.pdf

    Table of Contents

    Hostname/Alias

    Hostname Standards

    In order to achieve maximum flexibility during normal operations, maintenance, disaster recovery, and business continuity efforts, it is important to provide a naming standard for business functions that can be translated easily into hostnames and/or aliases. The purpose of using hostnames instead of IP addresses is that they are easier to remember and use. Hostnames are not necessary, but usually desirable.

    Normal user access to an application or business function will always be through an alias. Normal users should never access a system using a hostname. The reason is for portability and availability. It is easy to redirect an alias to any host, it is significantly more difficult to change hostnames. By having the users access required services through aliases rather than hostnames, the users can be redirected quickly to available services in the event of a failure.

    Hostnames

    In MtXia's environment, a hostname refers to an IP address, the IP address is associated with one or more network adapters. It is important to recognize that an IP address is not necessarily tied to a network adapter, but may float across adapters and machines. The same is true with the hostnames. A hostname should be viewed as being independent from any machine or data center. The hostname shall be an enterprise wide unique value in order to eliminate conflicts during manual, automated, or disaster recovery failovers.

    The hostname shall consist of exactly 10 characters with the following structure:

    LocationCode + OS Type + Environment + ApplicationCode + SequenceID
   3 char    + 1 char  +    1 char   +      3 char     +   2 char   =  10 char

    The detailed information for each component of the resource group name is described below:

    HostName
    Component     		Number of
    Characters     		Values
    Location Code 3 
    mx1 = Dallas Data Center
mx0 = Mesquite Data Center
    OS Type 1 
    a = AIX
s = Sun
    Environment 1 
    a = acceptance
a = pre-production
d = test/development
p = production
t = test
x = disaster recovery
x = pre-production
    Application Code 3 
    atl = Atlas
ega = EGATE
nim = NIM
ora = Oracle
tps = Maximo
vio = Virtual I/O
    Sequence ID 2 
    0-9,A-Z,a-z

    Examples of Hostnames (HN):

  • mx1apega01
    EGATE Production database on AIX at Dallas Data Center, first instance

  • mx1apega01
    EGATE Production database on AIX at Dallas Data Center, second instance

  • mx0apnim01
    Production Network Information Manager on AIX at Mesquite Data Center, first instance

  • mx1apnim01
    Production Network Information Manager on AIX at Dallas Data Center, first instance

  • mx0apvio01
    Production Virtual I/O Server on AIX at Mesquite Data Center, first instance

  • mx0apvio02
    Production Virtual I/O Server on AIX at Mesquite Data Center, second instance

  • mx0apvio03
    Production Virtual I/O Server on AIX at Mesquite Data Center, third instance

  • mx0apvio04
    Production Virtual I/O Server on AIX at Mesquite Data Center, fourth instance

  • mx1aavio01
    Acceptance Virtual I/O Server on AIX at Dallas Data Center, first instance

  • mx1aavio02
    Acceptance Virtual I/O Server on AIX at Dallas Data Center, second instance

  • mx1aavio03
    Acceptance Virtual I/O Server on AIX at Dallas Data Center, third instance

  • mx1aavio04
    Acceptance Virtual I/O Server on AIX at Dallas Data Center, fourth instance

    • Aliases

    The rules for defining alias names are significantly less rigid than for hostnames. The alias can be any name as long as it is unique within the domain. This allows the application to be accessed though a name that makes logical sense to the user. For example, the production EGATE Application Server at the Dallas Data Center may have a hostname of "mx0apega03", however the alias may be "mx0egate". The use of aliases preserves the structure needed for hostnames and the ease of use desired by users.

    Table of Contents

    HMC

    HMC Standards

    Contained here are the standards for defining new LPAR's in the Power5 architecture environment using the Hardware Management Console. These standards describe the information required to define the LPAR's and the format in which this information should be presented.

    This environment utilizes the VIO server to virtualize the hardware I/O adapters to client LPAR's, thus allowing multiple LPAR's to share resources. Implementation of this type of environment requires extensive up-front design work and planning. Each hardware adapter must be identified to the VIO server and virtualized for use by each client LPAR.

    To begin configuring this environment, build a spreadsheet to contain all frame and I/O adapter information, this spreadsheet should contain at least the following:

    Frame Type:                                 
    Frame S/N:                                 
    System Name:                                 
    CPUs                                 
    RAM (GB)                                 
    CUoD CPUs                                 
    CUoD RAM (GB)                                 

    Drawer Serial Bus Slot Adapter LPAR
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                
                                                                                                                                

    Much of this information can be automatically generated using the script "hmcparse.ksh". Example results from this script follow:

    Server9119590SN51A972E

    Drawer Serial Bus Slot Adapter LPAR
    U5791.001.91800WT-P1 13 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 13 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WT-P1 13 C09 Empty slot  
    U5791.001.91800WT-P1 13 C10 Empty slot  
    U5791.001.91800WT-P1 14 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 15 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 15 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 15 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P1 15 C07 Empty slot  
    U5791.001.91800WT-P2 19 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 19 C08 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 19 C09 Empty slot  
    U5791.001.91800WT-P2 19 C10 Other Communications Device  
    U5791.001.91800WT-P2 20 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 21 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 21 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 21 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 21 C07 Empty slot  
    U5791.001.91800WW-P1 10 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 10 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WW-P1 10 C09 Empty slot  
    U5791.001.91800WW-P1 10 C10 Storage controller mx1apvio01
    U5791.001.91800WW-P1 11 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 12 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 12 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 12 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P1 12 C07 Empty slot  
    U5791.001.91800WW-P2 16 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 16 C08 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 16 C09 Empty slot  
    U5791.001.91800WW-P2 16 C10 Other Communications Device  
    U5791.001.91800WW-P2 17 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 18 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 18 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 18 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 18 C07 Empty slot  
    U5791.001.91800WT-P1 13 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 13 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WT-P1 13 C09 Empty slot  
    U5791.001.91800WT-P1 13 C10 Empty slot  
    U5791.001.91800WT-P1 14 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 15 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 15 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 15 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P1 15 C07 Empty slot  
    U5791.001.91800WT-P2 19 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 19 C08 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 19 C09 Empty slot  
    U5791.001.91800WT-P2 19 C10 Other Communications Device  
    U5791.001.91800WT-P2 20 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 21 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 21 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 21 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 21 C07 Empty slot  
    U5791.001.91800WW-P1 10 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 10 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WW-P1 10 C09 Empty slot  
    U5791.001.91800WW-P1 10 C10 Storage controller mx1apvio01
    U5791.001.91800WW-P1 11 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 12 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 12 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 12 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P1 12 C07 Empty slot  
    U5791.001.91800WW-P2 16 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 16 C08 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 16 C09 Empty slot  
    U5791.001.91800WW-P2 16 C10 Other Communications Device  
    U5791.001.91800WW-P2 17 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 18 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 18 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 18 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 18 C07 Empty slot  

    Server9119590SN51A973E

    Drawer Serial Bus Slot Adapter LPAR
    U5791.001.91800WR-P1 13 T6 SCSI bus controller mx1apvio04
    U5791.001.91800WR-P1 13 C08 Fibre Channel Serial Bus mx1pocdb02
    U5791.001.91800WR-P1 13 C09 Empty slot  
    U5791.001.91800WR-P1 13 C10 Empty slot  
    U5791.001.91800WR-P1 14 C01 PCI 1Gbps Ethernet mx1apvio04
    U5791.001.91800WR-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WR-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WR-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WR-P1 15 T5 SCSI bus controller mx1apvio04
    U5791.001.91800WR-P1 15 C05 PCI 1Gbps Ethernet mx1apvio04
    U5791.001.91800WR-P1 15 C06 Fibre Channel Serial Bus mx1apvio04
    U5791.001.91800WR-P1 15 C07 Empty slot  
    U5791.001.91800WR-P2 19 T6 SCSI bus controller mx1apvio04
    U5791.001.91800WR-P2 19 C08 Fibre Channel Serial Bus mx1apvio04
    U5791.001.91800WR-P2 19 C09 Empty slot  
    U5791.001.91800WR-P2 19 C10 Other Communications Device  
    U5791.001.91800WR-P2 20 C01 PCI 1Gbps Ethernet mx1apvio04
    U5791.001.91800WR-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WR-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio04
    U5791.001.91800WR-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio04
    U5791.001.91800WR-P2 21 T5 SCSI bus controller mx1apvio04
    U5791.001.91800WR-P2 21 C05 PCI 1Gbps Ethernet mx1apvio04
    U5791.001.91800WR-P2 21 C06 Fibre Channel Serial Bus mx1apvio04
    U5791.001.91800WR-P2 21 C07 Empty slot  
    U5791.001.91800WY-P1 10 T6 SCSI bus controller mx1apvio03
    U5791.001.91800WY-P1 10 C08 Fibre Channel Serial Bus mx1pocdb02
    U5791.001.91800WY-P1 10 C09 Empty slot  
    U5791.001.91800WY-P1 10 C10 Storage controller mx1apvio03
    U5791.001.91800WY-P1 11 C01 PCI 1Gbps Ethernet mx1apvio03
    U5791.001.91800WY-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio04
    U5791.001.91800WY-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio03
    U5791.001.91800WY-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio04
    U5791.001.91800WY-P1 12 T5 SCSI bus controller mx1apvio03
    U5791.001.91800WY-P1 12 C05 PCI 1Gbps Ethernet mx1apvio03
    U5791.001.91800WY-P1 12 C06 Fibre Channel Serial Bus mx1apvio03
    U5791.001.91800WY-P1 12 C07 Empty slot  
    U5791.001.91800WY-P2 16 T6 SCSI bus controller mx1apvio03
    U5791.001.91800WY-P2 16 C08 Fibre Channel Serial Bus mx1apvio03
    U5791.001.91800WY-P2 16 C09 Empty slot  
    U5791.001.91800WY-P2 16 C10 Other Communications Device  
    U5791.001.91800WY-P2 17 C01 PCI 1Gbps Ethernet mx1apvio03
    U5791.001.91800WY-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio03
    U5791.001.91800WY-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio03
    U5791.001.91800WY-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio03
    U5791.001.91800WY-P2 18 T5 SCSI bus controller mx1apvio03
    U5791.001.91800WY-P2 18 C05 PCI 1Gbps Ethernet mx1apvio03
    U5791.001.91800WY-P2 18 C06 Fibre Channel Serial Bus mx1apvio03
    U5791.001.91800WY-P2 18 C07 Empty slot  

    Server9119590SN51A972E

    Drawer Serial Bus Slot Adapter LPAR
    U5791.001.91800WT-P1 13 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 13 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WT-P1 13 C09 Empty slot  
    U5791.001.91800WT-P1 13 C10 Empty slot  
    U5791.001.91800WT-P1 14 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 15 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 15 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 15 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P1 15 C07 Empty slot  
    U5791.001.91800WT-P2 19 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 19 C08 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 19 C09 Empty slot  
    U5791.001.91800WT-P2 19 C10 Other Communications Device  
    U5791.001.91800WT-P2 20 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 21 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 21 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 21 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 21 C07 Empty slot  
    U5791.001.91800WW-P1 10 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 10 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WW-P1 10 C09 Empty slot  
    U5791.001.91800WW-P1 10 C10 Storage controller mx1apvio01
    U5791.001.91800WW-P1 11 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 12 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 12 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 12 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P1 12 C07 Empty slot  
    U5791.001.91800WW-P2 16 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 16 C08 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 16 C09 Empty slot  
    U5791.001.91800WW-P2 16 C10 Other Communications Device  
    U5791.001.91800WW-P2 17 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 18 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 18 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 18 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 18 C07 Empty slot  
    U5791.001.91800WT-P1 13 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 13 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WT-P1 13 C09 Empty slot  
    U5791.001.91800WT-P1 13 C10 Empty slot  
    U5791.001.91800WT-P1 14 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WT-P1 15 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P1 15 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P1 15 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P1 15 C07 Empty slot  
    U5791.001.91800WT-P2 19 T6 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 19 C08 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 19 C09 Empty slot  
    U5791.001.91800WT-P2 19 C10 Other Communications Device  
    U5791.001.91800WT-P2 20 C01 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio01
    U5791.001.91800WT-P2 21 T5 SCSI bus controller mx1apvio01
    U5791.001.91800WT-P2 21 C05 PCI 1Gbps Ethernet mx1apvio01
    U5791.001.91800WT-P2 21 C06 Fibre Channel Serial Bus mx1apvio01
    U5791.001.91800WT-P2 21 C07 Empty slot  
    U5791.001.91800WW-P1 10 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 10 C08 Fibre Channel Serial Bus mx1pocdb01
    U5791.001.91800WW-P1 10 C09 Empty slot  
    U5791.001.91800WW-P1 10 C10 Storage controller mx1apvio01
    U5791.001.91800WW-P1 11 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P1 12 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P1 12 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P1 12 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P1 12 C07 Empty slot  
    U5791.001.91800WW-P2 16 T6 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 16 C08 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 16 C09 Empty slot  
    U5791.001.91800WW-P2 16 C10 Other Communications Device  
    U5791.001.91800WW-P2 17 C01 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec  
    U5791.001.91800WW-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec mx1apvio02
    U5791.001.91800WW-P2 18 T5 SCSI bus controller mx1apvio02
    U5791.001.91800WW-P2 18 C05 PCI 1Gbps Ethernet mx1apvio02
    U5791.001.91800WW-P2 18 C06 Fibre Channel Serial Bus mx1apvio02
    U5791.001.91800WW-P2 18 C07 Empty slot  

    Configuring Virtual Ethernet Adapters

    Configuring virtual ethernet adapters for use in MtXia's high availability environment requires configuration of multiple server side ethernet adapters as well as multiple client side adapters. Each VIO server will have one server side ethernet adapter that can be shared to all client LPAR's requiring virtual ethernet adapters.

    This document describes a standard for establishing virtual ethernet adapters in the VIO Server environment. This standard is specific to the numbering scheme used to identify the VLAN ID's of the virtual ethernet adapters. The VLAN ID number is also referred to in the HMC as the PVID number.

    This document assumes there are two VIO servers in the environment and the names of the VIO servers are represented by "*vio0" and "*vio5".

    The VLAN ID numbers will be three digit numbers, each digit representing a different aspect of the underlying ethernet adapter.

    3 Digit VLAN ID Number
    First Digit Second Digit Third Digit
    5: Boot/Service
    6: Standby
    7: Backup
    8: Management
    9: Intra-Frame     		0: Gigabit
    5: 10/100
    9: Bus     		0,2,4,6,8: VIO Server with even numbered hostnames
    1,3,5,7,9: VIO Server with odd numberd hostnames

    The first digit of the VLAN ID numbers associated with virtual ethernet adapters will be used to represent a variety of adapter purposes. Those purposes include boot, standby, backup, management, and intra-frame communications.

    • 500-599: boot/service
    • 600-699: standby
    • 700-799: backup
    • 800-899: management
    • 900-999: intra-frame

    The third digit of the three digit VLAN ID number assigned to virtual ethernet adapters associated with the VIO Server named *vio0 will end with a number between 0 and 4.

    Example: 500, 501, 502, 510, 520, 521, ...

    The VLAN ID numbers assigned to virtual ethernet adapters associated with the VIO Server named *vio5 will end with an odd number beginning at 5.

    Example: 505, 506, 507, 515, 525, 526, ...

    The second digit of the three digit VLAN ID sequence will represent the adapter speed, gigabit cards will be represented by 0 thru 4, 10/100 adapters by 5 thru 8, and bus speed adapters by a 9. This digit may be reconfigured as necessary.

    Examples:

    Adapter Speed
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot 0 Gigabit *vio0
    501 Boot 1 Gigabit *vio0
    505 Boot 0 Gigabit *vio5
    506 Boot 1 Gigabit *vio5
           
    550 Boot 0 10/100 *vio0
    551 Boot 1 10/100 *vio0
    555 Boot 0 10/100 *vio5
    556 Boot 1 10/100 *vio5
           
    590 Boot 0 Bus *vio0
    591 Boot 0 Bus *vio0
    595 Boot 0 Bus *vio5
    596 Boot 1 Bus *vio5

    An LPAR may have multiple adapters of a variety of types, for example an LPAR that provides database services and is a member of an HACMP cluster may have boot, standby, management, backup, and intra-frame virtual adapters as follows:

    • Gigabit adapter used for boot/service address
    • Gigabit adapter used for standby address
    • 10/100 backup adapter
    • 10/100 management adapter
    • 2 intra-frame adapters

    VIO Server Configuration:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    600 Standby Gigabit *vio0
    750 Backup 10/100 *vio0
    850 Management 10/100 *vio0
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
           
    505 Boot Gigabit *vio5
    605 Standby Gigabit *vio5
    755 Backup 10/100 *vio5
    855 Management 10/100 *vio5
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    LPAR VLAN ID configuration to utilize virtual adapters:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    505 Boot Gigabit *vio5
    600 Standby Gigabit *vio0
    605 Standby Gigabit *vio5
    750 Backup 10/100 *vio0
    755 Backup 10/100 *vio5
    850 Management 10/100 *vio0
    855 Management 10/100 *vio5
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    This virtual ethernet information can be automatically gathered from an existing frame through the HMC using the script "virtualeth.ksh. Example output from this script follows:

    Server9119590SN51A972E

    Adapter Type Slot Trunk Device Port Virtual LAN ID MAC Address LPAR Name
    server 10 1 595 12F3F000200A mx1apvio01
    server 20 1 593 12F3F0002014 mx1apvio01
    server 15 1 594 12F3F000300F mx1apvio02
    server 25 1 592 12F3F0003019 mx1apvio02
    client 10 0 595 12F3F000500A mx1pocap01
    client 15 0 594 12F3F000500F mx1pocap01
    client 20 0 593 12F3F0005014 mx1pocap01
    client 25 0 592 12F3F0005019 mx1pocap01
    client 10 0 595 12F3F000600A mx1pocap02
    client 15 0 594 12F3F000600F mx1pocap02
    client 20 0 593 12F3F0006014 mx1pocap02
    client 25 0 592 12F3F0006019 mx1pocap02
    client 10 0 595 12F3F000700A mx1pocap03
    client 15 0 594 12F3F000700F mx1pocap03
    client 20 0 593 12F3F0007014 mx1pocap03
    client 25 0 592 12F3F0007019 mx1pocap03
    client 10 0 595 12F3F000400A mx1pocdb01
    client 15 0 594 12F3F000400F mx1pocdb01
    client 20 0 593 12F3F0004014 mx1pocdb01
    client 25 0 592 12F3F0004019 mx1pocdb01

    Server9119590SN51A973E

    Adapter Type Slot Trunk Device Port Virtual LAN ID MAC Address LPAR Name
    client 520 0 520 EE9530001208 mx1applm73
    client 525 0 525 EE953000120D mx1applm73
    server 10 1 510 EE953000300A mx1apvio03
    server 20 1 520 EE9530003014 mx1apvio03
    server 15 1 515 EE953000400F mx1apvio04
    server 25 1 525 EE9530004019 mx1apvio04
    client 10 0 510 EE953000500A mx1pocdb02
    client 15 0 515 EE953000500F mx1pocdb02
    client 20 0 520 EE9530005014 mx1pocdb02
    client 25 0 525 EE9530005019 mx1pocdb02

    Configuring Virtual SCSI Adapters

    Configuration of the virtual I/O adapters requires the knowledge of disk layouts as well as networking configuration. The virtual SCSI adapters require server and client side adapters to be configured on the HMC. The server side portion of the SCSI adapter, configured on the VIO, requires a frame wide unique "slot number" be defined. For high availability a server side portion of the SCSI adapter must be configured for each VIO server. This means that each virtual disk or logical volume connection is associated with two server side SCSI adapters, one on each VIO server. By convention the standard has become that each SCSI adapter is numbered as a multiple of 10, with the first SCSI adapter of the server side high availability pair being configured on the first VIO server and ending with the number 0, i.e., 210, 220, 230, 240, ... The second SCSI adapter of the server side high availability pair is configured on the second VIO server and ends with the number 5, i.e., 215, 225, 235, 245, ...

    For each LPAR that uses virtual disk or logical volumes, a client side virtual SCSI adapter must be configured on the HMC. The client side of the virtual SCSI adapter requires additional information and it's settings to correspond with the server side of the SCSI adapter. Coordination of the slot numbers defined here will make debugging and tracking of problems much easier and is highly desired. The information required to configure a client side SCSI adapter includes slot number, the name of the server side SCSI adapter remote partition, and the slot number of the server side SCSI adapter on the remote partition. The client side slot number should correspond with the server side slot number to make debugging and tracking easier. As an example of defining both server and client side SCSI adapters in a high availability environment:

    For each LPAR, a pair of virtual SCSI adapters shall be configured to be used for attachment of the operating system and paging disks. Another pair of virtual SCSI adapters shall be configured for the purpose of application disk attachment. The virtual SCSI adapters designated for use as operating system disk attachment shall be numbered between 10 and 199. The virtual SCSI adapters designated for use as application disk attachment shall be numbered between 200 and 499.

    Using this standard, each VIO server will have one virtual SCSI adapter per LPAR for the operating system, and one virtual SCSI adapter per LPAR for the application storage. Each LPAR will reference two virtual SCSI adapters, one from each VIO server, for the operating system storage, and two virtual SCSI adapters, one from each VIO server, for the application storage. Examples of this is shown below.

    Example Virtual SCSI Slot Numbers
    LPAR VIO 0
    OS Slot    		 VIO 1
    OS Slot    		 VIO 0
    Appl Slot    		 VIO 1
    Appl Slot
    mx1adcal01 10 15 200 205
    mx1adfim03 20 25 210 215
    mx1adesp01 30 35 220 225
    mx1apega01 40 45 230 235
    mx1aaora02 50 55 240 245

    Each virtual SCSI adapter may have one or more disks with it, depending upon the LPAR requirements. These disk associations are performed on the VIO server by referencing the slot numbers assigned to each LPAR.

    This virtual SCSI adapter information can be automatically gathered from an existing frame through the HMC using the script "virtualscsi.ksh. Example output from this script follows:

    Server9119590SN51A972E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 100 any 0x8100000000000000//ap01rootlv mx1apvio01
    server 110 any 0x8100000000000000//ap02rootlv mx1apvio01
    server 120 any 0x8100000000000000//ap03rootlv mx1apvio01
    server 130 any 0x8100000000000000//db01rootlv mx1apvio01
    server 150 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L1000000000000/hdisk5 mx1apvio01
    server 160 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L2000000000000/hdisk6 mx1apvio01
    server 170 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L3000000000000/hdisk7 mx1apvio01
    client 190 mx1apvio01 190 none mx1pocdb01
    server 30 any 0x8100000000000000//pocap01lv mx1apvio01
    server 40 any 0x8100000000000000//pocap02lv mx1apvio01
    server 50 any 0x8100000000000000//pocap03lv mx1apvio01
    server 60 any 0x8100000000000000//pocdb01lv mx1apvio01
    server 105 any // mx1apvio02
    server 115 any // mx1apvio02
    server 125 any // mx1apvio02
    server 135 any // mx1apvio02
    server 155 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L1000000000000/hdisk5 mx1apvio02
    server 165 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L2000000000000/hdisk6 mx1apvio02
    server 175 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L3000000000000/hdisk7 mx1apvio02
    client 195 mx1apvio02 195 none mx1pocdb01
    server 35 any 0x8100000000000000//pocap01lv mx1apvio02
    server 45 any 0x8100000000000000//pocap02lv mx1apvio02
    server 55 any 0x8100000000000000//pocap03lv mx1apvio02
    server 65 any 0x8100000000000000//pocdb01lv mx1apvio02
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 190 mx1apvio01 190 none mx1pocdb01
    client 195 mx1apvio02 195 none mx1pocdb01
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01

    Server9119590SN51A973E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    server 130 any 0x8100000000000000//sdb02rootlv mx1apvio03
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    client 190 mx1apvio03 190 none mx1pocdb02
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    client 195 mx1apvio04 195 none mx1pocdb02
    server 65 any 0x8100000000000000//db02rootlv mx1apvio04
    client 190 mx1apvio03 190 none mx1pocdb02
    client 195 mx1apvio04 195 none mx1pocdb02
    client 2 mx1apvio04 65 none mx1pocdb02
    client 3 mx1apvio03 130 none mx1pocdb02

    Table of Contents

    Config VEthnet

    Configuring Virtual Ethernet Adapters

    Configuring virtual ethernet adapters for use in MtXia's high availability environment requires configuration of multiple server side ethernet adapters as well as multiple client side adapters. Each VIO server will have one server side ethernet adapter that can be shared to all client LPAR's requiring virtual ethernet adapters.

    This document describes a standard for establishing virtual ethernet adapters in the VIO Server environment. This standard is specific to the numbering scheme used to identify the VLAN ID's of the virtual ethernet adapters. The VLAN ID number is also referred to in the HMC as the PVID number.

    This document assumes there are two VIO servers in the environment and the names of the VIO servers are represented by "*vio0" and "*vio5".

    The VLAN ID numbers will be three digit numbers, each digit representing a different aspect of the underlying ethernet adapter.

    3 Digit VLAN ID Number
    First Digit Second Digit Third Digit
    5: Boot/Service
    6: Standby
    7: Backup
    8: Management
    9: Intra-Frame     		0: Gigabit
    5: 10/100
    9: Bus     		0,2,4,6,8: VIO Server with even numbered hostnames
    1,3,5,7,9: VIO Server with odd numberd hostnames

    The first digit of the VLAN ID numbers associated with virtual ethernet adapters will be used to represent a variety of adapter purposes. Those purposes include boot, standby, backup, management, and intra-frame communications.

    • 500-599: boot/service
    • 600-699: standby
    • 700-799: backup
    • 800-899: management
    • 900-999: intra-frame

    The third digit of the three digit VLAN ID number assigned to virtual ethernet adapters associated with the VIO Server named *vio0 will end with a number between 0 and 4.

    Example: 500, 501, 502, 510, 520, 521, ...

    The VLAN ID numbers assigned to virtual ethernet adapters associated with the VIO Server named *vio5 will end with an odd number beginning at 5.

    Example: 505, 506, 507, 515, 525, 526, ...

    The second digit of the three digit VLAN ID sequence will represent the adapter speed, gigabit cards will be represented by 0 thru 4, 10/100 adapters by 5 thru 8, and bus speed adapters by a 9. This digit may be reconfigured as necessary.

    Examples:

    Adapter Speed
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot 0 Gigabit *vio0
    501 Boot 1 Gigabit *vio0
    505 Boot 0 Gigabit *vio5
    506 Boot 1 Gigabit *vio5
           
    550 Boot 0 10/100 *vio0
    551 Boot 1 10/100 *vio0
    555 Boot 0 10/100 *vio5
    556 Boot 1 10/100 *vio5
           
    590 Boot 0 Bus *vio0
    591 Boot 0 Bus *vio0
    595 Boot 0 Bus *vio5
    596 Boot 1 Bus *vio5

    An LPAR may have multiple adapters of a variety of types, for example an LPAR that provides database services and is a member of an HACMP cluster may have boot, standby, management, backup, and intra-frame virtual adapters as follows:

    • Gigabit adapter used for boot/service address
    • Gigabit adapter used for standby address
    • 10/100 backup adapter
    • 10/100 management adapter
    • 2 intra-frame adapters

    VIO Server Configuration:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    600 Standby Gigabit *vio0
    750 Backup 10/100 *vio0
    850 Management 10/100 *vio0
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
           
    505 Boot Gigabit *vio5
    605 Standby Gigabit *vio5
    755 Backup 10/100 *vio5
    855 Management 10/100 *vio5
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    LPAR VLAN ID configuration to utilize virtual adapters:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    505 Boot Gigabit *vio5
    600 Standby Gigabit *vio0
    605 Standby Gigabit *vio5
    750 Backup 10/100 *vio0
    755 Backup 10/100 *vio5
    850 Management 10/100 *vio0
    855 Management 10/100 *vio5
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    This virtual ethernet information can be automatically gathered from an existing frame through the HMC using the script "virtualeth.ksh. Example output from this script follows:

    Server9119590SN51A972E

    Adapter Type Slot Trunk Device Port Virtual LAN ID MAC Address LPAR Name
    server 10 1 595 12F3F000200A mx1apvio01
    server 20 1 593 12F3F0002014 mx1apvio01
    server 15 1 594 12F3F000300F mx1apvio02
    server 25 1 592 12F3F0003019 mx1apvio02
    client 10 0 595 12F3F000500A mx1pocap01
    client 15 0 594 12F3F000500F mx1pocap01
    client 20 0 593 12F3F0005014 mx1pocap01
    client 25 0 592 12F3F0005019 mx1pocap01
    client 10 0 595 12F3F000600A mx1pocap02
    client 15 0 594 12F3F000600F mx1pocap02
    client 20 0 593 12F3F0006014 mx1pocap02
    client 25 0 592 12F3F0006019 mx1pocap02
    client 10 0 595 12F3F000700A mx1pocap03
    client 15 0 594 12F3F000700F mx1pocap03
    client 20 0 593 12F3F0007014 mx1pocap03
    client 25 0 592 12F3F0007019 mx1pocap03
    client 10 0 595 12F3F000400A mx1pocdb01
    client 15 0 594 12F3F000400F mx1pocdb01
    client 20 0 593 12F3F0004014 mx1pocdb01
    client 25 0 592 12F3F0004019 mx1pocdb01

    Server9119590SN51A973E

    Adapter Type Slot Trunk Device Port Virtual LAN ID MAC Address LPAR Name
    client 520 0 520 EE9530001208 mx1applm73
    client 525 0 525 EE953000120D mx1applm73
    server 10 1 510 EE953000300A mx1apvio03
    server 20 1 520 EE9530003014 mx1apvio03
    server 15 1 515 EE953000400F mx1apvio04
    server 25 1 525 EE9530004019 mx1apvio04
    client 10 0 510 EE953000500A mx1pocdb02
    client 15 0 515 EE953000500F mx1pocdb02
    client 20 0 520 EE9530005014 mx1pocdb02
    client 25 0 525 EE9530005019 mx1pocdb02

    Table of Contents

    Config VSCSI

    Configuring Virtual SCSI Adapters

    Configuration of the virtual I/O adapters requires the knowledge of disk layouts as well as networking configuration. The virtual SCSI adapters require server and client side adapters to be configured on the HMC. The server side portion of the SCSI adapter, configured on the VIO, requires a frame wide unique "slot number" be defined. For high availability a server side portion of the SCSI adapter must be configured for each VIO server. This means that each virtual disk or logical volume connection is associated with two server side SCSI adapters, one on each VIO server. By convention the standard has become that each SCSI adapter is numbered as a multiple of 10, with the first SCSI adapter of the server side high availability pair being configured on the first VIO server and ending with the number 0, i.e., 210, 220, 230, 240, ... The second SCSI adapter of the server side high availability pair is configured on the second VIO server and ends with the number 5, i.e., 215, 225, 235, 245, ...

    For each LPAR that uses virtual disk or logical volumes, a client side virtual SCSI adapter must be configured on the HMC. The client side of the virtual SCSI adapter requires additional information and it's settings to correspond with the server side of the SCSI adapter. Coordination of the slot numbers defined here will make debugging and tracking of problems much easier and is highly desired. The information required to configure a client side SCSI adapter includes slot number, the name of the server side SCSI adapter remote partition, and the slot number of the server side SCSI adapter on the remote partition. The client side slot number should correspond with the server side slot number to make debugging and tracking easier. As an example of defining both server and client side SCSI adapters in a high availability environment:

    For each LPAR, a pair of virtual SCSI adapters shall be configured to be used for attachment of the operating system and paging disks. Another pair of virtual SCSI adapters shall be configured for the purpose of application disk attachment. The virtual SCSI adapters designated for use as operating system disk attachment shall be numbered between 10 and 199. The virtual SCSI adapters designated for use as application disk attachment shall be numbered between 200 and 499.

    Using this standard, each VIO server will have one virtual SCSI adapter per LPAR for the operating system, and one virtual SCSI adapter per LPAR for the application storage. Each LPAR will reference two virtual SCSI adapters, one from each VIO server, for the operating system storage, and two virtual SCSI adapters, one from each VIO server, for the application storage. Examples of this is shown below.

    Example Virtual SCSI Slot Numbers
    LPAR VIO 0
    OS Slot    		 VIO 1
    OS Slot    		 VIO 0
    Appl Slot    		 VIO 1
    Appl Slot
    mx1adcal01 10 15 200 205
    mx1adfim03 20 25 210 215
    mx1adesp01 30 35 220 225
    mx1apega01 40 45 230 235
    mx1aaora02 50 55 240 245

    Each virtual SCSI adapter may have one or more disks with it, depending upon the LPAR requirements. These disk associations are performed on the VIO server by referencing the slot numbers assigned to each LPAR.

    This virtual SCSI adapter information can be automatically gathered from an existing frame through the HMC using the script "virtualscsi.ksh. Example output from this script follows:

    Server9119590SN51A972E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 100 any 0x8100000000000000//ap01rootlv mx1apvio01
    server 110 any 0x8100000000000000//ap02rootlv mx1apvio01
    server 120 any 0x8100000000000000//ap03rootlv mx1apvio01
    server 130 any 0x8100000000000000//db01rootlv mx1apvio01
    server 150 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L1000000000000/hdisk5 mx1apvio01
    server 160 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L2000000000000/hdisk6 mx1apvio01
    server 170 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L3000000000000/hdisk7 mx1apvio01
    client 190 mx1apvio01 190 none mx1pocdb01
    server 30 any 0x8100000000000000//pocap01lv mx1apvio01
    server 40 any 0x8100000000000000//pocap02lv mx1apvio01
    server 50 any 0x8100000000000000//pocap03lv mx1apvio01
    server 60 any 0x8100000000000000//pocdb01lv mx1apvio01
    server 105 any // mx1apvio02
    server 115 any // mx1apvio02
    server 125 any // mx1apvio02
    server 135 any // mx1apvio02
    server 155 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L1000000000000/hdisk5 mx1apvio02
    server 165 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L2000000000000/hdisk6 mx1apvio02
    server 175 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L3000000000000/hdisk7 mx1apvio02
    client 195 mx1apvio02 195 none mx1pocdb01
    server 35 any 0x8100000000000000//pocap01lv mx1apvio02
    server 45 any 0x8100000000000000//pocap02lv mx1apvio02
    server 55 any 0x8100000000000000//pocap03lv mx1apvio02
    server 65 any 0x8100000000000000//pocdb01lv mx1apvio02
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 190 mx1apvio01 190 none mx1pocdb01
    client 195 mx1apvio02 195 none mx1pocdb01
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01

    Server9119590SN51A973E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    server 130 any 0x8100000000000000//sdb02rootlv mx1apvio03
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    client 190 mx1apvio03 190 none mx1pocdb02
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    client 195 mx1apvio04 195 none mx1pocdb02
    server 65 any 0x8100000000000000//db02rootlv mx1apvio04
    client 190 mx1apvio03 190 none mx1pocdb02
    client 195 mx1apvio04 195 none mx1pocdb02
    client 2 mx1apvio04 65 none mx1pocdb02
    client 3 mx1apvio03 130 none mx1pocdb02

    Table of Contents

    VIO Server

    Virtual I/O Server Standards

    Defined here are the standards that describe how a Virtual I/O (VIO) server will be configured in the MtXia environment. The purpose of these standards is to ensure business continuity, disaster recovery, high availability, serviceability, managability, and supportability of the virtualized environment.

    Procedure to enable centralized statistics gathering from a VIO server via WLM

    The Virtual I/O (VIO) servers should not have extraneous software installed on them, therefore the performance toolbox software is not installed or enabled. However the Workload Manager (WLM) is installed and should be enabled in passive mode. The procedure to enable WLM on the VIO servers follows:

    This procedure assumes there is a centralized storage location for the WLM statistics shared to the VIO server via NFS. In the following example the centralized storage is located on the MX1 NIM server whose hostname is "mx1apnim01". The specific directory being shared via NFS from "mx1apnim01" is "/prfdmce0".

    This procedure also uses an example VIO server hostname of "mx1advio01".

    Establish the NFS mount from the centralized NFS storage location.

    /usr/sbin/mknfsmnt -f /prfdmce0 -d /prfdmce0 -h mx1apnim01-mc2 -M sys -t rw -w bg -ABSXYZ -jqg

    Add a directory to the centralized NFS storage location to contain the statistics files from the VIO server.

    mkdir -p /prfdmce0/ddadvio01/wlm

    Add a record line to "/etc/inittab" to start the WLM statistics gathering daemon

    mkitab 'ptxwlm:2:respawn:/usr/bin/xmwlm -d /prfdmce0/mx1advio01/wlm -n xmwlm > /dev/null 2>&1'

    Start the WLM in "passive" mode.

    /usr/sbin/wlmcntrl -p > /dev/console 2>&1

    Add a record to the "/etc/inittab" to start the WLM at system boot time.

    mkitab -i rc 'wlm:2:once:/usr/sbin/wlmcntrl -p > /dev/console 2>&1'

    Table of Contents

    VIO VLAN ID

    This document describes a standard for establishing virtual ethernet adapters in the VIO Server environment. This standard is specific to the numbering scheme used to identify the VLAN ID's of the virtual ethernet adapters. The VLAN ID number is also referred to in the HMC as the PVID number.

    This document assumes there are two VIO servers in the environment and the names of the VIO servers are represented by "*vio0" and "*vio5".

    The VLAN ID numbers will be three digit numbers, each digit representing a different aspect of the underlying ethernet adapter.

    3 Digit VLAN ID Number
    First Digit Second Digit Third Digit
    5: Boot/Service
    6: Standby
    7: Backup
    8: Management
    9: Intra-Frame     		0: Gigabit
    5: 10/100
    9: Bus     		0: VIO Server 0
    5: VIO Server 5

    The first digit of the VLAN ID numbers associated with virtual ethernet adapters will be used to represent a variety of adapter purposes. Those purposes include boot, standby, backup, management, and intra-frame communications.

    • 500-599: boot/service
    • 600-699: standby
    • 700-799: backup
    • 800-899: management
    • 900-999: intra-frame

    The third digit of the three digit VLAN ID number assigned to virtual ethernet adapters associated with the VIO Server named *vio0 will end with a number between 0 and 4.

    Example: 500, 501, 502, 510, 520, 521, ...

    The VLAN ID numbers assigned to virtual ethernet adapters associated with the VIO Server named *vio5 will end with an odd number beginning at 5.

    Example: 505, 506, 507, 515, 525, 526, ...

    The second digit of the three digit VLAN ID sequence will represent the adapter speed, gigabit cards will be represented by 0 thru 4, 10/100 adapters by 5 thru 8, and bus speed adapters by a 9. This digit may be reconfigured as necessary.

    Examples:

    Adapter Speed
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot 0 Gigabit *vio0
    501 Boot 1 Gigabit *vio0
    505 Boot 0 Gigabit *vio5
    506 Boot 1 Gigabit *vio5
           
    550 Boot 0 10/100 *vio0
    551 Boot 1 10/100 *vio0
    555 Boot 0 10/100 *vio5
    556 Boot 1 10/100 *vio5
           
    590 Boot 0 Bus *vio0
    591 Boot 0 Bus *vio0
    595 Boot 0 Bus *vio5
    596 Boot 1 Bus *vio5

    An LPAR may have multiple adapters of a variety of types, for example an LPAR that provides database services and is a member of an HACMP cluster may have boot, standby, management, backup, and intra-frame virtual adapters as follows:

    • Gigabit adapter used for boot/service address
    • Gigabit adapter used for standby address
    • 10/100 backup adapter
    • 10/100 management adapter
    • 2 intra-frame adapters

    VIO Server Configuration:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    600 Standby Gigabit *vio0
    750 Backup 10/100 *vio0
    850 Management 10/100 *vio0
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
           
    505 Boot Gigabit *vio5
    605 Standby Gigabit *vio5
    755 Backup 10/100 *vio5
    855 Management 10/100 *vio5
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    LPAR VLAN ID configuration to utilize virtual adapters:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    505 Boot Gigabit *vio5
    600 Standby Gigabit *vio0
    605 Standby Gigabit *vio5
    750 Backup 10/100 *vio0
    755 Backup 10/100 *vio5
    850 Management 10/100 *vio0
    855 Management 10/100 *vio5
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    Table of Contents

    VIO SCSI ID

    Configuration of the virtual I/O adapters requires the knowledge of disk layouts as well as networking configuration. The virtual SCSI adapters require a server and a client adapter to be configured on the HMC. The server side portion of the SCSI adapter requires a frame wide unique "slot number" be defined. For high availability a server side portion of the SCSI adapter must be configured for each VIO server. This means that for each virtual disk or logical volume connection, 2 server side SCSI adapters will be configured, one for each VIO server. By convention the standard has become that each SCSI adapter is numbered as a multiple of 10, with the first SCSI adapter of the server side high availability pair being configured on the first VIO server and ending with the number 0, i.e., 210, 220, 230, 240, ... The second SCSI adapter of the server side high availability pair is configured on the second VIO server and ends with the number 5, i.e., 215, 225, 235, 245, ...

    For each LPAR that uses virtual disk or logical volumes, a client side virtual SCSI adapter must be configured on the HMC. The client side of the virtual SCSI adapter requires additional information and it's settings to correspond with the server side of the SCSI adapter. Coordination of the slot numbers defined here will make debugging and tracking of problems much easier and is highly desired. The information required to configure a client side SCSI adapter includes slot number, the name of the server side SCSI adapter remote partition, and the slot number of the server side SCSI adapter on the remote partition. The client side slot number should correspond with the server side slot number to make debugging and tracking easier. As an example of defining both server and client side SCSI adapters in a high availability environment:

    LPAR Type Slot
    Number    		 Remote
    Partition    		 Remote
    Slot Number
    mx1apvio01 server 210
    mx1apvio02 server 215
    mx1pocap01 client 210 mx1apvio01 210
    mx1pocap01 client 215 mx1apvio02 215
    mx1apvio01 server 220
    mx1apvio02 server 125
    mx1pocap02 client 220 mx1apvio01 220
    mx1pocap02 client 225 mx1apvio02 225
    mx1apvio01 server 230
    mx1apvio02 server 235
    mx1pocap03 client 230 mx1apvio01 230
    mx1pocap03 client 235 mx1apvio02 235
    mx1apvio01 server 240
    mx1apvio02 server 245
    mx1pocap04 client 240 mx1apvio01 240
    mx1pocap04 client 245 mx1apvio02 245

    This virtual SCSI adapter information can be automatically gathered from an existing frame through the HMC using the script "virtualscsi.ksh. Example output from this script follows:

    Server9119590SN51A972E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 100 any 0x8100000000000000//ap01rootlv mx1apvio01
    server 110 any 0x8100000000000000//ap02rootlv mx1apvio01
    server 120 any 0x8100000000000000//ap03rootlv mx1apvio01
    server 130 any 0x8100000000000000//db01rootlv mx1apvio01
    server 150 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L1000000000000/hdisk5 mx1apvio01
    server 160 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L2000000000000/hdisk6 mx1apvio01
    server 170 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L3000000000000/hdisk7 mx1apvio01
    client 190 mx1apvio01 190 none mx1pocdb01
    server 30 any 0x8100000000000000//pocap01lv mx1apvio01
    server 40 any 0x8100000000000000//pocap02lv mx1apvio01
    server 50 any 0x8100000000000000//pocap03lv mx1apvio01
    server 60 any 0x8100000000000000//pocdb01lv mx1apvio01
    server 105 any // mx1apvio02
    server 115 any // mx1apvio02
    server 125 any // mx1apvio02
    server 135 any // mx1apvio02
    server 155 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L1000000000000/hdisk5 mx1apvio02
    server 165 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L2000000000000/hdisk6 mx1apvio02
    server 175 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L3000000000000/hdisk7 mx1apvio02
    client 195 mx1apvio02 195 none mx1pocdb01
    server 35 any 0x8100000000000000//pocap01lv mx1apvio02
    server 45 any 0x8100000000000000//pocap02lv mx1apvio02
    server 55 any 0x8100000000000000//pocap03lv mx1apvio02
    server 65 any 0x8100000000000000//pocdb01lv mx1apvio02
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 190 mx1apvio01 190 none mx1pocdb01
    client 195 mx1apvio02 195 none mx1pocdb01
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01

    Server9119590SN51A973E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    server 130 any 0x8100000000000000//sdb02rootlv mx1apvio03
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    client 190 mx1apvio03 190 none mx1pocdb02
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    client 195 mx1apvio04 195 none mx1pocdb02
    server 65 any 0x8100000000000000//db02rootlv mx1apvio04
    client 190 mx1apvio03 190 none mx1pocdb02
    client 195 mx1apvio04 195 none mx1pocdb02
    client 2 mx1apvio04 65 none mx1pocdb02
    client 3 mx1apvio03 130 none mx1pocdb02

    Table of Contents

    PLM

    Partition Load Manager Standards

    The Partition Load Manager (PLM) provides CPU and memory resource management and monitoring across logical partitions (LPARs). Partition Load Manager allows you to effectively use CPU and Memory resources by allowing you to set thresholds for designated resources. When a threshold is exceeded, Partition Load Manager can try to assign CPU and/or Memory resources to that LPAR by using resources assigned to other LPARs that are not being used.

    Determining which node is more or less deserving of resources is primarily done by taking into account certain values defined in what is known as a policy file. This policy file details partitions, their entitlements, their thresholds, and organizes the partitions into groups. Every node, but not every LPAR, managed by Partition Load Manager must be defined in the policy file along with several associated attribute values. Some of the attributes that are associated with the node are the maximum, minimum, and guaranteed resource values, variable share values, and so on. These are the attributes taken into consideration by Partition Load Manager when a decision is made as to whether a resource is reallocated from one LPAR to another.

    PLM is an automated mechanism for utilizing the Dynamic LPAR (DLPAR) capabilities of the HMC and requires communication with the HMC. This means that before PLM will function, DLPAR must be functional on the HMC. DLPAR requires communication with each LPAR via the Resource Monitoring and Control (RMC) subsystem.

    NOTE: The RMC subsystem is not installed when the AIX operating system is installed from the NIM server as an "rte" install.

    The following fileset must be installed on every PLM client LPAR to enable RMC communications with the HMC and PLM:

    csm.client

    The PLM communications are also dependent upon SSH and SSL and must be installed on every PLM client LPAR.

    Refer to the PLM configuration procedures for more information

    A single PLM server can manage multiple frames across multiple HMC's. In the MtXia environment there is a single primary PLM in each data center. Within a frame there are two classifications of CPU's, dedicated and shared. Policy files are used by the PLM to control each frame and a single policy file will exist for each frame. The policy file is named for the serial number of each frame. When new frames are added to MtXia's environment, a policy file will be created on the PLM and the name of the policy file will be the serial number of the frame. Policy files currently exist with names such as:

    • 107CE4E - p520 - Warner Home Video
    • 10F6BEE - p570 - Warner Home Video
    • 51A972E - p590 - Mt Xia
    • 51A973E - p590 - Mt Xia

    Every LPAR created in the MtXia environment will be managed by a PLM and will be initially assigned a minimum amount of CPU and memory resources. This means there will be a policy file on the PLM for every frame in the data center where the PLM exists.

    Within a PLM policy there are two groups to represent the two CPU classifications, dedicated and shared. Each LPAR will be assigned to one of these two groups, depending upon what type of CPU's are assigned to the LPAR.

    As a configuration standard, every policy will be configured to immediately release free CPU and memory resources. Most other configuration parameters within the PLM will depend upon the LPAR and application requirements.

    Table of Contents

    LPAR

    Logical Partition Standards

    LPAR, short for logical partitioning, is a mechanism of taking a computer's total resources - processors, memory and storage -- and splitting them into smaller units that each can be run with its own instance of the operating system and applications. Each partition can communicate with the other partitions as if the other partition is in a separate machine.

    In MtXia's environment, the ability to obtain outages for the purpose of maintenance and upgrades will be difficult. Furthermore, systems supporting multiple business functions will be even more difficult to obtain outage windows. Therefore it is desirable to create LPAR's to support each business function, thus reducing the impact of an outage upon the overall environment. So rather than creating large LPAR's supporting multiple business functions for a client, it is preferable to create multiple LPARs to support each business function.

    When creating an LPAR, the following standards will be applied:

    • The LPAR name and profile name will be the same as the short machine name assigned to the LPAR.
    • Minimum Memory: 512 MB
    • Desired Memory: 512 MB
    • Maximum Memory: All available memory

    For LPARs that will require 3 physical processors or less during normal operations:

    • Processor Mode: shared
    • Minimum processing units: 0.20
    • Desired processing units: 0.20
    • Maximum processing units: All available CPUs
    • Minimum Virtual Processors: 2
    • Desired Virtual Processors: 2
    • Maximum Virtual Processors: 30

    For LPARs that will require more than 3 physical processors during normal operation:

    • Processor Mode: shared
    • Minimum processing units: 1.00
    • Desired processing units: 1.00
    • Maximum processing units: All available CPUs
    • Minimum Virtual Processors: 2
    • Desired Virtual Processors: 2
    • Maximum Virtual Processors: 64

    Physical I/O will be assigned as required by the business functions supported by by each LPAR, Virtual I/O will be assigned as required by each LPAR and in accordance with MtXia's VIO standards. Connection monitoring will be enabled for each LPAR and no LPARs will be started automatically when the frame is powered on.

    Table of Contents

    NIM

    Network Information Manager Standards

    Features

    NIM permits the installation and maintenance of AIX, its basic operating system, and additional software and fixes that may be applied over a period of time over token-ring, ethernet, FDDI, and ATM net works.

    NIM also permits the customization of machines both during and after installation . As a result, NIM has eliminated the reliance on tapes and CD-ROMs for software installation; the onus, in NIM’sase, is on the network. NIM will allow one machine to act as a master in the environment. This machine will be responsible for storing information about the clients it supports, the resources it or other servers provide to these clients, and the networks on which they operate.

    Benefits

    Some of the benefits of NIM are:

    • Manageability - It allows central localization of software installation images, thus, making backup and administration easier.
    • Central Administration - Administrators can install remote AIX machines without having to physically attend them.
    • Scalability - You can install more than one machine at a time, implement a group strategy of machines and resources, and choose how many machines to install at a time.
    • Usability - VSM GUI for NIM has been improved so that, now, it can be used to configure NIM groups.
    • Availability - Where server down time means loss of profits, NIM provides you with a backup image of all your servers. A new server can be set up and running in just over an hour.
    • Non-prompted installation - NIM provides a function to install systems without having to go to the machine, thus, avoiding the sneaker net method.

    Installations can be initiated by either the client or master at a convenient time. For example, if a client is unavailable at the time of the install, you can initiate an install when it is back on line, or, if there is less traffic on your network at a certain time, you can initiate the installations to occur then.

    It is a relatively faster means of installation than tape or CD-ROM.

    NIM provides greater functionality than CD-ROM or tape. Among other things, it allows you to customize an install, initiate a non-prompted install, or install additional software.

    MtXia's NIM Environment

    NIM Server Machines

    Each data center currently has one NIM server which serves various resources to the client machines in that data center. Some cross data center communication occurs for the purpose of disaster recovery. The NIM Server machines are:

    • Mesquite Data Center: mx0apnim01.tu.com
    • Dallas Data Center: mx1apnim01.tu.com

    No NIM Alternate-Master servers are currently configured, but will be implemented soon. This capability will provide automated redundancy of NIM resources between data centers.

    NIM Client Machines

    All AIX and linux machines in the MtXia enviroment utilize resources originating from the NIM Servers.

    NIM Resources

    The resources available from the NIM servers include operating systems, OS updates, OS backup and restores, clustering software, applications, device drivers, firmware, and disaster recovery services and information. These resources can be delivered from any NIM server to any NIM client in any MtXia data center. Some of the resources available on the NIM Servers include:

    • AIX
    • Linux
    • mksysb repository
    • AIX Maintenance Levels
    • AIX APAR's
    • AIX Fixes
    • HACMP
    • HACMP-ES
    • MQ Series Software
    • Tivoli Storage Manager Software
    • Linux Toolbox for AIX
    • freeware
    • Hitachi Sofware
    • Performance monitoring software
    • firmware updates
    • Disaster Recovery hub for AIX

    NIM Server Operations

    Using the resources previously listed, a wide variety of operations may be peformed on or by a NIM client. These operations include the ability to perform a bare-metal install of a new operating sytem or backup. Other operating system installation options are also available, dependent only upon what the system administrator is attempting to accomplish. For example, using the NIM server, a backup of a production machine can be performed, the backup restored to an alternate-disk on the same production machine, and the operating system on the alternate-disk can be updated to the latest maintenance level, all without interuption or downtime to the production machine. Some of the operations that are regularly performed utilizing the resources provided by the NIM servers include:

  • Network boot server
  • AIX operating system installation
  • AIX operating system maintenance level updates
  • AIX operating system APAR updates
  • AIX operating system efix updates
  • AIX mksysb repository
  • AIX mksysb installation
  • AIX alt-clone installation
  • AIX alt-clone maintenance level updates
  • AIX alt-disk installation
  • Linux operating system installation
  • Linux operating rpm updates
  • Oracle database installation
  • Application installation and updates
  • Script Server
  • Disaster Recovery information gathering
  • Disaster Recovery information distribution
  • Disaster Recovery automated documentation generator

    • NIM Server Structure

    To maintain structure and order on the NIM Servers, a specific directory hierarchy has been adopted and utilized. This structure must be observed and practiced when making modifications to the resources provided by the NIM Servers.

    The top level directory for storage of NIM resources begins at the directory:

    /export

    Each resource class provided by the NIM server should exist as a subdirectory under /export. The list of valid NIM resource classes are:

    • boot: represents the network boot resource
    • nim_script: directory containing customization scripts created by NIM
    • spot: Shared Product Object Tree - equivalent to /usr/filesystem
    • root: parent directory for client / (root) directories
    • paging: parent directory for client paging files
    • dump: parent directory for client dump files
    • home: parent directory for client /home directories
    • shared_home: home directory shared by clients
    • tmp: parent directory for client /tmp directories
    • exclude_files: files to be excluded when creating a mksysb or savevg image
    • lpp_source: source device for optional product images
    • installp_bundle: installp bundle file
    • fix_bundle: fix (keyword) input file for the cust or fix_query operation
    • bosinst_data: config file used during base system installation
    • image_data: config file used during base system installation
    • vg_data: config file used during volume group restoration
    • mksysb: a mksysb image
    • script: an executable file which is executed on a client
    • resolv_conf: configuration file for name-server information
    • savevg: a savevg image
    • adapter_def: directory containing secondary adapter definition files
    • fb_script: an executable script added to /etc/firstboot and run at first reboot after bos install to configure devices.

    Not all NIM resource classes are currently utilized, however when a new resource is utilized, this guide should be followed for the directory naming structure.

    The currently implemented NIM resource classes and class instances follow. Naming conventions for class instances are included here and should be adhered to when new class instances are created:

    Currently implemented NIM Resource's

  • /export/bosinst_data

    The "bosinst_data" resource class is for the configuration files used during the AIX base operating system installation. The default instance shall be named "bosinst_data". Additional instances shall be suffixed with unique identifying information such as the AIX Operating System version number, machine name, user name, application name, etc. Example instances of the "bosinst_data" resource class and file follow:

    bosinst_data Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    ID     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    Base OS Install Data bosinst_data Default   bosinst_data /export/bosinst_data/bosinst_data
    Base OS Install Data bosinst_data noprompt   bosinst_data_noprompt /export/bosinst_data/bosinst_data_noprompt
    Base OS Install Data bosinst_data mx0iaapp52   bosinst_data_mx0iaapp52 /export/bosinst_data/bosinst_data_mx0iaapp52
    Base OS Install Data bosinst_data egate   bosinst_data_egate /export/bosinst_data/bosinst_data_egate
    Base OS Install Data bosinst_data 4330   bosinst_data_4330 /export/bosinst_data/bosinst_data_4330
    Base OS Install Data bosinst_data 4330 10 bosinst_data_4330-10 /export/bosinst_data/bosinst_data_4330-10
    Base OS Install Data bosinst_data 4330 11 bosinst_data_4330-11 /export/bosinst_data/bosinst_data_4330-11
    Base OS Install Data bosinst_data 4330 09 bosinst_data_4330-09 /export/bosinst_data/bosinst_data_4330-09
    Base OS Install Data bosinst_data 4330 10.5 bosinst_data_4330-10_5 /export/bosinst_data/bosinst_data_4330-10_5
    Base OS Install Data bosinst_data 5100   bosinst_data_5100 /export/bosinst_data/bosinst_data_5100
    Base OS Install Data bosinst_data 5100 02 bosinst_data_5100-02 /export/bosinst_data/bosinst_data_5100-02
    Base OS Install Data bosinst_data 5200   bosinst_data_5200 /export/bosinst_data/bosinst_data_5200
    Base OS Install Data bosinst_data 5200 01 bosinst_data_5200-01 /export/bosinst_data/bosinst_data_5200-01
    Base OS Install Data bosinst_data 5200 02 bosinst_data_5200-02 /export/bosinst_data/bosinst_data_5200-02
    Base OS Install Data bosinst_data 5200 04 bosinst_data_5200-04 /export/bosinst_data/bosinst_data_5200-04
    Base OS Install Data bosinst_data 5200 05 bosinst_data_5200-05 /export/bosinst_data/bosinst_data_5200-05
    Base OS Install Data bosinst_data 5300   bosinst_data_5300 /export/bosinst_data/bosinst_data_5300
    Base OS Install Data bosinst_data 5300 01 bosinst_data_5300-01 /export/bosinst_data/bosinst_data_5300-01

    When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "bosinst_data" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.

  • /export/image.data

    The "image_data" resource class is for the configuration files used during the AIX base operating system installation. The default instance shall be named "image_data". Additional instances shall be suffixed with unique identifying information such as the AIX Operating System version number, machine name, user name, application name, etc. Example instances of the "image_data" resource class and file follow:

    image_data Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    ID     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    Base OS Install Data image_data Default   image_data /export/image_data/image_data
    Base OS Install Data image_data noprompt   image_data_noprompt /export/image_data/image_data_noprompt
    Base OS Install Data image_data mx0iaapp52   image_data_mx0iaapp52 /export/image_data/image_data_mx0iaapp52
    Base OS Install Data image_data egate   image_data_egate /export/image_data/image_data_egate
    Base OS Install Data image_data 4330   image_data_4330 /export/image_data/image_data_4330
    Base OS Install Data image_data 4330 10 image_data_4330-10 /export/image_data/image_data_4330-10
    Base OS Install Data image_data 4330 11 image_data_4330-11 /export/image_data/image_data_4330-11
    Base OS Install Data image_data 4330 09 image_data_4330-09 /export/image_data/image_data_4330-09
    Base OS Install Data image_data 4330 10.5 image_data_4330-10_5 /export/image_data/image_data_4330-10_5
    Base OS Install Data image_data 5100   image_data_5100 /export/image_data/image_data_5100
    Base OS Install Data image_data 5100 02 image_data_5100-02 /export/image_data/image_data_5100-02
    Base OS Install Data image_data 5200   image_data_5200 /export/image_data/image_data_5200
    Base OS Install Data image_data 5200 01 image_data_5200-01 /export/image_data/image_data_5200-01
    Base OS Install Data image_data 5200 02 image_data_5200-02 /export/image_data/image_data_5200-02
    Base OS Install Data image_data 5200 04 image_data_5200-04 /export/image_data/image_data_5200-04
    Base OS Install Data image_data 5200 05 image_data_5200-05 /export/image_data/image_data_5200-05
    Base OS Install Data image_data 5300   image_data_5300 /export/image_data/image_data_5300
    Base OS Install Data image_data 5300 01 image_data_5300-01 /export/image_data/image_data_5300-01

    When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "image_data" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.

  • /export/lpp_source

    Software filesets and updates are identified in the NIM server as an "lpp_source". The top level directory location to be used for storage of these resources will be "/export/lpp_source". The storage location of these resources will be further divided into subdirectories such as "aix", "hacmp", "hitachi", etc.

  • /export/lpp_source/aix

    The "lpp_source" resources stored in the "aix" subdirectory shall be those that are directly related to the AIX operating system. The "lpp_source" resources stored in this directory may consist of a number of different types including the AIX operating system, AIX device drivers, AIX expansion packs, Partition Load Manager, Virtual I/O Server, and others. The following identifiers will be used when defining the lpp_source of this type on the NIM Server and when creating directories to store the lpp_source on the NIM Server:

    • aix: AIX Operating System
    • aixdoc: AIX Documentation
    • dev: AIX Device Drivers
    • exppack: AIX Expansion Pack
    • plm: Partition Load Manager
    • vio: Virtual I/O Server

    Each AIX "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

    The resource identifier (aix, aixdoc, dev, exppack, plm, vio) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    AIX lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    AIX Operating System aix 4330   aix_4330 /export/lpp_source/aix/aix_4330
    AIX Operating System aix 4330 10 aix_4330-10 /export/lpp_source/aix/aix_4330-10
    AIX Operating System aix 4330 11 aix_4330-11 /export/lpp_source/aix/aix_4330-11
    AIX Operating System aix 4330 09 aix_4330-09 /export/lpp_source/aix/aix_4330-09
    AIX Operating System aix 4330 10.5 aix_4330-10_5 /export/lpp_source/aix/aix_4330-10_5
    AIX Operating System aix 5100   aix_5100 /export/lpp_source/aix/aix_5100
    AIX Operating System aix 5100 02 aix_5100-02 /export/lpp_source/aix/aix_5100-02
    AIX Operating System aix 5200   aix_5200 /export/lpp_source/aix/aix_5200
    AIX Operating System aix 5200 01 aix_5200-01 /export/lpp_source/aix/aix_5200-01
    AIX Operating System aix 5200 02 aix_5200-02 /export/lpp_source/aix/aix_5200-02
    AIX Operating System aix 5200 04 aix_5200-04 /export/lpp_source/aix/aix_5200-04
    AIX Operating System aix 5200 05 aix_5200-05 /export/lpp_source/aix/aix_5200-05
    AIX Operating System aix 5300   aix_5300 /export/lpp_source/aix/aix_5300
    AIX Operating System aix 5300 01 aix_5300-01 /export/lpp_source/aix/aix_5300-01
    AIX Documentation aixdoc 5300   aixdoc_5300 /export/lpp_source/aix/aixdoc_5300
    AIX Device Drivers dev 4330   dev_4330 /export/lpp_source/aix/dev_4330
    AIX Device Drivers dev 5100   dev_5100 /export/lpp_source/aix/dev_5100
    AIX Device Drivers dev 5200   dev_5200 /export/lpp_source/aix/dev_5200
    AIX Expansion Pack exppack 5300   exppack_5300 /export/lpp_source/aix/exppack_5300
    Partition Load Manager plm 1100   plm_1100 /export/lpp_source/aix/plm_1100
    Virtual I/O Server vio 1100   vio_1100 /export/lpp_source/aix/vio_1100

  • /export/lpp_source/hacmp

    The "lpp_source" resources stored in the "hacmp" subdirectory shall be those that are directly related to the HACMP Clustering Software, this does NOT include HACMP ES. The "lpp_source" resources stored in this directory will consist of a number of different versions of the HACMP Clustering software.

    Each HACMP "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

    The resource identifier (hacmp) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    HACMP lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    HACMP hacmp 4500   hacmp_4500 /export/lpp_source/hacmp/hacmp_4500

  • /export/lpp_source/hacmpes

    The "lpp_source" resources stored in the "hacmpes" subdirectory shall be those that are directly related to the HACMP ES Clustering Software. The "lpp_source" resources stored in this directory will consist of a number of different versions of the HACMP ES Clustering software.

    Each HACMP ES "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

    The resource identifier (hacmpes) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    HACMP ES lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    HACMP ES hacmpes 4400   hacmpes_4400 /export/lpp_source/hacmpes/hacmpes_4400
    HACMP ES hacmpes 4410   hacmpes_4410 /export/lpp_source/hacmpes/hacmpes_4410
    HACMP ES hacmpes 4410 01 hacmpes_4410-01 /export/lpp_source/hacmpes/hacmpes_4410-01
    HACMP ES hacmpes 4419 hacmpes_4419 /export/lpp_source/hacmpes/hacmpes_4419
    HACMP ES hacmpes 4500 hacmpes_4500 /export/lpp_source/hacmpes/hacmpes_4500
    HACMP ES hacmpes 4507 hacmpes_4507 /export/lpp_source/hacmpes/hacmpes_4507
    HACMP ES hacmpes 5100 hacmpes_5100 /export/lpp_source/hacmpes/hacmpes_5100
    HACMP ES hacmpes 5200 hacmpes_5200 /export/lpp_source/hacmpes/hacmpes_5200
    HACMP ES hacmpes 5200 01 hacmpes_5200-01 /export/lpp_source/hacmpes/hacmpes_5200-01

  • /export/lpp_source/hitachi

    The "lpp_source" resources stored in the "hitachi" subdirectory shall be those that are directly related to the Hitachi SAN Subsystems. The "lpp_source" resources stored in this directory may consist of a number of different types including the AIX ODM software, DLM Drivers, HDLM Drivers, Hitachi's MPIO Drivers, and Hitachi's performance monitoring software. The following identifiers will be used when defining the lpp_source of this type on the NIM Server and when creating directories to store the lpp_source on the NIM Server:

    • aixodm: Hitachi's AIX ODM Software
    • dlm: DLM Drivers
    • hdlm: HDLM Drivers
    • hdsmpio: Hitachi's MPIO Drivers
    • lunstat: Performance Monitoring

    Each Hitachi "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

    The resource identifier (aixodm, dlm, hdlm, hdsmpio, lunstat) followed by an underscore "_", followed by the four(4) digit version number of the resource. The version number of the Hitachi filesets should be taken from the filenames, NOT from the media on which the software was delivered. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    Hitachi lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    AIX ODM Software aixodm 5000   aixodm_5000 /export/lpp_source/hitachi/aixodm_5000
    AIX ODM Software aixodm 5001   aixodm_5001 /export/lpp_source/hitachi/aixodm_5001
    AIX ODM Software aixodm 5002   aixodm_5002 /export/lpp_source/hitachi/aixodm_5002
    AIX ODM Software aixodm 5004   aixodm_5004 /export/lpp_source/hitachi/aixodm_5004
    AIX ODM Software aixodm 5014   aixodm_5014 /export/lpp_source/hitachi/aixodm_5014
    DLM Drivers dlm 2430   dlm_2430 /export/lpp_source/hitachi/dlm_2430
    DLM Drivers dlm 2530   dlm_2530 /export/lpp_source/hitachi/dlm_2530
    HDLM Drivers hdlm 5024   hdlm_5024 /export/lpp_source/hitachi/hdlm_5024
    HDLM Drivers hdlm 5112   hdlm_5112 /export/lpp_source/hitachi/hdlm_5112
    HDLM Drivers hdlm 5231   hdlm_5231 /export/lpp_source/hitachi/hdlm_5231
    HDLM Drivers hdlm 5251   hdlm_5251 /export/lpp_source/hitachi/hdlm_5251
    HDLM Drivers hdlm 5411   hdlm_5411 /export/lpp_source/hitachi/hdlm_5411
    Hitachi MPIO Driver hdsmpio 5400   hdsmpio_5400 /export/lpp_source/hitachi/hdsmpio_5400
    Performance Monitoring lunstat 122   lunstat_122 /export/lpp_source/hitachi/lunstat_122

  • /export/lpp_source/mqseries

    The "lpp_source" resources stored in the "mqseries" subdirectory shall be those that are directly related to the MQ Series software. Each MQ Series "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

    The resource identifier (mq) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    MQ Series lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    MQ Series mq 5300   mq_5300 /export/lpp_source/mqseries/mq_5300

  • /export/lpp_source/performance

    The "lpp_source" resources stored in the "performance" subdirectory shall be those that are related to performance monitoring and management. Each Performance related "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory will depend upon the resource and may deviate from those identified in this document. The resource identifiers shall have the following specific format:

    The resource identifier (perfaide, perftoolbox, etc) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    Performance related lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    Performance perfaide 3100   perfaide_3100 /export/lpp_source/performance/perfaide_3100
    Performance perftoolbox 3100   perftoolbox_3100 /export/lpp_source/performance/perftoolbox_3100

  • /export/lpp_source/tsm

    The "lpp_source" resources stored in the "tsm" subdirectory shall be those that are directly related to the Tivoli Storage Manager(TSM). The "lpp_source" resources stored in this directory will consist of a number of different versions of the TSM software.

    Each TSM "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

    The resource identifier (tsmclient,tsmserver) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    Tivoli Storage Manager related lpp_source Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    TSM tsmclient 42125   tsmclient_42125 /export/lpp_source/tsm/tsmclient_42125
    TSM tsmclient 4221   tsmclient_4221 /export/lpp_source/tsm/tsmclient_4221
    TSM tsmclient 5162   tsmclient_5162 /export/lpp_source/tsm/tsmclient_5162

  • /export/mksysb

    The "mksysb" resource class is for AIX mksysb backups of the "rootvg" volume group. "mksysb" resources can be used by the NIM server to perform a new installation or restore a machine to a known state. The "mksysb" images are specific to an individual machine at a particular point in time.

    Each "mksysb" resource shall be stored under the "/export/mksysb" subdirectory. The name of the resource shall have the following specific format:

    The resource identifier (mksysb) followed by an underscore "_", followed by the machine name from which the "mksysb" image was generated. If multiple versions are desired, follow the machine name with an underscore "_", followed by the 4 digit year, 2 digit month number, 2 digit day of the month, 2 digit hour of the day, 2 digit minute of the hour, and 2 digit seconds. If this level of granularity is not required, the date/time identifer can be truncated as necessary, but should remain in the stated sequence and format.

    mksysb Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Originating
    Machine     		Date/Time
    Stamp     		NIM
    Resource Name     		Storage
    Location
    Backup mksysb mx1aaega01   mksysb_mx1aaega01 /export/mksysb/mksysb_mx1aaega01
    Backup mksysb mx1aaega02   mksysb_mx1aaega02 /export/mksysb/mksysb_mx1aaega02
    Backup mksysb mx1pocdb01   mksysb_mx1pocdb01 /export/mksysb/mksysb_mx1pocdb01
    Backup mksysb mx0iaapp80 20050412 mksysb_mx0iaapp80_20050412 /export/mksysb/mksysb_mx0iaapp80_20050412
    Backup mksysb mx0iaapp80 20050414 mksysb_mx0iaapp80_20050414 /export/mksysb/mksysb_mx0iaapp80_20050414

  • /export/resolv_conf

    The "resolv_conf" resource class is the configuration file for the Domain Name Server (DNS) information. A instance of this class shall be defined for each data center and may contain DNS information for multiple data centers. Example instances of the "resolv_conf" resource class and file follow:

    resolv_conf Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Datacenter
    ID     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    DNS Resolution resolv_conf Default   resolv_conf /export/resolv_conf/resolv_conf
    DNS Resolution resolv_conf mx1   resolv_conf_mx1 /export/resolv_conf/resolv_conf_mx1
    DNS Resolution resolv_conf mx0   resolv_conf_mx0 /export/resolv_conf/resolv_conf_mx0

    When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "resolv_conf" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.

  • /export/spot

    The "spot" resource class is for the bootable images to use for network booting a machine and OS installation. Each "spot" image is specific to a particular version and maintenance level of AIX or other operating system and shall be identified accordingly. The resource identifier for the AIX "spot" images is "aixspot". The reason "aixspot" is used for this identifier instead of just "spot" is because Linux spots are also be included in this resource class and are identified by the brand of Linux such as "susespot", "redhatspot", "debianspot", etc. These resource identifiers shall be be used to identify each instance as follows:

    The resource identifier (aixspot) followed by an underscore "_", followed by the four(4) digit version number of the AIX OS resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

    Spot Resource Names and Subdirectories
    Resource
    Type     		Resource
    Identifier     		Version
    Number     		Maintenance
    Level     		NIM
    Resource Name     		Storage
    Location
    AIX Spot aixspot 4330   aixspot_4330 /export/spot/aixspot_4330
    AIX Spot aixspot 5100   aixspot_5100 /export/spot/aixspot_5100
    AIX Spot aixspot 5200   aixspot_5200 /export/spot/aixspot_5200
    AIX Spot aixspot 5200 02 aixspot_5200-02 /export/spot/aixspot_5200-02
    AIX Spot aixspot 5200 05 aixspot_5200-05 /export/spot/aixspot_5200-05
    AIX Spot aixspot 5300   aixspot_5300 /export/spot/aixspot_5300
    Suse Spot slesspot 9000   slesspot_9000 /export/spot/slesspot_9000

    • Table of Contents

    Resource Group

    Resource Group Name Standards

    The concept of Resource Group is used here in a larger scope than it is used in HACMP. In MtXia's environment, a resource group is any logical collection of resources, this may include disk, I/O, users, applications, etc. A resource group should be viewed as being independent from any machine or data center. The resource group name is used as the basis of all other naming structures for all entities whether or not they are controlled by HACMP. The resource group name shall be an enterprise wide unique value in order to eliminate conflicts during manual, automated, or disaster recovery failovers.

    When designing any new system, the first step is to determine the resource group name(s). The names of volume groups, logical volumes, mount points, major numbers, WLM classes, etc, are all derived from the resource group name(s).

    The resource group name shall consist of exactly 8 characters with the following structure:

    ApplicationCode + Environment + Function + Company + Sequence ID
     3 char     +    1 char   +  1 char  +  2 char +   1 char

    The detailed information for each component of the resource group name is described below:

    RG Name
    Component     		Number of
    Characters     		Values
    Application Code 3 
    atl = Atlas
ega = EGATE
nim = NIM
ora = Oracle
tps = Maximo
vio = Virtual I/O
    Environment 1 
    a = acceptance
a = pre-production
d = test/development
p = production
t = test
x = disaster recovery
x = pre-production
    Function 1 
    a = application
c = combination/multi-purpose
d = database
m = management
u = utility
    Company 2 
    cg = Mt Xia
ce = Mt Xia Energy
tu = Mt Xia
tw = Time Warner
    Sequence ID 1 
    0-9,A-Z,a-z

    Examples of Resource Group (RG) names:

  • egapdtu0
    EGATE Production database RG for Mt Xia, first instance

  • egapdtu1
    EGATE Production database RG for Mt Xia, second instance

  • nimpuce0
    Network Information Manager production utility RG for MtXia, first instance

  • nimpuce1
    Network Information Manager production utility RG for MtXia, second instance

  • viopuce1
    Virtual I/O production utility RG for MtXia, first instance

  • viopuce2
    Virtual I/O production utility RG for MtXia, second instance

  • viopuce3
    Virtual I/O production utility RG for MtXia, third instance

  • viopuce4
    Virtual I/O production utility RG for MtXia, fourth instance

  • vioauce1
    Virtual I/O acceptance utility RG for MtXia, first instance

  • vioauce2
    Virtual I/O acceptance utility RG for MtXia, second instance

  • vioauce3
    Virtual I/O acceptance utility RG for MtXia, third instance

  • vioauce4
    Virtual I/O acceptance utility RG for MtXia, fourth instance

  • tpspdtu0
    Maximo production database RG for Mt Xia, first instance

  • tpspdtu1
    Maximo production database RG for Mt Xia, second instance

    • Table of Contents

    WLM AIX 433

    Workload Manager for AIX 4.3.3.0 Standards

    This document describes the Workload Manager implementation standards on AIX 4.3.3.0 machines only.

    For WLM implementation on AIX version 5 systems, see the AIX 5 WLM standards document.

    The workload manager (WLM) shall be implemented on all AIX systems. On most systems WLM will be running in "passive" mode, which does not limit resources. In MtXia's environment, only a few selected systems will have WLM implemented in "active" mode to control and regulate resources. If there is any question as to whether WLM should be implemented in "active" or "passive" mode, default to "passive".

    The WLM provides a mechanism to classify and segment resources by process, user, group, etc. The classification scheme must be constructed by the AIX system administrator. This WLM classification scheme in the MtXia environment is based on the concept of the Resource Group. Each Resource Group will be represented in WLM as a class. Multiple instances of an application within a single resource group shall be represented in WLM as subclasses.

    In order to configure WLM, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a WLM class must be defined using the resource group name as the WLM class name.

    To define a new WLM class using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Add a class" to define a new WLM class.

                                  Workload Management

Move cursor to desired item and press Enter.

  List all Classes
  Add a Class
  Change / Show Characteristics of a Class
  Remove a Class
  Class Assignment Rules
  Start/Stop/Update WLM

    Enter the resource group name as the WLM class name, and provide a description of this WLM class. The Tier level will normally be 0 (zero) unless there is a specific reason to change this. The CPU and Memory values will be defaulted to a minumum of 0% and a maximum value of 100%.

                                      Add a Class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
  Class name                                         [atladtu1]
  Description                                        [Atlas pre-prod Database for Mt Xia, instance 1]
  Tier                                               [0]
  Minimum CPU time (%)                               [0]
  Maximum CPU time (%)                               [100]
  Shares of CPU                                      [1]
  Minimum Memory (%)                                 [0]
  Maximum Memory (%)                                 [100]
  Shares of Memory                                   [1]

    Class rules are used to determine which processes are assigned to which WLM classes and the order of the rules is significant. The first rule that matches is used to determine the WLM class assignment, so the class rules should be ordered from highly specific to less specific.

    To define WLM class rules using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Class assignment rules" to define a new WLM class.

                                  Workload Management

Move cursor to desired item and press Enter.

  List all Classes
  Add a Class
  Change / Show Characteristics of a Class
  Remove a Class
  Class Assignment Rules
  Start/Stop/Update WLM

    Select "Class assignment rules" to define a new WLM class rule.

                                 Class Assignment Rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule

    In the following example, a rule is defined to assign all processes owned by oracl817 to the the WLM class "atladtu1". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                                   Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the Rule                                  [1]
* Class                                              [atladtu1]
  User                                               [oracl817]
  Group                                              [-]
  Application                                        [-]

    Under AIX 4.3.3.0, to start WLM in passive mode, it must be done from the command line. If WLM is started from "smitty", it will be started in "active" mode. So to be safe and exact, always start/stop WLM from the command line using the appropriate flags.

    To start WLM from the command line in "passive" mode: 

    wlmcntrl -p

    To start WLM from the command line in "active" mode: 

    wlmcntrl -a

    To stop WLM from the command: 

    wlmcntrl -o

    Any changes to the WLM configuration will require that WLM be stopped and restarted in order for the changes to take effect.

    An example WLM configuration of the Atlas pre-production Database server for Mt Xia follows. The "standard" WLM configuration for this machine contains five WLM classes. It is important to recognize that the "standard" WLM configuration will be different for every machine. The term "standard" is used in reference to the local machine, this is not enterprise wide terminology used here.

    The AIX 4.3.3.0 WLM does not support the concept of subclasses, therefore multiple instances of an application will likely be configured as multiple WLM classes, requiring multiple resource groups. Since the AIX 4.3.3.0 WLM does not support subclasses, the WLM configuration will be different between AIX 4.3.3.0 and AIX 5.X systems.

  • mx1adatl01:/etc/wlm/standard/classes 
    System:

Default:

atladtu1:
        description = "Atlas pre-prod Database for Mt Xia, AMST instance"

atladtu2:
        description = "Atlas pre-prod Database for Mt Xia, C2KR instance"

atladtu3:
        description = "Atlas pre-prod Database for Mt Xia, ATLP instance"

    • The class rules associated with this "standard" configuration assign processes to multiple classes depending upon the user id. Rules are defined to segment the processes owned by the three oracle instances into separate WLM classes. All processes owned by "root" are assigned to the class "System", and all other processes are assigned to the class "Default".

  • mx1adatl01:/etc/wlm/standard/rules 
    * class   resvd  user      group  application
atladtu1  -      oracl817  -      -
atladtu2  -      oracle8i  -      -
atladtu3  -      oracle    -      -
System    -      root      -      -
Default   -      -         -      -

    • Table of Contents

    WLM AIX 5

    Workload Manager for AIX 5L Standards

    This document describes the Workload Manager implementation standards on AIX version 5 machines only.

    For WLM implementation on AIX version 4.3.3.0 systems, see the AIX 4.3.3.0 WLM standards document.

    The workload manager (WLM) shall be implemented on all AIX systems. On most systems WLM will be running in "passive" mode, which does not limit resources. In MtXia's environment, only a few selected systems will have WLM implemented in "active" mode to control and regulate resources. If there is any question as to whether WLM should be implemented in "active" or "passive" mode, default to "passive".

    The WLM provides a mechanism to classify and segment resources by process, user, group, etc. The classification scheme must be constructed by the AIX system administrator. This WLM classification scheme in the MtXia environment is based on the concept of the Resource Group. Each Resource Group will be represented in WLM as a class. Multiple instances of an application within a single resource group shall be represented in WLM as subclasses.

    In order to configure WLM, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a WLM class must be defined using the resource group name as the WLM class name.

    To define a new WLM class using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Add a class" to define a new WLM class.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Enter the resource group name as the WLM class name, and provide a description of this WLM class. The Tier level will normally be 0 (zero) unless there is a specific reason to change this. The "Resource Set Inheritance" value will normally be set to "Yes".

    The user and group values will be dependent upon the nature of the resource group. It may be desirable to specify a non-root user and group that is permitted to administer the WLM class and/or assign processes to the class. This will have to be determined on a resource group by resource group basis. If this information is unknown, default to "root" for the user values and "system" for the group values.

    
                       General characteristics of a class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                         [Entry Fields]
* Class name                                             [egapdtu1]
  Description                                            [EGATE Production Database for Mt Xia, Instance 0]
  Tier                                                   [0]
  Resource Set                                          
  Inheritance                                            [Yes]
  User authorized to assign its processes to this class  [oracle]
  Group authorized to assign its processes to this class [dba]
  User authorized to administrate this class             [root]
  (Superclass only) 
  Group authorized to administrate this class            [system]
  (Superclass only)
  Localshm                                               [No]

    Class rules are used to determine which processes are assigned to which WLM classes and the order of the rules is significant. The first rule that matches is used to determine the WLM class assignment, so the class rules should be ordered from highly specific to less specific.

    To define WLM class rules using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Class assignment rules" to define a new WLM class.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select "Class assignment rules" to define a new WLM class rule.

                                 Class assignment rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule 
  Attribute value groupings

    In the following example, a rule is defined to assign all processes owned by oracle or the group dba to the the WLM class "egapdtu1". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                                   Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the rule                                  [1]
* Class name                                          [egapdtu1
* User                                               [oracle]
* Group                                              [dba]
  Application                                        [-]
  Type                                               [-]
  Tag                                                [-]

    To define a new WLM subclass using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Add a class" to define a new WLM subclass.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    When defining a subclass, again enter the resource group name, followed by a period (.) followed by the name of the subclass to create. The Tier level will normally be 1 (one) for a subclass, unless there is a specific reason to change this. The "Resource Set Inheritance" value will normally be set to "Yes".

    The user and group values will be dependent upon the nature of the resource group. It may be desirable to specify a non-root user and group that is permitted to administer the WLM class and/or assign processes to the class. This will have to be determined on a resource group by resource group basis. If this information is unknown, default to "root" for the user values and "system" for the group values.

    
                       General characteristics of a class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                         [Entry Fields]
* Class name                                             [egapdtu1.oracleex511]
  Description                                            [EGATE Production Database for Mt Xia, Instance 511]
  Tier                                                   [1]
  Resource Set                                          
  Inheritance                                            [Yes]
  User authorized to assign its processes to this class  [oracle]
  Group authorized to assign its processes to this class [dba]
  User authorized to administrate this class             [root]
  (Superclass only) 
  Group authorized to administrate this class            [system]
  (Superclass only)
  Localshm                                               [No]

    To define a class rule for a subclass requires an additional step. First select a set of WLM subclasses to work on, then define the rule. To define a rule for a WLM subclass using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Work on a set of Subclasses" to select the subclass for which to define a rule.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets

  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)

  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select the WLM class that contains the subclass for which the rule will be defined, press enter, then return to the main WLM menu.

                                Select a Superclass or -

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Superclass name                                    [egapdtu1]

    Select "Class assignment rules" to define a new WLM subclass rule.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select "Class assignment rules" to define a new WLM subclass rule.

                                 Class assignment rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule 
  Attribute value groupings

    In the following example, a rule is defined to assign all processes owned by oracle or the group dba to the the WLM subclass "egapdtu1.oracleex511". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                                   Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the rule                                  [1]
* Class name                                          oracleex511
* User                                               [oracle]
* Group                                              [dba]
  Application                                        [-]
  Type                                               [-]
  Tag                                                [-]

    After all classes, subclasses, and rules have been defined, start WLM.

    smitty wlm

    Select "Work on a set of Subclasses" to select the subclass for which to define a rule.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets

  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)

  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select "Start Workload Manager"

                                 Start/Stop/Update WLM

Move cursor to desired item and press Enter.

  Start Workload Manager
  Update Workload Manager
  Stop Workload Manager
  Show WLM status

    For the options on this page, select the "current" configuration set, choose the "Passive" management mode, and choose "Both" for the start option. 

                                 Start Workload Manager

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Configuration, or for a set: set name/currently     current
      applicable configuration
  Management mode                                     Passive
  Enforce Resource Set bindings                       Yes
  Disable class total limits on resource usage        Yes
  Disable process total limits on resource usage      Yes
  Start now, at next boot, or both ?                  Both

    Any subsequent changes to the WLM configuration will require that WLM be stopped and restarted in order for the changes to take effect.

    An example WLM configuration of the EGATE Production Database server for Mt Xia follows. The "standard" WLM configuration for this machine contains a single WLM class called "egapdtu1". It is important to recognize that the "standard" WLM configuration will be different for every machine. The term "standard" is used in reference to the local machine, this is not enterprise wide terminology used here.

  • mx0apega01:/etc/wlm/standard/classes 
    System:

Default:

Shared:

egapdtu1:
        description = "Oracle Concurrent"
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"
        adminuser = "root"
        admingroup = "system"

    • The class rules associated with this "standard" configuration assign any processes owned by "oracle" or by the group "dba" to the WLM class "egapdtu1". All processes owned by "root" are assigned to the class "System", and all other processes are assigned to the class "Default".

  • mx0apega01:/etc/wlm/standard/rules 
    *class    resvd   user    group   application     type    tag
egapdtu1  -       oracle  dba     -               -       -       
System    -       root    -       -               -       -       
Default   -       -       -       -               -       -

    • Multiple subclasses are defined for the class "egapdtu1". These subclasses are intended to segment the processes by oracle instance. The definition of subclasses will be customized for each individual resource group.

  • mx0apega01:/etc/wlm/standard/egapdtu1/classes 
    Default:

Shared:

oracleex011:
        description = "Instance ex011"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex061:
        description = "Instance ex061"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex071:
        description = "Instance ex071"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleexa11:
        description = "Instance a11"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex031:
        description = "Instance ex031"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex041:
        description = "Instance ex041"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex051:
        description = "Instance ex051"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

    • The rules associated with each subclass of the class "egapdtu1" associate all processes owned by "oracle" or the group "dba" to the subclass. In this instance the processes are not automatically assigned to subclasses by WLM, instead they are assigned by the oracle startup script.

  • mx0apega01:/etc/wlm/standard/egapdtu1/rules 
    *class          resvd   user    group   application     type    tag
oracleex011     -       oracle  -       -               -       -       
oracleex031     -       oracle  -       -               -       -       
oracleex041     -       oracle  -       -               -       -       
oracleex051     -       oracle  -       -               -       -       
oracleex061     -       oracle  -       -               -       -       
oracleex071     -       oracle  -       -               -       -       
oracleexa11     -       oracle  -       -               -       -

    • Table of Contents

    VG Name

    Volume Group Name Standards

    This document describes the standards for assigning AIX Volume Group (VG) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This VG naming standard provides the mechanism to assign enterprise wide unique names to all AIX VG's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    To assign enterprise wide unique VG names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a VG name may be defined based on the resource group name.

    A single system may contain multiple resource groups, and typically there will be one VG defined per resource group. However, a resource group may contain several VG's, depending upon the requirements of the application.

    To define a VG name, obtain the 8 character resource group name, then add a 2 digit volume group sequence number that will uniquely identify the VG, followed by the characters "vg". The VG name will always end with the characters "vg".

    The VG name shall consist of exactly 12 characters with the following structure:

    ApplicationCode + Environment + Function + Company + Sequence ID + VG Sequence ID + "vg"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    +      2 char    + 2 char

    As an example, a resource group named "egaaptu0", may have multiple associated VG's:

    RG Name
    Component     		VG Sequence
    Identifier     		LV Identifier VG Name
    egaaptu0 00 vg egaaptu000vg
    egaaptu0 01 vg egaaptu001vg
    egaaptu0 02 vg egaaptu002vg

    Each VG also requires a system or cluster wide unique Major Number. A unique major number can be generated using the following algorithm:

    MajorNbr=$( print "${VGNAME}" | sum -o | awk '{ print $1 }' )

    To reiterate, before creating a VG, first establish an enterprise wide unique resource group name, a VG name, and a major number. Then create the VG.

    Table of Contents

    LV Name

    Logical Volume Name Standards

    This document describes the standards for assigning AIX Logical Volume (LV) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This LV naming standard provides the mechanism to assign enterprise wide unique names to all AIX LV's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    To assign enterprise wide unique LV names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a Volume Group (VG) must be defined based on the RG name. After the VG has been created, LV's can be assigned. A VG will typically contain several LV's, and each LV will be named based on the resource group to which it is associated.

    To define a LV name, obtain the 8 character resource group name, then add a 4 digit logical volume sequence identifier that will uniquely identify the LV, followed by the characters "lv". The 4 digit LV sequence identifier will consist of alpha-numeric characters and must always be exactly 4 characters in length. The LV name will always end with the characters "lv".

    The LV name shall consist of exactly 14 characters with the following structure:

    ApplicationCode + Environment + Function + Company + Sequence ID + LV Sequence ID + "lv"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    +      4 char    + 2 char

    As an example, a resource group named "egaaptu0", may have a volume group named "egaaptu00vg". This volume group may have multiple LV's associated with it:

    RG Name
    Component     		LV Sequence
    Identifier     		LV Identifier LV Name
    egaaptu0 db20 lv egaaptu0db20lv
    egaaptu0 db21 lv egaaptu0db21lv
    egaaptu0 db22 lv egaaptu0db22lv

    JFS filesystems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

    JFS Log Logical Volume Name Standards

    The following is a description of the standards for assigning AIX JFS Log Logical Volume (JFS Log LV) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This JFS Log LV naming standard provides the mechanism to assign enterprise wide unique names to all AIX JFS Log LV's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    To assign enterprise wide unique JFS Log LV names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a Volume Group (VG) must be defined based on the RG name. After the VG has been created, JFS Log LV's can be assigned. A VG will typically contain one JFS Log LV's, however multiple JFS Log LV's can exist.

    To define a JFS Log LV name, obtain the 8 character resource group name, then add the 4 digit logical volume sequence identifier that will uniquely identify the JFS Log LV, followed by the characters "lv". The 4 digit JFS Log LV sequence identifier will consist of the characters "jfs" followed by a single digit to uniquely identify the JFS Log LV. The JFS Log LV name will always end with the characters "lv".

    The JFS Log LV name shall consist of exactly 14 characters with the following structure:

    ApplicationCode + Environment + Function + Company + Sequence ID +  "jfs" + JFS Log Sequence ID + "lv"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    + 3 char +       1 char        + 2 char

    As an example, a resource group named "egaaptu0", may have a volume group named "egaaptu00vg". This volume group may have multiple JFS Log LV's associated with it:

    RG Name
    Component     		JFS Log LV
    Sequence ID     		JFS Log
    LV ID     		JFS Log
    LV Name
    egaaptu0 jfs0 lv egaaptu0jfs0lv
    egaaptu0 jfs1 lv egaaptu0jfs1lv
    egaaptu0 jfs2 lv egaaptu0jfs2lv

    JFS filesystems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

    Table of Contents

    JFS Logs

    JFS Log Logical Volume Name Standards

    The following is a description of the standards for assigning AIX JFS Log Logical Volume (JFS Log LV) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This JFS Log LV naming standard provides the mechanism to assign enterprise wide unique names to all AIX JFS Log LV's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    To assign enterprise wide unique JFS Log LV names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a Volume Group (VG) must be defined based on the RG name. After the VG has been created, JFS Log LV's can be assigned. A VG will typically contain one JFS Log LV's, however multiple JFS Log LV's can exist.

    To define a JFS Log LV name, obtain the 8 character resource group name, then add the 4 digit logical volume sequence identifier that will uniquely identify the JFS Log LV, followed by the characters "lv". The 4 digit JFS Log LV sequence identifier will consist of the characters "jfs" followed by a single digit to uniquely identify the JFS Log LV. The JFS Log LV name will always end with the characters "lv".

    The JFS Log LV name shall consist of exactly 14 characters with the following structure:

    ApplicationCode + Environment + Function + Company + Sequence ID +  "jfs" + JFS Log Sequence ID + "lv"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    + 3 char +       1 char        + 2 char

    As an example, a resource group named "egaaptu0", may have a volume group named "egaaptu00vg". This volume group may have multiple JFS Log LV's associated with it:

    RG Name
    Component     		JFS Log LV
    Sequence ID     		JFS Log
    LV ID     		JFS Log
    LV Name
    egaaptu0 jfs0 lv egaaptu0jfs0lv
    egaaptu0 jfs1 lv egaaptu0jfs1lv
    egaaptu0 jfs2 lv egaaptu0jfs2lv

    JFS filesystems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

    Table of Contents

    FS Mt Point

    File System Mount Point Directory Name Standards

    This document describes the standards for assigning AIX filesystem mount point (MtPt) directory names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This filesystem mount point directory naming standard provides the mechanism to assign enterprise wide unique names to all AIX filesystem mount point directory's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    To assign enterprise wide unique LV names, the system administrator must first define the Resource Groups, Volume Groups, and Logical Volumes. Once these have been defined, the filesystem mount point directory names can be assigned. Typically a filesystem mount point is required for each logical volume, therefore the mount point can usually be based on the logical volume name, or at a minimum the resource group name.

    To define a filesystem mount point directory name, obtain the 8 character resource group name, then depending upon the applications filesystem requirements, use the RG name as the mount point, or add sub-directories to make it enterprise wide unique.

    The filesystem mount point directory name shall consist of at least 8 characters, but may be of a variable length:

    / + ApplicationCode + Environment + Function + Company + Sequence ID + ( LV Sequence ID or Directory Structure )
         3 char     +    1 char   +  1 char  +  2 char +   1 char    +      4 or more char

    As an example, a resource group named "egaaptu0", may have multiple file systems associated with it:

    RG Name
    Component     		Optional
    Logical Volume
    Sequence ID     		Optional
    Sub-Directories     		Filesystem Mount Point
    egaaptu0   db2_08_01/bin /egaaptu0/db2_08_01/bin
    egaaptu0   db2_08_01/data /egaaptu0/db2_08_01/data
    egaaptu1 mq01   /egaaptu1mq01
    egaaptu1 mq02   /egaaptu1mq02
    egaaptu1 mq03   /egaaptu1mq03

    Table of Contents

    User/UID

    User Name Standards

    This document describes the standards for assigning user names and UID numbers in MtXia's AIX environment. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This user naming standard provides the mechanism to assign enterprise wide unique user names to all AIX users's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    Users are normally divided into two major categories on a Unix system, administrators and normal users. Applications such as databases, SAP, MQSeries, etc normally require an administration user name and possibly a group name. With each new user created on a Unix system a user ID number is assigned to that user, this user ID number is referred to as the UID number and is normally unique to that user on that one Unix system. When building highly available and/or recoverable systems, the user name and UID number must be enterprise wide unique values. Therefore a centralized user management system must be implemented to manage users and UID numbers to ensure that no two users have the same user name or UID number.

    This centralized user management function is performed in MtXia's environment by LDAP. All user requests and assignments must be performed through the centralized user management system via the LDAP servers.

    Table of Contents

    Group/GID

    Group Name Standards

    This document describes the standards for assigning group names and GID numbers in MtXia's AIX environment. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This group naming standard provides the mechanism to assign enterprise wide unique group names to all AIX groups's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

    Groups are normally divided into two major categories on a Unix system, administration and normal user groups. Applications such as databases, SAP, MQSeries, etc may require an administration group. With each new group created on a Unix system a group ID number is assigned to that group, this group ID number is referred to as the GID number and is normally unique to that group on that one Unix system. When building highly available and/or recoverable systems, the group name and GID number must be enterprise wide unique values. Therefore a centralized group management system must be implemented to manage groups and GID numbers to ensure that no two groups have the same group name or UID number.

    This centralized group management function is performed in MtXia's environment by LDAP. All group requests and assignments must be performed through the centralized group management system via the LDAP servers.

    Table of Contents

    Security (DRAFT)

    Security Standards

    1 General Security Design

    1.1 Environment

    1.1.1

    The root user's PATH variable does not include the Current Working Directory or its parent.

    If the root user's PATH includes '.' or '..', the user is vulnerable to trojan horse attacks residing in the user's current working directory or its parent.

    The default path for the root user does not include any directories which are writable by other users.

    1.1.2

    Any user's PATH variable does not include the Current Working Directory unless it's the last entry in the PATH; any specific $HOME directories must be after the standard system directories and before the current directories in a user's PATH variable.

    If a user's PATH includes '.' or '..', the user is vulnerable to trojan horse attacks residing in the user's current working directory or its parent.

    The default path for any user should not include any directories which are writable by themselves or other users until checking for system supported commands first.

    1.2 Network Services

    1.2.1

    Insecure Sendmail configuration options such as WIZ, VRFY, EXPN and DEBUG are not used.

    Several of the Sendmail commands present serious security risks. For instance, the WIZ command allows anyone who knows the "Wizard" password to log into the system, gaining command line access. VRFY and EXPN ("verify" and "expand" respectively) allow anyone to query the Sendmail server as to the names of valid accounts on the system. DEBUG allows an outsider to put Sendmail in "debug" mode and execute commands on the system.

    A mail program such as smap should be used. Smap eliminates most of the security weaknesses associated with sendmail.

    1.2.2

    The Sendmail daemon is only used if an approved business justification exists.

    The Sendmail program is the mail system's routing program. The UNIX program /usr/lib/sendmail implements both the client and the server side of the mail program. Sendmail has been the source of numerous security breaches on UNIX systems. Security vulnerabilities have been found in all versions of Sendmail, up to and including Sendmail version 8.11.2 This is the latest version of Sendmail ' see www.sendmail.com

    On AIX, sendmail is started by the Run Control (rc) scripts. Locate the entry for sendmail and comment it out.

     

    In order for the changes to take effect, one must either reboot or kill the currently running sendmail process.

    1.2.3

    The sendmail.cf file allows only a minimal list of "trusted users."

    The /etc/sendmail.cf file contains configuration information necessary for sendmail to run, include options which can create security vulnerabilities in the mail system. The T configuration command identifies the "trusted users" who can override a sender's name in a mail message by using the -f option with one of their own. Trusted users are necessary for certain kinds of mail to flow properly, but other trust relationships can be added which introduce security vulnerabilities.

    Remove any T sendmail.cf directives not listing uucp, root or daemon.

    1.2.4

    DNS is configured to disallow unauthorized zone transfers.

    Zone transfers can be used by intruders to rapidly obtain a complete map of an organization's servers. Such information is commonly used by intruders to facilitate target scanning and selection during break-in attempts.

    DNS is configured to prevent unauthorized zone transfers as well as log unauthorized zone transfer attempts.

    1.2.5

    If the WAN architecture allows access from insecure networks such as the Internet, the server's network services are either disabled or implemented in a manner which appropriately minimizes the risk of intrusion from the insecure networks.

    Many network services are unnecessary and may pose a security risk if enabled on servers accessable via the Internet or high risk WAN segments.

    Only network services which are necessary for business operations are active.

    1.2.6

    The latest available version of BIND is installed on the system

    Earlier versions of UNIX BIND contained security problems which might allow an attacker to gain access to the system

    The latest available version of BIND should be installed. Currently (01/17/2001/19/2000), the latest version is BIND 9.1. You can find this information at www.isc.org.

    1.2.7

     

    The Sendmail Aliases file is configured securely.

    An incorrectly configured /etc/aliases file may allow unauthorized access to the system.

    1) The aliases file must be owned by root and protected mode 644. Use the following command to check the file permissions:

     

    ls -l /etc/aliases

     

    They should read:

     

    "-rw-r--r--"

     

    If permissions are incorrect, change them using the following command:

     

    chmod 644 /etc/aliases

     

    2) Review the entries in the aliases file, using vi /etc/aliases, and comment out any undesirable entries (using a text editor, place a comment "#" marker at the front of the line in question). In particular:

     

    a) Remove the decode alias, which might appear in the alias file as follows:

    decode: |/usr/bin/guudecode

    b) Review for any other entries which execute a program. Remove if not necessary.

     

    If NIS is used, run /usr/sbin/newaliases after changing the aliases file in order to rebuild the maps.

    1.2.8

    The Sendmail mail queue file is configured securely, with the minimum permissions necessary for operation.

    Access to the mail queue can allow users to read other users mail, gaining sensitive information or to overwrite mail messages.

    Check the mail queue's permissions, by:

     

    ls -l /var/spool/mqueue/mqueue

     

    Since only the owner, root, should have access, the permissions should look like:

    -rwx------

     

     

    If permissions are not correct, change them by:

     

    chmod 700 /usr/spool/mqueue/mqueue

    1.2.9

    The sendmail.cf file has secure file permissions.

    If the Sendmail configuration file has improper file permissions (e.g., world writeable) there is an increased risk than an unauthorized user may gain privileged access to the system or cause a disruption of service.

    The sendmail.cf file should be secured with appropriate file permissions. The /etc/sendmail.cf file must be writable only by root with permission mode 640 or 660.

    1.2.10

    Sendmail is implemented in a secure manner, including immediate installation of the latest security patches as they become available.

    Sendmail (a mail routing daemon) has been the source of numerous security breaches on UNIX systems. Security vulnerabilities have been found in all versions of Sendmail, up to and including Sendmail version 8.8.11.2 (Sendmail is currently on version 8.11.2 as of 12/29/2000 . You can find this information at www.sendmail.com.

    Check www.ers.ibm.com for the latest patches; follow site instructions to install patch. Subscribe to the IBM ERS service to keep abreast of latest patches to install, as well as the CERT (www.cert.org) and Bugtraq (www.netspace.org) mailing lists for breaking news regarding Sendmail (and other) security vulnerabilities. In addition, the latest information on sendmail can be found at www.sendmail.org.

     

    Evaluate the need to run sendmail, and disable if the service is not used. If sendmail is necessary, conisder using a more secure version (e.g, Qmail) or a sendmail wrapper (smrsh, SMAP / SMAPD).

    1.2.11

    Unnecessary RPC services are disabled.

    RPC services provide unauthenticated or weakly authenticated access to systems to remotely execute commands (Remote Procedure Calls) for distributed computing. RPC is used for services such as NFS, but can be a significant vulnerability source.

    Where RPC is necessary, secure versions of RPC which implement strong authentication and encryption are used.

    1.2.12

    Protect against an account name/password guessing attack

    Parameters in the /etc/security/login.cfg file can be set by port to delay or prohibit additional logins after a failed login.

    Consider setting the parameters appropriately to protect against a guessing attack on sensitive ports (i.e. a modem port).

    Examine failed logins using

    /usr/bin/who `-s` `/etc/security/failedlogin`

    1.2.13

    The organizational structure of the IS and security groups provides for adequate UNIX security.

    I think you wanted to say IS personnel resources are insufficient to allow for the time and effort needed to address security issues, security needs are generally assigned a very low priority.

    Sufficient lets either use IS or MIS not both when talking about the same function.MIS resources should be devoted to security. Job descriptions of system, network and database administrators should include security related tasks.

    1.3 Network Information Services (NIS/NIS+)

    1.3.1

    (If NIS is used) a current (i.e., patched) version of NIS is implemented for enterprise wide user authentication.

    NIS offer a robust set of administration options that organizations can use centrally manage access to system resources. However, there are many options that need to be configured correctly to provide security over the NIS environment. Moreover, many security related vulnerabilities have been associated with NIS. Thus, if NIS is not properly configured and patched, there is an increased risk an unauthorized user could gain privileged access to system resources.

    Contact your vendor for the most up-to-date patches for NIS/NIS+.

     

    To check for active NIS, use:

    isypset=`domainname | /bin/grep '^[a-zA-Z]'

    If active, to check the NIS domainname, use:

    /usr/bin/domainname

     

    1.3.2

    If NIS is used, it only provides users with access to those systems they have a business need to access.

    Users with domain-wide access may have privileges which go beyond their job responsibilities, including unauthorized access to sensitive files.

    Limited access via NIS can be accomplished by creating one or more designated login shells on each machine.

     

    For instance, the server sales may contain the login shells /usr/local/salessh and /usr/local/salesapp, the former being a copy of /bin/sh and the latter being a shell which launches an application on this server.

     

    Most users will now have the NIS entry /usr/local/salesapp, while users requiring shell access to the server will have the NIS entry /usr/local/salessh. These users can now be administered on a domain-wide basis, but their login access is limited to the server sales.

     

    Note also that the .login/.cshrc/.profile files can play a role in controlling NIS access.

    1.3.3

    NIS configuration files have secure file permissions.

    World-writable NIS configuration files could make it possible for an attacker to change NIS information, including adding privileged accounts.

    NIS configuration files have restrictive permissions. In particular, the passwd.adjunct file is not accessible by users other than root.

     

    The umask value for the root user is set to 077 to ensure that files are created with secure default permissions.

    1.3.4

    NIS Master servers do not use NIS for password information.

    Since NIS master servers are key to NIS security, and thus a point of compromise for the entire network, such systems should have extra security protections

    NIS master servers use only local account information for authentication.

    1.3.5

    Root level UIDs are only defined on the local server and do not provide domain-wide access through the NIS password file.

    If root IDs are implemented domain-wide using NIS, it is likely that system administrators will have privileged access to systems not required for their job functions, while the compromise of a single root account would result in the compromise of all systems in the domain.

    NIS contains no root level UIDs (uid=0).

    1.4 System Configuration

    1.4.1

    Access to the at command is limited.

    The at command allow users to run commands at a later time, using the cron command queue. The unrestricted use of these commands is a security risk.

    Review the at.allow and at.deny files for appropriate entries, using the cat command. If users other than root have a business need to use the at and batch commands, create the at.allow and at.deny files to control which users can use the at command. The login names of users that are allowed to use the at command must be listed in the at.allow file. The at.deny file specifies the list of denied users.

     

    These files must be owned by root and members of the sys group, with permissions mode 640.

     

    Where necessary, add entries to at.allow and at.deny using a text editor, and change permissions on these files using chmod.

    1.4.2

    Devices (except terminals) are not world readable, writeable or executable.

    Improperly protected devices (which are represented to the UNIX OS as files) can leave systems vulnerable to attackers. For instance, if an attacker can write to the /dev/kmem device (kernel memory) with a debugger, he may be able to modify his UserID (to become root), modify data in system buffers, or write garbage over critical data structures, causing the system to crash. Similarly, unauthorized access to disk devices, tape devices, network devices and terminals being used by others can lead to problems.

    Use the chmod command to set appropriate permissions on device files.

    1.4.3

    The network interface card should not be in promiscuous mode.

    Most Ethernet cards can be placed in "promiscuous" mode, which enables a user to gather and review all Ethernet packets on the local subnetwork, including the data in those packets, such as passwords. Intruders will often attempt to install such gathering software (such as etherfind or tcpdump) upon breaking into the system, in order to gain further access.

    To determine whether the network interface is in promiscuous mode, use the CPM tools, available from www.cert.org

    1.4.4

    Use of the mount command should not be executable by users and any untrusted file system (i.e. CD-ROMS) should only be mounted without the ability to execute suid programs.

    Users can inadvertantly mount systems over one another and do not need to routinely mount file susyems. A file system mounted, such as a CD-ROM may contain suid to root programs, allowing an attacker to gain root access.

    Remove the mount command from world access and require untrusted file systems to be mounted with the 'o nosuid option.

    1.5 Support, Maintenance & Planning

    1.5.1

    Corporate IS security policies include specific sections pertaining to the UNIX environment, including configuration guidelines to significant security areas.

    AIX System Administrator that does not know and understand the Corporate IS security policies may wrongly configure the AIX system and thereby expose the system to security risks.

    Review the corporate information security policies and procedures to determine if sufficient support exists for a controlled environment. UNIX policies should include specific configuration guidelines, tailored to particular environments such as "file servers," "DMZ systems," etc.

    1.5.2

    Procedures must be implemented for the regular acquisition and installation of vendor (both IBM and third party applications) patches and upgrades necessary to correct security flaws, as well as installation of workarounds for unpatched problems.

    The system may be needlessly vulnerable to security flaws discovered on an ongoing basis, in terms of both system penetration and denial of service. System crackers are aware of security flaws, and will exploit them if patches are not implemented.

    Inquire about the system administrator's procedures for obtaining the latest and Inquire about the system administrator's procedures for obtaining the latest and installing the security patches and workarounds.

     

    Review vendor resources (including www.ers.ibm.com) and security sites such as CERT (www.cert.org) and Bugtraq (www.netspace.org) for the existence of security-related system patches for the particular OS, and install said patches. If using an older version of the OS, upgrading to the latest version of the OS (plus any patches for that version is usually preferable to keeping the older version with patches. The IBM ERS web site contains (but not for any other software such as a third party Web server or for Sendmail - consult other vendors as appropriate.

     

    Important: Some patches may change to your system configuration to insecure defaults.installing the security patches and workarounds.

     

    Review vendor resources (including www.ers.ibm.com) and security sites such as CERT (www.cert.org) and Bugtraq (www.netspace.org) for the existence of security-related system patches for the particular OS, and install said patches

     

    Important: Some patches may change to your system configuration to insecure defaults.

    1.5.3

    If significant programming is done on the server, an appropriate system development life cycle and change control methodology is in place.

    A disorderly development environment, including problems such as a blurring of the development and production environments, insufficient quality assurance testing, insufficient documentation, and excessive programmer privileges, can lead to a breakdown in the security of the system and the integrity of the production data.

    Develop applications on a development system. (NOTE: Development system needs to be completely separate from Production system and network).

    Test new application/program on the Development/Test system. Provide the test criteria and application/program documentation.

    Submit program to Quality & Assurance group for testing.

    Develop a migration plan to the Production system.

    Prepare a back-out plan.

    Notify the system administrator about the migration and the tentative date.

    If all tests have been conducted and passed, submit a change request following the Change Management Process.

    If all authorizations have been obtained and the date approved, migrate to production according to plan.

    Verify that the migrated application is working.

    Provide any required maintenance documentation to the system administrator.

    1.6 Physical Access

    1.6.1

    The server's physical surroundings are designed for the safety and availability of the system, including cleanliness (lack of dust), appropriate and stable temperature and humidity, and neat and controlled cabling.

    If a computer is not stored in a clean, cool environment, it may be subject to more breakdowns and loss of data.

    Rooms containing critical servers should be climate-controlled.

    If conditions are inappropriate, take steps to correct.

    2 Identification

    2.1 User Accounts

    2.1.1

    Each user has a unique user name and user ID.

    UNIX tracks users by UID, rather than by username. Therefore, where users share UIDs, they may gain access to each others' files, while security administrators will not be able to track specific security events to specific users.

    All server user names and UIDs are unique.

    The process for user addition and deletion is constructed so as to minimize the risk of duplicate user names and UIDs.

    2.1.2

    User account group identification (GID) codes should be greater than 100 and never be 1 or 0. User account UIDs should be greater than 100 and must never be 0.

    UNIX UIDs under 100 are reserved for system accounts. By allowing users to have UIDs under 100, the risk is increased that the user will have access to information or resources that are reserved for more powerful system level accounts.

    To change a user's UID or GID, use the smit tool. Next, use the chmod command to change ownership any files owned by the old UID to the new UID.

    2.1.3

    User names follow an organizational naming convention.

    Following a pre-defined set of standards allows for the easier recognition of new accounts that may have been created in violation of policy, either by intruders or system administrators.

    Best Practices call for a naming standard which makes it hard for outsiders to guess individual account names based on personal information.

    We have a namiming standard in the Account Management and MSB Introduction documents. You may want to reference these two documents here.

    This naming standard prevents outsiders' deriving user account names from publically available information such as employee names. User account names can be used in combination with password guessing and social engineering to gain unauthorized access to systems.

    2.1.4

    Generic or group user accounts are not used. A generic account is identified as a user account in which multiple users, on a regular basis, access and have knowledge of a single user account with a known identification/password combination.

    Generic user accounts limit accountability on user actions performed while logged in as a generic user. Use of a generic account are extremely difficult to audit since it is impossible differentiate between the activities of individual users, making it a high priority target for intruders.

    If a generic account is identified, perform the following:

    1. Identify the purpose of the account,

    2. Identify all users of the account,

    3. Create unique accounts for all users of the generic account,

    4. Assign appropriate rights to all new user accounts, and

    5. Delete the generic account.

    2.1.5

    Third party tech support accounts are disabled, and only enabled temporarily as needed.

    Vendor accounts are often left enabled, with default passwords shared among vendor employees and known to vendor ex-employees.

    Vendor support accounts should only be enabled on a temporary basis.

    Support contracts with third-party vendors should be reviewed to determine liability in case a break-in takes place through the vendor's network.

    The third-party vendor should be contacted to determine whether secure systems practices are being followed, whether third-party security reviews have been performed, and whether such reviews are available for inspection.

    2.2 System Configuration

    2.2.1

    Default system accounts that do not need to be used are disabled.

    Default system accounts, such as daemon, bin, sys and adm, are automatically created when the AIX Operating System is installed. Many of these accounts are never logged into but are instead place holders for software ownership.

    The following accounts provided by default with AIX 4.x should be disabled:

    daemon, bin, sys, adm, uucp, guest, nobody, lpd.

    2.2.1

    All user accounts should be managed consistently to minimize inappropriate account configurations.

    Managing user accounts and their associated parameters by editing the native unix files, or even the mkuser command can lead to misconfiguartions creating a security exposure.

    Use the smit utility whenever its capabilitiy is sufficient. All normal administration of user accounts should utilize the smit utility.

    3 Authentication

    3.1 User Accounts

    3.1.1

    Accounts that run a single command, without authentication, are not allowed.

    UNIX allows accounts that simply run a single command or application program (rather than a shell) at login. These accounts typically have no password and are used, for example, to allow people to log in as who to obtain a list of who is on the system, to log in as lpq to check the printer queue, and so on. Examples of such accounts include who, finger, lpq, mail, news, date, uptime, sync, and help. These types of accounts are often exploited by an intruder.

    Delete any unauthenticated single command logins using the smit tool.

    3.1.2

    Dormant accounts are removed or disabled.

    Dormant entries are a target for intruders, as the account user will not notice the activity.

    Procedures should be in place for checking for dormant accounts on a regular basis. Same comment as 2.4.1.

    3.2 Password Composition & Management

    3.2.1

    Passwords are not easily guessable, i.e. words found in a dictionary, or a variation on the user name; they do not pertain directly to a user's family or personal interests. While passwords should contain both alpha and numeric characters, passwords with special characters are even harder to guess or crack with a utility.

    Passwords which are easy to guess give intruders an easy opportunity to break into the system.

    Define password/user characteristics in /etc/security/user, /etc/security/mkuser.default, /etc/security/login.cfg

    Minimum requirements (defined in /etc/security/user):

    minlen=8

    maxage=12

    minage=1

    maxrepeat=2

    minalpha=5

    minother=3

    mindiff=3

    maxrepeats=2

    maxexpired=0

    histsize=24

    pwdwarntime=14

    Set dictionlist= dictionary file of invalid passwords

    Set minimum default values for smit user field (defined in /etc/security/user) for the default stanza as follows:

    admin=false

    login=true

    su=false

    daemon=true

    rlogin=false

    sugroups=ALL

    ttys=ALL

    auth1=SYSTEM

    auth2=NONE

    tpath=noask

    umask=027

    expire=0

    3.2.2

    A unique initial password must be assigned to all new accounts and all users must change their passwords immediately when using a new account for the first time and passwords are distributed in a secure manner.

    If passwords are distributed in printed format or by e-mail, the likelihood is greatly increased that the information will fall into the hands of intruders, who can intercept e-mail or regularly check the office printer for password lists.

    Initial system passwords should be created in a secure manner, for instance by using a random character generator. Users should be required to obtain their initial system password in person and instructed to destroy any written material which may contain their password. We have a clearly defined process for new user password creation and communication in our Account Management Policy and MSB Introduction. We need to either reference these two documents or write the appropriate guidelines.

    3.2.3

    Root passwords should be different for each machine.

    Using the same root password on all machines can lead to compromise of all machines with the compromise of just one.

    The root password is set differently on each machine. The frequency with which they are changed should be irregular and unpredictable.

    3.2.4

    The root account does not allow for the separation of duties.

    Separation of duties is basic to security controls. The root account is all-powerful; access to this account for a subset of privileges violates this concept.

    Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

    3.2.5

    The shadow password file is used, with appropriate file permissions.

    The standard UNIX password file is world readable, so that anyone logged into the system can read the file and attempt to crack the account passwords, including root. The shadow password file removes this threat by moving the password information to a separate file, readable only by root. If the shadow password file is accessible by other users, the value of the shadow file is lost.

    Password shadowing should be in use for every account on the system. No encrypted passwords should exist in the etc/passwd file (null, * and ! only in the password field).

    3.2.6

    Insure proper password maintenance.

    Improperly maintained passwords can result in explotitation of the system and reduce user accountability.

    To scan for password inconsistencies, use:

    /usr/bin/pwdck ?n ALL

    To scan for group inconsistencies, use:

    /usr/bin/grpck ?n ALL

    Both of these will report errors but will not fix them automatically. To have the errors fixed, change the '-n' to '-y' in both cases.

    Review /etc/passwd, /etc/security/passwd, /etc/security/group regularly for changes

    3.3 System Configuration

    3.3.1

    Only one root level account (UID = 0) is defined on the server.

    Multiple root level accounts increase the risk that users have system access privileges not required for their job functions. In addition, intruders who target privileged accounts have multiple opportunities to gain root access. It also becomes more difficult to maintain an accurate audit trail when more than one root-level user exists on the system.

    Only one account with UID=0 exists on the system.

    Administrators are required to log into their own unprivileged accounts and su to root. No direct logins to the system as root are allowed.

    Administrators are to never su to root from a user's session without resetting the path variable or entering the full path for each command.

    4 System Access Controls

    4.1 User Accounts

    4.1.1

    Employee accounts are removed in a timely manner after separation from employment.

    Unnecessary accounts or accounts with unnecessary privileges create additional access paths for intruders.

    Business processes should be in place which ensure that all organizational accounts are created, updated and deleted in a timely manner.

    Often, and particularly in large orgainzations, software to support the above processes must be acquired.

    4.1.2

    End users are not provided command line (shell) access to the UNIX operating system unless necessary for their job functions.

    Access to the command line via a shell (the command line interpreter) increases the risk that the user can access unauthorized resources, as well as the risk to the system if an account is compromised.

    The following methods, in order of effectiveness, represent best practices:

    1) Replace the shell located in the last field of the password file (cat /etc/passwd). with a menu program,

    2) Use the chroot command to prevent user from accessing unauthorized files,

    3) Give users a restricted shell with no access to cd, rm, cat, and other sensitive commands (historical implementations of restricted shells have often been found to be ineffective).

    Note that restricting the shell is ineffective unless the rshd daemon is disabled on the server.

    4.1.3

    User configurable environment files should only be changeable by the user or root.

    Only the user should have write access to these files and no other users need to be able to see them.

    Group and world require no access privilieges to the following files:

    $HOME./.profile

    $HOME./cshrc.

    $HOME./.Xdefaults

    4.1.4

    The umask is set to control access to newly created files. Only the owner of a file has default permissions to read, write and execute the newly created file.

    Files and directories are created with a default set of permissions; these default permissions are controlled by the umask (user mask) system variable. Often, the default permissions are far in excess of what is needed for job functions, such as default world read and write privileges, creating opportunities for access to sensitive files or compromise of other accounts including root.

    The umask setting should be one of:

    077 - Most restrictive, but may hinder some collaborative efforts. Only the user has any access to the files he/she creates.

    027 - Somewhat less restrictive. Allows others in the user's group to read files created by the user.

    022 - Less restrictive. Allows any user to read files created by the user.

    The umask value must be set in the system file /etc/default/login.

    User umasks are set in the /etc/profile file (for Bourne and Korn shell users) and in the .login or .cshrc files in the user's home directory.

    For files deemed sensitive or confidential, use ACLs to further refine file access permissions.

    4.1.5

    Employee accounts are removed in a timely manner after separation from employment.

    Unnecessary accounts or accounts with unnecessary privileges create additional access paths for intruders.

    Business processes should be in place which ensure that all organizational accounts are created, updated and deleted in a timely manner.

    Often, and particularly in large orgainzations, software to support the above processes must be acquired.

    4.2 System Configuration

    4.2.1

    Any ' r ' services such as rlogin, rsh, rexec and .rhosts files are disabled.

    By using .rhosts authentication on a server, a user can permit specified users on specified machines to log in to the server without entering a password. Thus, individual users can set security policy (without the system administrator's knowledge), potentially leading to loss of critical resources within that account, and potentially compromising the entire host.

    Run the securetcpip command to disable the 'r' commands and deamons

    A cron job should be established to periodically check for, and remove, all 'r' commands such as rlogin, rsh, rexec, rcp and .rhosts files. This can be accomplished manually by issuing the following command:

    find / \(-name .rhosts -o -name .netrc \) -print

    Remove any 'r' files that are not required (rm <filename>).

    If 'r' files are required, utilize a utility such as Tripwire to verify that the files are not modified.

    Where .rhosts files are permitted, they should be limited to those users with a need for UNIX r-services. This can be accomplished on a per-user basis by editing the 'rlogin=no' parameter in /etc/security/user.

    .rhosts files may be effectively monitored by including them in the AIX Trusted Computing Base.

    4.2.2

    All user shells are listed in the /etc/shells file.

    The program chsh uses /etc/shells to determine which files are valid shells when the user wishes to change their shell. A user may be able to use any file as a shell if /etc/shells does not exist.

    The /etc/shells file exists and contains the names of a small number of valid shells.

    4.2.3

    Data files are given only the minimum access permissions necessary for operation.

    World writeable data files can be changed by anyone having any access to the system. Even without malicious intent, an inexperienced user may accidentally make critical changes to sensitive data files, or inadvertently allow an intruder to gain unauthorized access.

    Obtain a list of world readable and writeable files and directories by:

    find / \(-perm -0004 -o -perm -0002 \) -print >> ey.ww

    This command will search the file system for world readable and writeable files and send the contents to a local text file called "ey.ww".

    Note: exact command syntax may vary from system to system. Consult the system's man page. Also, this file may have already been created in a previous review step.

    Review the list for appropriateness.

    Change file permissions as necessary using chmod.

    4.2.4

    UNIX executables (e.g. /bin/sh and /usr/sbin/netstat), shell scripts (e.g. the /etc/rc scripts) and configuration files (e.g. /etc/inittab, /etc/inetd.conf, .profile and .login) are given only the minimum privileges necessary for operation.

    World writeable binaries and shell scripts can be changed or replaced with command files to give the intruder further access, or to damage the system (a.k.a. a "Trojan horse"). In any event, inexperienced users may accidentally damage the system or make hard to trace bugs due to critical files.

    Executables and shell scripts generally should not be world writeable, e.g., those in /bin, /usr/sbin, /dev, (although some devices may need to be world writeable), /etc, /etc/conf, /etc/default, /etc/init.d, /etc/log, /lib, /root, /shlib. Some key system files which should not be world writeable include /etc/passwd, /etc/group, /etc/profile, /etc/vfstab (default boot parameters), /etc/default/fs and /etc/dfs/fstypes (file system types), /etc/initab, /sbin/init and /etc/bootrc (boot script).

    Tools such as Tripwire ensure that system executables have not been tampered with.

    Alternatively, the AIX Trusted Computing Base (TCB) should be expanded to include the system executables.

    4.3 Password Composition & Management

    4.3.1

    Account names and passwords are not embedded in scripts, files or applications.

    If account names and passwords are embedded in login scripts, files or applications, anyone with read access to the scripts, files or applications (e.g. using the strings command) could extract the username and password, and gain unauthorized access to the system.

    Account names and passwords should not be embedded in executables or text files, including .netrc files.

    4.4 Physical Access

    4.4.1

    A server key lock facility is used (if available), and the key is removed and stored in a secure location.

    Key lock facilities can prevent illicit or unauthorized use of the system.

    Policies should be developed, implemented and effectively communicated concerning the procedures for the proper use of the key lock facility.

    A key lock facility is used (if available) to prevent unauthorized use or removal of a system. The key is removed and stored in a secure location.

    4.4.2

    The server console is physically secured within a locked facility.

    With physical access to the server console, all system security can be bypassed. It may be possible for unauthorized persons to obtain confidential data located on the server, or even reboot and take control over the server giving them instant root access without a password.

    Develop and implement procedures to control physical access to the system.

    - Servers should be located in locked rooms with physical access restricted to authorized personnel.

    - Key or card access to these rooms should be limited to those who have a job requirement to enter the room frequently.

    - Visitors and vendors should be escorted at all times.

    - Closed-circuit surveillance of the server room entrance should be considered.

    4.4.3

    The system key lock is in the secure position.

    Without this preventive measure, anyone with physical access to the server could cause it to reboot off of any tape, diskette, CD-ROM or hard drive, potentially allowing access to all information stored on the server.

    Ensure that the system key lock is in the secure position and that the key is removed and securely stored.

    4.4.4

    The server's physical surroundings are designed for the safety and availability of the system, including cleanliness (lack of dust), appropriate and stable temperature and humidity, and neat and controlled cabling.

    If a computer is not stored in a clean, cool environment, it may be subject to more breakdowns and loss of data.

    Rooms containing critical servers should be climate-controlled.

    If conditions are inappropriate, take steps to correct.


    5 Resource Access Controls

    5.1 System Configuration

    5.1.1

    Access to the Crontab command is limited. Best practices call for only the root user to have access.

    The crontab command submits, edits, list, or remove cron jobs. A cron job is a command run by the cron daemon at regularly scheduled intervals. The crontab program is owned by root and run with the SUID bit set. By default, everyone on the system can use the crontab command.

    Review (using cat) the files cron.allow and cron.deny, which control access to crontab. The files must be owned by root and members of the sys group, with permissions mode 640. Under AIX, the crontab access files are /etc/cron.d/cron.allow and cron.deny. The cron.allow file is checked by the system first. This file must include all of the login names (one name per line) of users allowed to use the crontab command. The root user's login name (root) must be listed in the cron.allow file. The cron.deny file must be used to list the login names of users who are not allowed to use crontab. If neither the cron.deny nor the cron.allow file exists, only the superuser can submit a job with the crontab command.

    To allow root only, remove the two files:

    /var/adm/cron/cron.deny

    &

    /var/adm/cron/cron.allow

    Where necessary, add appropriate entries to the cron.allow and cron.deny files.

    To explicity allow a user to use crontab:

    touch cron.allow

    put the userid in it

    To explicitly deny a user:

    touch cron.deny

    put the userid in it

    5.1.2

    Idle/inactive terminals are automatically locked or logged out after a period of inactivity.

    If accounts are not logged out (e.g. if the user doesn't log out at lunchtime or the end of the work day) someone with physical access to a terminal can gain access to sensitive information or install backdoors allowing later access to the account.

    Idle or inactive terminals should be automatically logged out after 5-20 minutes of inactivity, depending on business needs and work patterns. (TMOUT variable for the Korn shell, TIMEOUT for the Borne shell)


    6 Privileges

    6.1 User Accounts

    6.1.1

    Membership in privileged groups is limited to users with a business necessity for such access.

    Accounts listed in privileged groups, such as GID=0, have access to group writeable files created and owned by the root user. Allowing unauthorized users to have a GID=0 increases the risk that sensitive system configuration files will be changed or deleted.

    Only necessary and authorized users belong to privileged groups. Membership in privileged groups should be limited to users with a business need for the access. Of particular concern on AIX are the admin, adms and audit groups, whose menbership should be tightly controlled. For the predefined AIX groups, users should be added to the staff group only, or locally created groups.

    6.1.2

    Regularly examine group definitions.

    A common exploit is for an attacker to modify group permissions and privileges so that their activities are possibly less noticeable to the system administrator.

    To examine user group definitions, use:

    /usr/sbin/lsgroup `-fa` `id` `users` `ALL`

    6.1.3

    Regularly examine user information.

    A common exploit is for an attacker to modify group memberships for cracked accounts so that their activieites are possibly less noticeable to the system administrator.

    To examing user information, use (single command):

    /user/sbin/lsuser `-fa` `id` `groups` `home` `auditclasses` `login` `su` `rlogin` `telnet` `ttys` `ALL`

    6.1.4

    SUID and SGID programs are used only when no other reasonable, more secure means exists for the function. Where such programs are necessary, they are implemented in a secure manner, including limiting access to such programs using group permissions.

    If the SUID bit is set in the file permissions, the program executes with the permissions of the owner of the program in addition to the user executing it. For example, ps, the process status program, is SUID to root because it needs to read from system memory, something normal users are not allowed to do. The SGID bit behaves in exactly the same way as the SUID bit, except that the program operates with the permission of the group associated with the file. A vulnerability in a SUID root program (e.g.) can lead to a root-level compromise of the system. Accordingly, world writable SUID programs are especially dangerous.

    Where SUID or SGID programs are necessary, restrict access to SUID and SGID programs by creating a group especially for that program. This group should have execute permissions, while 'world' should not have access to the program. The permission bits on such a program would look like:

    r-sr-x--- 1 root print 9872 Dec 28 17:44 print_cleaner

    SUID programs should NOT be shell scripts, but should be compiled from C or a similar language.

    6.1.5

    Disable direct logins for root.

    Allowing for someone to log in directly as root is dangerous because it removes a layer of authentication and it may be more prone to a sniffing attack to capture the password.

    Set 'User can LOGIN REMOTELY' = false' in SMIT CHANGE/SHOW User Characteristics Screen.

    6.1.6

    If the system contains particularly sensitive data, or if strong controls on privileged access are otherwise required, software controls exist to manage and limit root access.

    Root access gives complete control over the system, including the power to crash the system or erase all data. While AIX is not equipped by default with exceptionally strong controls on root activity, such controls are available where necessary, in the form of free software such as sudo and larger packages such as SeOS, CA or Tivoli Security Management. These packages allow you to restrict which commands root can run, and to log the activity of root users.

    Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

    Use a third-party facility to further partition root functionality, if required. For example, "sudo-root" accounts can be set up and used by system operators to do system backups without providing full root functionality.

    For sensitive data files, use ACLs to implement refined access controls.

    If sudo is not in use, inquire about the appropriateness of using sudo.

    Keep root users to a minimum.

    To see which userids each user can use with su, use:

    lsuser 'f ALL


    6.2 System Configuration

    6.2.1

    If the system contains particularly sensitive data, or if strong controls on privileged access are otherwise required, software controls exist to manage and limit root access.

    Root access gives complete control over the system, including the power to crash the system or erase all data. While AIX is not equipped by default with exceptionally strong controls on root activity, such controls are available where necessary, in the form of free software such as sudo and larger packages such as SeOS, CA or Tivoli Security Management. These packages allow you to restrict which commands root can run, and to log the activity of root users.

    Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

    Use a third-party facility to further partition root functionality, if required. For example, "sudo-root" accounts can be set up and used by system operators to do system backups without providing full root functionality.

    For sensitive data files, use ACLs to implement refined access controls.

    If sudo is not in use, inquire about the appropriateness of using sudo.

    Keep root users to a minimum.

    To see which userids each user can use with su, use:

    lsuser 'f ALL


    7 Accountability

    7.1 Intrusion Detection

    7.1.1

    A regular program of logging and monitoring is in place.

    Logging and monitoring is often ignored or under utilized by system administrators, as it is often given a low priority by both IS and other departments. However, it is the only way to ensure the effectiveness of security measures, provide the opportunity to react to security breaches, and collect evidence of potential intrusions.

    A program of logging and monitoring is in place which includes real-time monitoring and notification of potential intrusions.

    7.1.2

    Log files are not world writeable.

    Log files provide the system audit trail and must be properly protected from unauthorized modification.

    Log files, including syslog and messages, should not be writable by users other than root. Change permissions using the command

    chmod go-w syslog

    7.1.3

    The loginlog is not world writeable.

    If the loginlog is world writeable, a intruder may delete records of their attempts to gain access, decreasing the likelihood that that their activities will be discovered.

    The loginlog should not be writable by any user other than root.

    Change permissions using the command

    chmod go-w loginlog

    7.2 System Configuration

    7.2.1

    The "sticky bit" is set on all world-writeable public directories.

    If the sticky bit is not set on a world-writable directory, files in that directory may be renamed or removed by users other than the owner of the directory or file. Some applications create temporary files in public directories; if the sticky bit is not set, an intruder might be able to overwrite the temporary files and compromise the application.

    The sticky bit should be set on all public directories which are normally world-writable, such as /tmp, /usr/tmp (/var/tmp) and /usr/spool/uucppublic. Set the sticky bit using chmod +t <name>.

    No sensitive or confidential information should be written to files in these directories, since any user can read them.

    7.3 Logging & Monitoring

    7.3.1

    Error logging should always be active.

    Many times, security exposures happen because of errors made. Recording and reviewing these errors can reduce the exposure they potentially represent.

    Ensure error logging is active ( the errdemon is running) and review the error log regularly.

    7.3.2

    Examine failed logins frequently.

    Failed logins can be an indication of possible attack against the system.

    Use the command:

    /usr/bin/who '-s' '/etc/securtiy/failedlogin'

    to generate a list of usernames that are unsuccessfully used to access the system.

    8 Remote Access Management

    8.1 User Accounts

    8.1.1

    Root login is restricted to the console.

    If root login is not restricted to the console, then the list of intruders who may attempt to directly gain root access increases from only those with physical access to the system to (potentially) anyone in the world. Users may still login to an unprivileged account and su to root.

    Remote logins as root are not permitted.

    8.1.2

    .netrc files are implemented securely.

    .netrc files can be a source of security risk because of the authentication information they contain. The $HOME/.netrc file is used by the ftp and rexec commands to allow automatic login to remote hosts without specifying passwords, and contains a list of host names, login names, and unencrypted passwords and other information to use at the remote hosts. This gives anyone with read access to the .netrc file (root on the local host) the ID's and passwords of remote systems.

    Forbid the use of .netrc files unless they are absolutely necessary (e.g.: the risk of disseminating remote passwords is acceptable).

    To prevent the use of .netrc files, adhere to the following standards:

    1. They should not contain passwords,

    2. They should be 0 bytes, and

    3. They should be owned by root.

    8.1.3

    Users such as root, as well as various system accounts, are not allowed to use FTP.

    Use of FTP access through the root account allows an additional remote path to supervisor level access by an intruder. Allowing FTP from system accounts (such as bin, smtp and sys) which normally would not require FTP also create additional paths into the system without providing an offsetting business benefit.

    Using a text editor, edit the file /etc/ftpusers. To disable ftp access for a particular account, add the name of the account to the file.

    8.2 NFS

    8.2.1

    Use NFS only when necessary. Check regularly for unauthorized NFS activation and use.

    The NFS service allows for users to mount a systems filesystems remotely. This service is a common way to exploit a system and gain access to private information.

    To check current NFS status use:

    lssrc 'g nfs

    To check if NFS is installed, use:

    lslpp 'l | /bin/grep nfs

    To check if NFS is active, use:

    lssrc 'g nfs | /bin/grep active

    To display which directories are exported, use:

    cat /etc/xtab

    To display which hosts are exporting directories, use:

    /usr/bin/showmount

    If the host is a client, to show what's mounted from remote systems, use:

    mount | grep 'v '^ '

    8.2.2

    File systems are not mounted writeable, absent a compelling business justification. Executables are mounted read only, if at all.

    The default configuration of NFS is to grant full access (read, write and execute) to all hosts to a mounted file system. Thus there is a high chance of allowing access to unauthorized individuals.

    Unauthenticated access to server executables can lead to numerous security vulnerabilities due to flaws in the mounted programs. Program coding mistakes which can become security exploits exist (whether publicly known or not) in as many as 50% of programs.

    The access control options, and recommended settings for the /etc/export and etc/dfs/dfstab files are:

    -ro=host, host - Exports the directory read-only. If this option is not specified, the directory is exported with read-write permission,

    -access=host,host - Restricts access to only the named hosts or netgroup name. If no -access option is specified, all hosts will have access. The default value allows any machine to mount the directory,

    -rw=host,host - Exports the directory read-write. This mode of exporting inherently lowers directory security and must be implemented with caution,

    -root=host,host - Allows superuser access from the named hosts. If NFS root access is not enabled for a remote NFS client, the root UID of the server is mapped to a default UID of -2 or 60001 (the nobody account) This restricts access against the superuser UID on a remote machine. Exports specifying root access are inherently less security and must be implemented with caution. The default is for no hosts to be granted root access.

    -secure - Requires NFS clients to use a more secure protocol when accessing the directory.

    Export only to fully-qualified host names to prevent spoofing.

    Revise where inappropriate.

    Use ACLs to implement refined access controls; however, if it is a heterogeneous environment, do not use ACL functions

    8.2.3

    NFS exported file systems are protected with access lists.

    Entering a directory or filesystem in the /etc/exports file without specifying an access list allows any host to mount the directory.

    NFS should be configured to allow for the minimum access necessary. The number of servers allowed to mount an exported file system whould be reduced to the minimum necessary. If the /etc/exports file does not specify a list of hosts for each exported file system, then NFS is insecurely configured.

    Additionally, do not use the 'root=' option unless absolutely necessary.

    8.2.4

    NFS mounted files and directories are configured with appropriately secure file permissions.

    If individual file permissions in NFS mounted shares are not configured for security, the likelihood that unauthorized users will have access to sensitive information increases.

    Files and directories on the server should be protected by setting their owner to root and their protection mode to 755 (in the case of programs and directories) or 644 (in the case of data files).

    8.3 System Configuration

    8.3.1

    Network services, including login, telnet, FTP, and HTTP do not display system identifying banners prior to authentication. Instead, a warning message displays a warning against unauthorized use.

    Servers often display sensitive information by default, such as the hostname, the OS version, and the server software version, e.g. ftp.clienthost.com, AIX4.3.3, wuftp version2.14(b9). An intruder could then attempt to exploit known vulnerabilities in these software types (available from public Internet databases). Legitimate users generally do not need to know such information. A warning message may also be necessary for subsequent prosecution of offenders.

    Instead of banners that identify system type and other sensitive information, network services display generic warning banners.

    8.3.2

    Only necessary network services are enabled. Where necessary, services are only implemented in a secure manner, including IP filtering, TCP Wrapper, and installation with the latest software patches.

    Unintended network access can be granted by computers that have more services enabled that is necessary. UNIX systems often are configured "out of the box" with numerous network services that are often unneeded, such as the Berkeley R commands (rshell, rexec and rlogin) and obsolete network testing services such as echo, discard and chargen. After installation, system administrators will often install unnecessary services, because they, or their managers, underestimate the security concerns involved. If a service is not enabled, it cannot be used to break in to the system.

    Remove all unnecessary services by commenting them out of the inetd.conf file (restarting the inetd process is required at this point (kill 'HUP <pid>) or out of the appropriate boot script, as necessary (by placing a comment mark (#) at the beginning of the lines describing the service).

    To verify inet services running use:

    netserv 's 'S -X

    8.3.3

    Rlogin and rshell are used only if an approved business justification exists.

    Rlogin and rsh provide remote virtual terminal and remote execution services similar to Telnet and rexec. However:

    a. rlogind and rshd do not require that the user type his login name; the login name is automatically transmitted at the start of the connection.

    b. If the connection comes from a trusted host (via hosts.equiv) or trusted user (via .rhosts), rlogind and rshd will accept the connection without requiring a password.

    The use of rshd and rlogind is not allowed unless a viable business justification exists. Employ secure methods for remote shells and remote logins that include advanced authentication and encryption (e.g., Secure Shell- SSH).

    8.3.4

    Tftpd is disabled except on servers which act as a boot host. On these servers, tftp is configured securely.

    The Trivial File Transfer Protocol (TFTP) is used to allow users to retrieve files without requiring an account on the remote system. TFTP is an unauthenticated file transfer service. It is commonly used for booting diskless workstations and downloading server code or fonts for X-terminals over the network. Many implementations of TFTP have security problems. In particular, unrestricted TFTP access allows remote intruders to retrieve a copy of any world-readable file without authentication, such as /etc/passwd.

    If TFTP is required, restrict access to server files so that sensitive files can not be retrieved remotely via tftp. You may want to talk to Chris Watson regarding this. He may have some stuff that could help us improve this section.

    8.3.5

    The finger daemon is only used if an approved business justification exists, and then only in a secure manner.

    The Finger daemon service allows a remote user to obtain information about local users, such as their user name, full name, home directory, last login time, and in some cases when she last received and/or read her mail. The fingerd program allows users (and intruders) on remote hosts to obtain this information.

    If the finger service is necessary, a newer version should be run which requires that a user name be provided along with any request. This keeps arbitrary outsiders from obtaining a complete list of users logged in to the server.

    8.3.6

    The FTP daemon is only used if an approved business justification exists.

    The File Transfer Protocol (FTP) allows users to connect to remote systems and transfer files. FTP may be used in either authenticated (where a plaintext username and password are required) or anonymous (no username or password required) mode, depending on system configuration. In either case, FTP allows remote access to the server's files, without secure authentication. FTP is an issue both because it allows remote users access to the file system and because legitimate users have been known to unwittingly store sensitive corporate information on publically available FTP sites.

    If FTP is required, it should be enabled with the following standard:

    1. Only the latest release (including patches) should be used, as various FTP servers have security bugs that allow intruders to break into the system,

    2. Anonymous FTP is not allowed, and

    3. The /etc/ftpusers file is utilized to restrict login from defined accounts.

    8.3.7

    The remote printer daemon is securely configured.

    The /etc/hosts.lpd file is used to specify the remote hosts that are allowed to communicate with the lpd printer daemon and access local printer queues. An improper configuration can lead to unauthorized root access.

    Edit the hosts.lpd file as necessary, using a text editor.

    Change file permissions using:

    chmod 640 /etc/hosts.lpd

    8.3.8

    The Rexec daemon is only used if an approved business justification exists.

    The rexec (RPC remote program execution) allows users to execute commands on remote computers without prior authentication.

    The use of rexecd is not allowed unless a viable business justification exists. Employ a secure methods for remote command execution that employs advanced authentication and encryption (e.g., Secure Shell- SSH).

    8.3.9

    The Telnet daemon is only used if an approved business justification exists.

    Telnet provides remote virtual terminal service similar to that provided by a dial-up modem. Usernames and passwords are susceptible to sniffing, as they are transmitted in plaintext. On the other hand, even without a known username and password, telnet is susceptible to remote attack. Because it is significantly faster to connect with telnet than it is to call up with a modem, an attacker can try to guess more passwords in a given amount of time. Also, it is often easier (and less expensive) to call a computer anonymously on the Internet than over the phone lines.

    If telnet functionality is needed, the standard telnet server is replaced with a program which encrypts passwords, such as ssh.

    Limit access to those accounts with a business justification through the accounts' LOGIN REMOTELY fields.

    8.3.10

    UUCP is only used if necessary for an approved business purposes.

    All versions of UNIX provide a rudimentary form of networking called UUCP, which allows files and electronic mail to be transferred, as well as remote command execution. Installation of the UUCP subsystem is not recommended: a) there is no pairing of a single individual with a UID on UUCP, b) many UUCP systems are configured with anonymous logins. Unless UUCP is carefully configured, sensitive information can be stolen and files can be sent to your system that can compromise security.

    UUCP can be disabled by changing the 'home directory' and 'shell' fields of the uucp passwd file entry to '/dev/null'.

    Disable UUCP-related commands such as uucp, uulog, uuname, uupick, uusend, uustat, uuto, uux, as well as commands in /usr/lib/uucp (Note that the uuencode and uudecode commands should not be disabled, as they are used by other applications such as mail clients. However, make sure that uuencode is not SUID, or else the user could accidentally create SUID executables).

    8.3.11

    X Windows is only used if necessary for an approved business purposes. If required, it is implemented in a secure manner, using secure shell to encrypt X traffic. Lets either use Xwindows or X Windows.

    We need to have 'Impact(s)' discussed.

    If X windows is not needed, it should be disabled by editing the AIX rc startup files and commenting out the line which starts X windows.

    If X windows is needed, it may be configured to use an encrypting "tunnel" such as Secure Shell.

    8.3.12

    Direct modem access to servers is only used if necessary for an approved business purpose; if necessary it is implemented in a secure manner.

    It is not uncommon for systems to be configured with insecure direct modem access, either 'out of the box' or thereafter by non-security conscious administrators. Dial-up modems allow anyone who knows the correct telephone number to access the system and try to break in. For example, it is not uncommon for the modem to have no password, or a simple password such as 'guest'. Also, if improperly configured, modems may allow an attacker to call a system and obtain access to an already logged-in line that another user has unknowingly left behind.

    Several options are available for increasing modem security.

    If practical, dial-back modems should be used.

    Hardware tokens is a secure way of providing remote access, and should be used if at all possible

    8.3.13

    hosts.equiv files are not used to establish trust relationships.

    The file /etc/hosts.equiv is used to establish global, password-less trust relationships between remote systems and the server, similar to .rhosts files (the system actually checks hosts.equiv first, then .rhosts if no matches are found).

    /etc/hosts.equiv files are not used to establish trust relationships between hosts.

    No application should need unauthenticated access to another server. If such applications exist and are mission-critical, they should be configured to make narrow use of the .rhosts feature of AIX while alternative applications are investigated or developed internally.

    Table of Contents

    HACMP

    HACMP Standards

    MtXia's HACMP standards are contained within the following document:

    Unix-HACMP-Presentation.pdf

    Table of Contents

    Installation

    Installation Standards

    Table of Contents

    Monitoring

    Monitoring Standards

    Table of Contents

    Patch Management

    Patch Management Standards

    Table of Contents

    Procedures

    The procedures used to support the Policies, Guidelines, and Standards implemented in the Power 5 environment, are described here.

    Table of Contents

    Frames

    Frame Procedures

    Table of Contents

    Microcode

    Microcode Management

    Systems without an HMC

    Use IBM's Microcode Discovery Service at the following URL to determine what microcode should be updated, to retrieve the microcode, and the instructions for installing the microcode.

    https://techsupport.services.ibm.com/server/aix.invscoutMDS

    Normally the "java applet" is used to peform the microcode discovery which requires the password for the user "invscout" to be set. This also requires internet communication from the system over port 808. To use the java applet perform the following steps on the target system:

    1. Set the password for the user "invscout"

      2. passwd invscout

    2. Clear the password administration flags on the user "invscout" 

      pwdadm -c invscout

    3. Start the "invscout" daemon 

      invscoutd

    4. The system is now ready for microcode discovery via the java applet
    5. The microcode discovery service will require several pieces of information to be able to perform the survey:

      • Fully qualified hostname of the system
      • Password for the user "invscout"
      • Port number (default: 808)
      • System Model Number 

        lsattr -El sys0 -a modelname -F value

      • System Serial Number 

        lsattr -El sys0 -a systemid -F value

    Systems with an HMC

    Use the facilities built into the HMC for performing microcode updates to all managed systems.

    Table of Contents

    Storage

    Storage Procedures

    Table of Contents

    Hostname/Alias

    Hostname Procedures

    Table of Contents

    HMC

    HMC Procedures

    Table of Contents

    Virtual Processor Size

    This document describes the algorithms used to calculate the size of a virtual processor in a shared processor environment using the Power5 architecture. The IBM documentation does not fully explain this concept and this document attempts to clarify this issue.

    When defining an LPAR through the HMC for the Power5 architecture, the type of processors assigned to the LPAR must be defined. The possible choices for this are: Dedicated and Shared. If "Shared" is selected, the following input fields are presented:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    When entering "shared" mode processors, the "Processing units" input fields define the total amount of processing units that will be allocated to all virtual processors. This translates to the following algorithm:

    Algorithm:

    Vs = Pu / Vn

    Rules:

    1.00 Pu = 1 full power5 physical processor
    Pu < Pt
    Vn <= 64

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR
    Pt = Total number of physical processors in frame

    As an example of using this algorithm:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    These values would allocate "0.5" physical processing units to the LPAR and "2" virtual processors. The size of each virtual processor would be "0.25" physical processing units.

    Algorithm:

    Vs = Pu / Vn
    Vs = 0.5 / 2
    Vs = 0.25

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR

    Another example using this algorithm:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    These values would allocate "2.5" physical processing units to the LPAR and "5" virtual processors. The size of each virtual processor would be "0.50" physical processing units.

    Algorithm:

    Vs = Pu / Vn
    Vs = 2.5 / 5
    Vs = 0.50

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR

    A final example illustrating how the EGATE Proof of Concept LPAR's were configured:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    In this example, if the desired number of physical processing units was allocated to the LPAR, "3.0" physical processing units would be allocated to the LPAR and "6" virtual processors. The size of each virtual processor would be "0.50" physical processing units.

    Algorithm:

    Vs = Pu / Vn
    Vs = 3.0 / 6
    Vs = 0.50

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR

    Table of Contents

    VIO Server

    Virtual I/O Server Procedures

    The procedures referenced by this document are related to the design, implementation, configuration and management of the AIX Virtual I/O Server (VIO Server).

    Table of Contents

    VIO WLM Enable

    Procedure to enable centralized statistics gathering from a VIO server via WLM

    The Virtual I/O (VIO) servers should not have extraneous software installed on them, therefore the performance toolbox software is not installed or enabled. However the Workload Manager (WLM) is installed and should be enabled in passive mode. The procedure to enable WLM on the VIO servers follows:

    This procedure assumes there is a centralized storage location for the WLM statistics shared to the VIO server via NFS. In the following example the centralized storage is located on the MX1 NIM server whose hostname is "mx1apnim01". The specific directory being shared via NFS from "mx1apnim01" is "/prfdmce0".

    This procedure also uses an example VIO server hostname of "mx1advio01".

    Establish the NFS mount from the centralized NFS storage location.

    /usr/sbin/mknfsmnt -f /prfdmce0 -d /prfdmce0 -h mx1apnim01-mc2 -M sys -t rw -w bg -ABSXYZ -jqg

    Add a directory to the centralized NFS storage location to contain the statistics files from the VIO server.

    mkdir -p /prfdmce0/ddadvio01/wlm

    Add a record line to "/etc/inittab" to start the WLM statistics gathering daemon

    mkitab 'ptxwlm:2:respawn:/usr/bin/xmwlm -d /prfdmce0/mx1advio01/wlm -n xmwlm > /dev/null 2>&1'

    Start the WLM in "passive" mode.

    /usr/sbin/wlmcntrl -p > /dev/console 2>&1

    Add a record to the "/etc/inittab" to start the WLM at system boot time.

    mkitab -i rc 'wlm:2:once:/usr/sbin/wlmcntrl -p > /dev/console 2>&1'

    Table of Contents

    VIO HDLM Parms

    Power 5: VIO HDLM configuration for MPIO based rootvg

    This document describes the procedure to configure the HDLM driver on AIX VIO servers for the purpose of serving virtual MPIO "rootvg" disks to client LPARs. This procedure requires multiple parameter settings that must be performed in a specific sequence in order for the values to take effect.

    This document describes a procedure to configure HDLM on a new VIO server with two (2) fiber channel controllers and assumes the disk and FC devices can be easily removed and recreated. This procedure also assumes the HMC VIO device configuration for the VIO Server and LPAR client has already been performed. This procedure further assumes the LPAR is booted and running AIX from a single path MPIO disk.

    NOTE: This procedure assumes an entire HDLM disk is used as the backend device, not a logical volume on an HDLM disk.

    Two fiber channel SCSI controller parameters must be changed to enable the MPIO based rootvg. To change these settings, first deconfigure the virtual SCSI adapter and remove the disk devices.

    From the VIO "padmin"prompt:" 

    rmdev -pdev vhost0
rmdev -dev vhost0 
oem_setup_env

    From the VIO "root" prompt: 

    rmdev -Rdl fcs0
rmdev -Rdl fcs1
cfgmgr

    Configure the HDLM reservation status to "on 0" and remove any persistant reserves that were placed on the disks by the HDLM driver.

    From the VIO "root" prompt: 

    cd /usr/DynamicLinkManager/bin
./dlnkmgr set -rsv on 0
echo y | ./dlmpr -c hdisk2
echo y | ./dlmpr -c hdisk6

    Configure the fiber channel SCSI controller dynamic tracking to be enabled. Also configure the fiber channel SCSI controller fast I/O failure to a setting of "fast_fail".

    From the VIO "root" prompt: 

    for i in $( lspv | grep -v 'rootvg' | awk '{ print $1}' )
do
    rmdev -dl ${i}
done
chdev -l fscsi0 -a dyntrk=yes
chdev -l fscsi0 -a fc_err_recov=fast_fail
lsattr -El fscsi0
chdev -l fscsi1 -a dyntrk=yes
chdev -l fscsi1 -a fc_err_recov=fast_fail
lsattr -El fscsi1

    Now reconfigure the FC disk devices with the new FC SCSI controller settings.

    From the VIO "root" prompt: 

    cfgmgr

    Again, remove any persistant reserves

    From the VIO "root" prompt: 

    cd /usr/DynamicLinkManager/bin
echo y | ./dlmpr -c hdisk2
echo y | ./dlmpr -c hdisk6

    Now reconfigure the virtual SCSI controller.

    From the VIO "padmin" prompt: 

    mkvdev -vdev dlmfdrv0 -vadapter vhost0 -dev vdlmfdrv0
lsmap -all

    Repeat this entire procedure on each VIO server, once complete, then boot the client LPAR's and check to see if there are multiple paths to each "rootvg" disk.

    From the "root" prompt on an LPAR client machine: 

    lspv
lspath

    Table of Contents

    PLM

    Partition Load Manager Policies

    The documents referenced here describe procedures related to the Partition Load Manager (PLM). The Partition Load Manager (PLM) provides CPU and memory resource management and monitoring across logical partitions (LPARs). Partition Load Manager allows you to effectively use CPU and Memory resources by allowing you to set thresholds for designated resources. When a threshold is exceeded, Partition Load Manager can try to assign CPU and/or Memory resources to that LPAR by using resources assigned to other LPARs that are not being used.

    Table of Contents

    PLM Config

    The Partition Load Manager (PLM) provides CPU and memory resource management and monitoring across logical partitions (LPARs). Partition Load Manager allows you to effectively use CPU and Memory resources by allowing you to set thresholds for designated resources. When a threshold is exceeded, Partition Load Manager can try to assign CPU and/or Memory resources to that LPAR by using resources assigned to other LPARs that are not being used.

    PLM is an automated mechanism for utilizing the Dynamic LPAR (DLPAR) capabilities of the HMC and requires communication with the HMC. This means that before PLM will function, DLPAR must be functional on the HMC. DLPAR requires communication with each LPAR via the Resource Monitoring and Control (RMC) subsystem.

    Preparation for implementation of PLM

    Install and configure SSL and OpenSSH.

    Verify or install the following fileset on the PLM Server and every PLM client LPAR::

    • csm.client

    After installation of the "csm.client" file, run the following commands to initialize the RMC subsystem:

    cd /usr/sbin/rsct/install/bin
./recfgct
lssrc -a | grep rsct

    From the above "lssrc" output, check to ensure "IBM.CSMAgentRM" is running. Repeat these steps on every PLM client LPAR.

    Before implementing this rest of this procedure, verify the HMC is able to perform DLPAR functions to the client LPAR, then continue. If the HMC is unable to perform a DLPAR, PLM will not work.

    Implementing PLM

    Install the following filesets:

    • plm.license
    • plm.server.rte
    • plm.sysmgt.websm

    For setup of PLM, create .rhosts files on the server and all clients. After PLM has been set up, you can delete the .rhosts files.

    Create SSH keys

    On the PLM server, enter:

    ssh-keygen -t rsa

    Copy the HMC secure keys to the PLM server

    scp hscroot@hmchostname:.ssh/authorized_keys2 ~/.ssh/tmp_authorized_keys2

    Append the PLM server keys to the temporary key file and copy it back to the HMC:

    cat ~/.ssh/id_rsa.pub >> ~/.ssh/tmp_authorized_keys2
scp ~/.ssh/tmp_authorized_keys2 hscroot@hmchostname:.ssh/authorized_keys2

    Test SSH and enable WebSM

    Test SSH to the HMC. You should not be asked for a password.

    ssh hscroot@hmchostname lssyscfg -r sys

    On the PLM server, make sure you can run WebSM:

    /usr/websm/bin/wsmserver -enable

    Configure the PLM Server

    On the PLM server, open WebSM and select Partition Load Manager.

    Click on ghe Globals tab and enter the fully qualified hostname of your HMC. Enter "hscroot" as the HMC user name. Enter the CEC name, which can be obtained by running the following command on the PLM server:

    ssh hscroot@hmchostname lssyscfg -sys -F name

    Select the system name that corresponds to the frame you are configuring in the PLM server and enter this as the CEC name.

    Click on the Groups tab and add the groups "dedicated" and "shared". The maximum values should be the total amount of CPU and memory on the frame being configured to be managed by the PLM. Click on CPU and memory management to manage both.

    Click on the partitions tab and add all the LPAR's on the frame to be managed by the PLM. Use the fully qualified domain name as the partition name for each LPAR.

    Click on OK to create the policy file and verify it's existance on the PLM server under "/etc/plm/policies"

    From the WebSM interface of the PLM, perform the PLM setup. NOTE: You must be logged into the PLM server through the WebSM interface as "root" to perform this step.

    Test RMC Authentication

    Test RMC authentication by running the following command from the PLM server, where "plm_client_name" is the hostname of the LPAR that will be managed by PLM.

    CT_CONTACT=<plm_client_NAME>  lsrsrc  IBM.LPAR

    If successful, several lines of LPAR information will be printed out instead of "Could not authenticate user".

    Start the PLM Server

    From the WebSM interface of the PLM server, start the PLM server. Enter the full path file name of the policy file name. The full path file name of the policy file will be the directory "/etc/plm/policies" followed by the serial number of the frame. Any alphabetic characters in the serial number must be entered in UPPERCASE letters. For example:

    /etc/plm/policies/10F6BEE

    Also enter the full path file name of a log file where the PLM will store activity information. Several utilities are dependent upon the information contained within the log file so it is important that this log file be created in the correct directory with the correct name. The log file directory is "/var/opt/plm" and the log file name is the serial number of the frame followed by ".log". Any alphabetic characters in the serial number must be entered in UPPERCASE letters. For example:

    /var/opt/plm/10F6BEE.log

    NOTE: You may have to "touch" the logfile before starting the PLM Server

    Troubleshooting

    If the PLM server does not start, check the PLM server file "/var/ct/cfg/ctrmc.acls" to ensure the following lines are at the bottom of the file:

    IBM.LPAR
	root@hmcHostname	*	rw

    NOTE: Even though there is no access to the "root" user on the HMC, this line should still reference "root@hmcHostname".

    On the PLM client LPAR check the same file "/var/ct/cfg/ctrmc.acls" to ensure the following lines are at the bottom of the file. Recognize the last line of this file on a PLM client LPAR will reference the PLM Server hostname rather than the HMC hostname:

    IBM.LPAR
	root@plmServerHostName	*	rw

    If you edit, the "/var/ct/cfg/cgrmc.acls" file on the PLM server or on a PLM client LPAR, restart the RMC subsystem on the modified systems.

    refresh -s ctrmc

    Troubleshooting

    If the PLM server still does not start, there is most likely an RMC authentication problem. Begin by obtaining a list of trusted hosts by running the following command on the PLM server:

    /usr/sbin/rsct/bin/ctsvhbal

    One or more identities of the PLM client LPAR should appear in this list. If not you may need to rerun the PLM Setup. This can be performed from the WebSM interface or from the command line on the PLM server. The command line is:

    cd /etc/plm/setup
./plmsetup <plmClientHostName> root

    On the PLM client LPAR check the list of trusted hosts by running the following command:

    /usr/sbin/rsct/bin/ctsthl -l

    The PLM Server host name should appear in this list. If multiple identities exist, it is usually a good idea to remove them all and rerun the PLM setup command on the PLM server. To remove the trusted host identities on a PLM client LPAR, run the following command:

    /usr/sbin/rsct/bin/ctsthl -d -n <hostname>

    Trusted host identities can be added on the PLM server or client LPAR's using the following command:

    /usr/sbin/rsct/bin/ctsthl -a -n <hostname> -m rsa512 -p <identifier>

    Where the <identifier> can be obtained by running ctsthl -l on the opposite system to determine it's value.

    Troubleshooting

    One problem that was encountered with the PLM server was when using the WebSM interface and clicking on the link labeled "Show LPAR Statistics", a dialog window would appear filled with java errors, and the statistics screen would not start. This was apparently due to a formatting problem with the policy file itself. However the PLM server will start and there are no obvious errors other than the inability to click on the "Show LPAR Statistics" link.

    The fix for this problem is to delete the Policy file and create a new one.

    Table of Contents

    LPAR

    Logical Partition Procedures

    Table of Contents

    VIO Procedures

    Virtual I/O Server Procedures

    The procedures referenced by this document are related to the design, implementation, configuration and management of the AIX Virtual I/O Server (VIO Server).

    Table of Contents

    VIO VLAN ID

    This document describes a standard for establishing virtual ethernet adapters in the VIO Server environment. This standard is specific to the numbering scheme used to identify the VLAN ID's of the virtual ethernet adapters. The VLAN ID number is also referred to in the HMC as the PVID number.

    This document assumes there are two VIO servers in the environment and the names of the VIO servers are represented by "*vio0" and "*vio5".

    The VLAN ID numbers will be three digit numbers, each digit representing a different aspect of the underlying ethernet adapter.

    3 Digit VLAN ID Number
    First Digit Second Digit Third Digit
    5: Boot/Service
    6: Standby
    7: Backup
    8: Management
    9: Intra-Frame     		0: Gigabit
    5: 10/100
    9: Bus     		0: VIO Server 0
    5: VIO Server 5

    The first digit of the VLAN ID numbers associated with virtual ethernet adapters will be used to represent a variety of adapter purposes. Those purposes include boot, standby, backup, management, and intra-frame communications.

    • 500-599: boot/service
    • 600-699: standby
    • 700-799: backup
    • 800-899: management
    • 900-999: intra-frame

    The third digit of the three digit VLAN ID number assigned to virtual ethernet adapters associated with the VIO Server named *vio0 will end with a number between 0 and 4.

    Example: 500, 501, 502, 510, 520, 521, ...

    The VLAN ID numbers assigned to virtual ethernet adapters associated with the VIO Server named *vio5 will end with an odd number beginning at 5.

    Example: 505, 506, 507, 515, 525, 526, ...

    The second digit of the three digit VLAN ID sequence will represent the adapter speed, gigabit cards will be represented by 0 thru 4, 10/100 adapters by 5 thru 8, and bus speed adapters by a 9. This digit may be reconfigured as necessary.

    Examples:

    Adapter Speed
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot 0 Gigabit *vio0
    501 Boot 1 Gigabit *vio0
    505 Boot 0 Gigabit *vio5
    506 Boot 1 Gigabit *vio5
           
    550 Boot 0 10/100 *vio0
    551 Boot 1 10/100 *vio0
    555 Boot 0 10/100 *vio5
    556 Boot 1 10/100 *vio5
           
    590 Boot 0 Bus *vio0
    591 Boot 0 Bus *vio0
    595 Boot 0 Bus *vio5
    596 Boot 1 Bus *vio5

    An LPAR may have multiple adapters of a variety of types, for example an LPAR that provides database services and is a member of an HACMP cluster may have boot, standby, management, backup, and intra-frame virtual adapters as follows:

    • Gigabit adapter used for boot/service address
    • Gigabit adapter used for standby address
    • 10/100 backup adapter
    • 10/100 management adapter
    • 2 intra-frame adapters

    VIO Server Configuration:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    600 Standby Gigabit *vio0
    750 Backup 10/100 *vio0
    850 Management 10/100 *vio0
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
           
    505 Boot Gigabit *vio5
    605 Standby Gigabit *vio5
    755 Backup 10/100 *vio5
    855 Management 10/100 *vio5
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    LPAR VLAN ID configuration to utilize virtual adapters:
    VLAN ID Adapter Type Adapter Speed VIO Server
    500 Boot Gigabit *vio0
    505 Boot Gigabit *vio5
    600 Standby Gigabit *vio0
    605 Standby Gigabit *vio5
    750 Backup 10/100 *vio0
    755 Backup 10/100 *vio5
    850 Management 10/100 *vio0
    855 Management 10/100 *vio5
    990 Intra-frame Bus *vio0
    991 Intra-frame Bus *vio0
    995 Intra-frame Bus *vio5
    996 Intra-frame Bus *vio5

    Table of Contents

    VIO SCSI ID

    Configuration of the virtual I/O adapters requires the knowledge of disk layouts as well as networking configuration. The virtual SCSI adapters require a server and a client adapter to be configured on the HMC. The server side portion of the SCSI adapter requires a frame wide unique "slot number" be defined. For high availability a server side portion of the SCSI adapter must be configured for each VIO server. This means that for each virtual disk or logical volume connection, 2 server side SCSI adapters will be configured, one for each VIO server. By convention the standard has become that each SCSI adapter is numbered as a multiple of 10, with the first SCSI adapter of the server side high availability pair being configured on the first VIO server and ending with the number 0, i.e., 210, 220, 230, 240, ... The second SCSI adapter of the server side high availability pair is configured on the second VIO server and ends with the number 5, i.e., 215, 225, 235, 245, ...

    For each LPAR that uses virtual disk or logical volumes, a client side virtual SCSI adapter must be configured on the HMC. The client side of the virtual SCSI adapter requires additional information and it's settings to correspond with the server side of the SCSI adapter. Coordination of the slot numbers defined here will make debugging and tracking of problems much easier and is highly desired. The information required to configure a client side SCSI adapter includes slot number, the name of the server side SCSI adapter remote partition, and the slot number of the server side SCSI adapter on the remote partition. The client side slot number should correspond with the server side slot number to make debugging and tracking easier. As an example of defining both server and client side SCSI adapters in a high availability environment:

    LPAR Type Slot
    Number    		 Remote
    Partition    		 Remote
    Slot Number
    mx1apvio01 server 210
    mx1apvio02 server 215
    mx1pocap01 client 210 mx1apvio01 210
    mx1pocap01 client 215 mx1apvio02 215
    mx1apvio01 server 220
    mx1apvio02 server 125
    mx1pocap02 client 220 mx1apvio01 220
    mx1pocap02 client 225 mx1apvio02 225
    mx1apvio01 server 230
    mx1apvio02 server 235
    mx1pocap03 client 230 mx1apvio01 230
    mx1pocap03 client 235 mx1apvio02 235
    mx1apvio01 server 240
    mx1apvio02 server 245
    mx1pocap04 client 240 mx1apvio01 240
    mx1pocap04 client 245 mx1apvio02 245

    This virtual SCSI adapter information can be automatically gathered from an existing frame through the HMC using the script "virtualscsi.ksh. Example output from this script follows:

    Server9119590SN51A972E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 100 any 0x8100000000000000//ap01rootlv mx1apvio01
    server 110 any 0x8100000000000000//ap02rootlv mx1apvio01
    server 120 any 0x8100000000000000//ap03rootlv mx1apvio01
    server 130 any 0x8100000000000000//db01rootlv mx1apvio01
    server 150 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L1000000000000/hdisk5 mx1apvio01
    server 160 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L2000000000000/hdisk6 mx1apvio01
    server 170 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L3000000000000/hdisk7 mx1apvio01
    client 190 mx1apvio01 190 none mx1pocdb01
    server 30 any 0x8100000000000000//pocap01lv mx1apvio01
    server 40 any 0x8100000000000000//pocap02lv mx1apvio01
    server 50 any 0x8100000000000000//pocap03lv mx1apvio01
    server 60 any 0x8100000000000000//pocdb01lv mx1apvio01
    server 105 any // mx1apvio02
    server 115 any // mx1apvio02
    server 125 any // mx1apvio02
    server 135 any // mx1apvio02
    server 155 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L1000000000000/hdisk5 mx1apvio02
    server 165 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L2000000000000/hdisk6 mx1apvio02
    server 175 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L3000000000000/hdisk7 mx1apvio02
    client 195 mx1apvio02 195 none mx1pocdb01
    server 35 any 0x8100000000000000//pocap01lv mx1apvio02
    server 45 any 0x8100000000000000//pocap02lv mx1apvio02
    server 55 any 0x8100000000000000//pocap03lv mx1apvio02
    server 65 any 0x8100000000000000//pocdb01lv mx1apvio02
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01
    client 5 mx1apvio01 170 none mx1pocap03
    client 6 mx1apvio02 175 none mx1pocap03
    client 190 mx1apvio01 190 none mx1pocdb01
    client 195 mx1apvio02 195 none mx1pocdb01
    client 2 mx1apvio01 60 none mx1pocdb01
    client 3 mx1apvio02 65 none mx1pocdb01
    client 4 mx1apvio01 130 none mx1pocdb01

    Server9119590SN51A973E

    Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    server 130 any 0x8100000000000000//sdb02rootlv mx1apvio03
    server 140 any 0x8100000000000000//s73Eplmrootlv mx1apvio03
    client 190 mx1apvio03 190 none mx1pocdb02
    server 145 any 0x8100000000000000//i73Eplmrootlv mx1apvio04
    client 195 mx1apvio04 195 none mx1pocdb02
    server 65 any 0x8100000000000000//db02rootlv mx1apvio04
    client 190 mx1apvio03 190 none mx1pocdb02
    client 195 mx1apvio04 195 none mx1pocdb02
    client 2 mx1apvio04 65 none mx1pocdb02
    client 3 mx1apvio03 130 none mx1pocdb02

    Table of Contents

    NIM

    Network Information Manager Procedures

    Table of Contents

    Resource Group

    Resource Group Name Procedures

    Table of Contents

    WLM AIX 433

    Workload Manager for AIX 4.3.3.0 Procedures

    Table of Contents

    WLM AIX 5

    Workload Manager for AIX 5L Procedures

    Table of Contents

    VG Name

    Volume Group Name Procedures

    Table of Contents

    LV Name

    Logical Volume Name Procedures

    Table of Contents

    JFS Logs

    JFS Log Logical Volume Name Procedures

    Table of Contents

    FS Mt Point

    File System Mount Point Directory Name Procedures

    Table of Contents

    User/UID

    User Name Procedures

    Table of Contents

    Group/GID

    Group Name Procedures

    Table of Contents

    Security

    Security Procedures

    Table of Contents

    HACMP

    HACMP Procedures

    Table of Contents

    Installation

    Installation Procedures

    Table of Contents

    Monitoring

    Monitoring Procedures

    Table of Contents

    VIO WLM Enable

    Procedure to enable centralized statistics gathering from a VIO server via WLM

    The Virtual I/O (VIO) servers should not have extraneous software installed on them, therefore the performance toolbox software is not installed or enabled. However the Workload Manager (WLM) is installed and should be enabled in passive mode. The procedure to enable WLM on the VIO servers follows:

    This procedure assumes there is a centralized storage location for the WLM statistics shared to the VIO server via NFS. In the following example the centralized storage is located on the MX1 NIM server whose hostname is "mx1apnim01". The specific directory being shared via NFS from "mx1apnim01" is "/prfdmce0".

    This procedure also uses an example VIO server hostname of "mx1advio01".

    Establish the NFS mount from the centralized NFS storage location.

    /usr/sbin/mknfsmnt -f /prfdmce0 -d /prfdmce0 -h mx1apnim01-mc2 -M sys -t rw -w bg -ABSXYZ -jqg

    Add a directory to the centralized NFS storage location to contain the statistics files from the VIO server.

    mkdir -p /prfdmce0/ddadvio01/wlm

    Add a record line to "/etc/inittab" to start the WLM statistics gathering daemon

    mkitab 'ptxwlm:2:respawn:/usr/bin/xmwlm -d /prfdmce0/mx1advio01/wlm -n xmwlm > /dev/null 2>&1'

    Start the WLM in "passive" mode.

    /usr/sbin/wlmcntrl -p > /dev/console 2>&1

    Add a record to the "/etc/inittab" to start the WLM at system boot time.

    mkitab -i rc 'wlm:2:once:/usr/sbin/wlmcntrl -p > /dev/console 2>&1'

    Table of Contents

    WLM AIX 433

    Workload Manager for AIX 4.3.3.0 Standards

    This document describes the Workload Manager implementation standards on AIX 4.3.3.0 machines only.

    For WLM implementation on AIX version 5 systems, see the AIX 5 WLM standards document.

    The workload manager (WLM) shall be implemented on all AIX systems. On most systems WLM will be running in "passive" mode, which does not limit resources. In MtXia's environment, only a few selected systems will have WLM implemented in "active" mode to control and regulate resources. If there is any question as to whether WLM should be implemented in "active" or "passive" mode, default to "passive".

    The WLM provides a mechanism to classify and segment resources by process, user, group, etc. The classification scheme must be constructed by the AIX system administrator. This WLM classification scheme in the MtXia environment is based on the concept of the Resource Group. Each Resource Group will be represented in WLM as a class. Multiple instances of an application within a single resource group shall be represented in WLM as subclasses.

    In order to configure WLM, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a WLM class must be defined using the resource group name as the WLM class name.

    To define a new WLM class using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Add a class" to define a new WLM class.

                                  Workload Management

Move cursor to desired item and press Enter.

  List all Classes
  Add a Class
  Change / Show Characteristics of a Class
  Remove a Class
  Class Assignment Rules
  Start/Stop/Update WLM

    Enter the resource group name as the WLM class name, and provide a description of this WLM class. The Tier level will normally be 0 (zero) unless there is a specific reason to change this. The CPU and Memory values will be defaulted to a minumum of 0% and a maximum value of 100%.

                                      Add a Class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
  Class name                                         [atladtu1]
  Description                                        [Atlas pre-prod Database for Mt Xia, instance 1]
  Tier                                               [0]
  Minimum CPU time (%)                               [0]
  Maximum CPU time (%)                               [100]
  Shares of CPU                                      [1]
  Minimum Memory (%)                                 [0]
  Maximum Memory (%)                                 [100]
  Shares of Memory                                   [1]

    Class rules are used to determine which processes are assigned to which WLM classes and the order of the rules is significant. The first rule that matches is used to determine the WLM class assignment, so the class rules should be ordered from highly specific to less specific.

    To define WLM class rules using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Class assignment rules" to define a new WLM class.

                                  Workload Management

Move cursor to desired item and press Enter.

  List all Classes
  Add a Class
  Change / Show Characteristics of a Class
  Remove a Class
  Class Assignment Rules
  Start/Stop/Update WLM

    Select "Class assignment rules" to define a new WLM class rule.

                                 Class Assignment Rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule

    In the following example, a rule is defined to assign all processes owned by oracl817 to the the WLM class "atladtu1". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                                   Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the Rule                                  [1]
* Class                                              [atladtu1]
  User                                               [oracl817]
  Group                                              [-]
  Application                                        [-]

    Under AIX 4.3.3.0, to start WLM in passive mode, it must be done from the command line. If WLM is started from "smitty", it will be started in "active" mode. So to be safe and exact, always start/stop WLM from the command line using the appropriate flags.

    To start WLM from the command line in "passive" mode: 

    wlmcntrl -p

    To start WLM from the command line in "active" mode: 

    wlmcntrl -a

    To stop WLM from the command: 

    wlmcntrl -o

    Any changes to the WLM configuration will require that WLM be stopped and restarted in order for the changes to take effect.

    An example WLM configuration of the Atlas pre-production Database server for Mt Xia follows. The "standard" WLM configuration for this machine contains five WLM classes. It is important to recognize that the "standard" WLM configuration will be different for every machine. The term "standard" is used in reference to the local machine, this is not enterprise wide terminology used here.

    The AIX 4.3.3.0 WLM does not support the concept of subclasses, therefore multiple instances of an application will likely be configured as multiple WLM classes, requiring multiple resource groups. Since the AIX 4.3.3.0 WLM does not support subclasses, the WLM configuration will be different between AIX 4.3.3.0 and AIX 5.X systems.

  • mx1adatl01:/etc/wlm/standard/classes 
    System:

Default:

atladtu1:
        description = "Atlas pre-prod Database for Mt Xia, AMST instance"

atladtu2:
        description = "Atlas pre-prod Database for Mt Xia, C2KR instance"

atladtu3:
        description = "Atlas pre-prod Database for Mt Xia, ATLP instance"

    • The class rules associated with this "standard" configuration assign processes to multiple classes depending upon the user id. Rules are defined to segment the processes owned by the three oracle instances into separate WLM classes. All processes owned by "root" are assigned to the class "System", and all other processes are assigned to the class "Default".

  • mx1adatl01:/etc/wlm/standard/rules 
    * class   resvd  user      group  application
atladtu1  -      oracl817  -      -
atladtu2  -      oracle8i  -      -
atladtu3  -      oracle    -      -
System    -      root      -      -
Default   -      -         -      -

    • Table of Contents

    WLM AIX 5

    Workload Manager for AIX 5L Standards

    This document describes the Workload Manager implementation standards on AIX version 5 machines only.

    For WLM implementation on AIX version 4.3.3.0 systems, see the AIX 4.3.3.0 WLM standards document.

    The workload manager (WLM) shall be implemented on all AIX systems. On most systems WLM will be running in "passive" mode, which does not limit resources. In MtXia's environment, only a few selected systems will have WLM implemented in "active" mode to control and regulate resources. If there is any question as to whether WLM should be implemented in "active" or "passive" mode, default to "passive".

    The WLM provides a mechanism to classify and segment resources by process, user, group, etc. The classification scheme must be constructed by the AIX system administrator. This WLM classification scheme in the MtXia environment is based on the concept of the Resource Group. Each Resource Group will be represented in WLM as a class. Multiple instances of an application within a single resource group shall be represented in WLM as subclasses.

    In order to configure WLM, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a WLM class must be defined using the resource group name as the WLM class name.

    To define a new WLM class using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Add a class" to define a new WLM class.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Enter the resource group name as the WLM class name, and provide a description of this WLM class. The Tier level will normally be 0 (zero) unless there is a specific reason to change this. The "Resource Set Inheritance" value will normally be set to "Yes".

    The user and group values will be dependent upon the nature of the resource group. It may be desirable to specify a non-root user and group that is permitted to administer the WLM class and/or assign processes to the class. This will have to be determined on a resource group by resource group basis. If this information is unknown, default to "root" for the user values and "system" for the group values.

    
                       General characteristics of a class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                         [Entry Fields]
* Class name                                             [egapdtu1]
  Description                                            [EGATE Production Database for Mt Xia, Instance 0]
  Tier                                                   [0]
  Resource Set                                          
  Inheritance                                            [Yes]
  User authorized to assign its processes to this class  [oracle]
  Group authorized to assign its processes to this class [dba]
  User authorized to administrate this class             [root]
  (Superclass only) 
  Group authorized to administrate this class            [system]
  (Superclass only)
  Localshm                                               [No]

    Class rules are used to determine which processes are assigned to which WLM classes and the order of the rules is significant. The first rule that matches is used to determine the WLM class assignment, so the class rules should be ordered from highly specific to less specific.

    To define WLM class rules using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Class assignment rules" to define a new WLM class.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select "Class assignment rules" to define a new WLM class rule.

                                 Class assignment rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule 
  Attribute value groupings

    In the following example, a rule is defined to assign all processes owned by oracle or the group dba to the the WLM class "egapdtu1". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                                   Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the rule                                  [1]
* Class name                                          [egapdtu1
* User                                               [oracle]
* Group                                              [dba]
  Application                                        [-]
  Type                                               [-]
  Tag                                                [-]

    To define a new WLM subclass using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Add a class" to define a new WLM subclass.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    When defining a subclass, again enter the resource group name, followed by a period (.) followed by the name of the subclass to create. The Tier level will normally be 1 (one) for a subclass, unless there is a specific reason to change this. The "Resource Set Inheritance" value will normally be set to "Yes".

    The user and group values will be dependent upon the nature of the resource group. It may be desirable to specify a non-root user and group that is permitted to administer the WLM class and/or assign processes to the class. This will have to be determined on a resource group by resource group basis. If this information is unknown, default to "root" for the user values and "system" for the group values.

    
                       General characteristics of a class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                         [Entry Fields]
* Class name                                             [egapdtu1.oracleex511]
  Description                                            [EGATE Production Database for Mt Xia, Instance 511]
  Tier                                                   [1]
  Resource Set                                          
  Inheritance                                            [Yes]
  User authorized to assign its processes to this class  [oracle]
  Group authorized to assign its processes to this class [dba]
  User authorized to administrate this class             [root]
  (Superclass only) 
  Group authorized to administrate this class            [system]
  (Superclass only)
  Localshm                                               [No]

    To define a class rule for a subclass requires an additional step. First select a set of WLM subclasses to work on, then define the rule. To define a rule for a WLM subclass using smitty, start smitty using the "wlm" fastpath.

    smitty wlm

    Select "Work on a set of Subclasses" to select the subclass for which to define a rule.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets

  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)

  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select the WLM class that contains the subclass for which the rule will be defined, press enter, then return to the main WLM menu.

                                Select a Superclass or -

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Superclass name                                    [egapdtu1]

    Select "Class assignment rules" to define a new WLM subclass rule.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select "Class assignment rules" to define a new WLM subclass rule.

                                 Class assignment rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule 
  Attribute value groupings

    In the following example, a rule is defined to assign all processes owned by oracle or the group dba to the the WLM subclass "egapdtu1.oracleex511". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                                   Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the rule                                  [1]
* Class name                                          oracleex511
* User                                               [oracle]
* Group                                              [dba]
  Application                                        [-]
  Type                                               [-]
  Tag                                                [-]

    After all classes, subclasses, and rules have been defined, start WLM.

    smitty wlm

    Select "Work on a set of Subclasses" to select the subclass for which to define a rule.

                                    Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets

  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)

  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

    Select "Start Workload Manager"

                                 Start/Stop/Update WLM

Move cursor to desired item and press Enter.

  Start Workload Manager
  Update Workload Manager
  Stop Workload Manager
  Show WLM status

    For the options on this page, select the "current" configuration set, choose the "Passive" management mode, and choose "Both" for the start option. 

                                 Start Workload Manager

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Configuration, or for a set: set name/currently     current
      applicable configuration
  Management mode                                     Passive
  Enforce Resource Set bindings                       Yes
  Disable class total limits on resource usage        Yes
  Disable process total limits on resource usage      Yes
  Start now, at next boot, or both ?                  Both

    Any subsequent changes to the WLM configuration will require that WLM be stopped and restarted in order for the changes to take effect.

    An example WLM configuration of the EGATE Production Database server for Mt Xia follows. The "standard" WLM configuration for this machine contains a single WLM class called "egapdtu1". It is important to recognize that the "standard" WLM configuration will be different for every machine. The term "standard" is used in reference to the local machine, this is not enterprise wide terminology used here.

  • mx0apega01:/etc/wlm/standard/classes 
    System:

Default:

Shared:

egapdtu1:
        description = "Oracle Concurrent"
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"
        adminuser = "root"
        admingroup = "system"

    • The class rules associated with this "standard" configuration assign any processes owned by "oracle" or by the group "dba" to the WLM class "egapdtu1". All processes owned by "root" are assigned to the class "System", and all other processes are assigned to the class "Default".

  • mx0apega01:/etc/wlm/standard/rules 
    *class    resvd   user    group   application     type    tag
egapdtu1  -       oracle  dba     -               -       -       
System    -       root    -       -               -       -       
Default   -       -       -       -               -       -

    • Multiple subclasses are defined for the class "egapdtu1". These subclasses are intended to segment the processes by oracle instance. The definition of subclasses will be customized for each individual resource group.

  • mx0apega01:/etc/wlm/standard/egapdtu1/classes 
    Default:

Shared:

oracleex011:
        description = "Instance ex011"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex061:
        description = "Instance ex061"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex071:
        description = "Instance ex071"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleexa11:
        description = "Instance a11"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex031:
        description = "Instance ex031"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex041:
        description = "Instance ex041"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

oracleex051:
        description = "Instance ex051"
        tier   = 1
        inheritance = "yes"
        authuser = "oracle"
        authgroup = "dba"

    • The rules associated with each subclass of the class "egapdtu1" associate all processes owned by "oracle" or the group "dba" to the subclass. In this instance the processes are not automatically assigned to subclasses by WLM, instead they are assigned by the oracle startup script.

  • mx0apega01:/etc/wlm/standard/egapdtu1/rules 
    *class          resvd   user    group   application     type    tag
oracleex011     -       oracle  -       -               -       -       
oracleex031     -       oracle  -       -               -       -       
oracleex041     -       oracle  -       -               -       -       
oracleex051     -       oracle  -       -               -       -       
oracleex061     -       oracle  -       -               -       -       
oracleex071     -       oracle  -       -               -       -       
oracleexa11     -       oracle  -       -               -       -

    • Table of Contents

    Patch Management

    Patch Management Procedures
    -
    Overview
    -
     

    LPAR Leasing
    Lease an AIX / i5 LPAR
    Reduce your costs
    www.mtxia.com

    Server Leasing
    Lease a Server off-site
    Reduce your costs
    www.mtxia.com

    Data Center Automation
    Business Continuity and DR
    Virtualization/Consolidation
    www.mtxia.com

    HMC Service
    Hardware Management Console
    Manage Remote AIX / i5 LPARs
    www.siteox.com

    Business Web Site Hosting
    $3.99 / month includes Tools,
    Shopping Cart, Site Builder
    www.siteox.com

    FREE Domain Registration
    included with Web Site Hosting
    Tools, Social Networking, Blog
    www.siteox.com

    Disaster Recovery
    Small Business Oriented
    Off-Site Facilities
    www.mtxia.com

    IBM pSeries / iSeries
    Reduce your Costs
    Off-Site Server Hosting
    www.mtxia.com