Must know page about AIX and Related technologies

1. AIX Booting Process explained below.
   
   
   I. Read Only Storage Kernel Init Phase
   
   
   Motherboard is Checked - POST --> look for Bootlist if found (Detected by ROS)------> look for boot image---Bootstrap code is loaded from disk
   
   
   - BLV contains AIX Kernel, rc.boot scripts, reduced ODM, and boot commands.
   - BLV get uncompressed in RAM and kernel gets released from it.
   - Then AIX kernel gets the control
   - AIX Kernel creates a RAMFS
   - Kernel Starts the init process from BLV
   - init executes rc.boot script from the BLV in the RAM
   
   
   II. Base Device Configuration Phase
   
   
   1. All devices are configured with cfgmgr command - init process from RAMFS executes rc.boot 1
   
   
   - restbase command copies ODM from BLV to RAMFS
   - cfgmgr will run and configure all the base devices
   
   
   III. System Boot Phase
   
   
   1. Logical volumes are varied on - rc.boot 2 is executed.
   
   
   - ipl_varyon will varyon the rootvg
   - run fsck on / and mount the same to RAMFS
   - run fsck on /usr and mount the same to RAMFS
   - run fsck on /var and mount the same to RAMFS
   
   
   2. Paging is started - copycore command checks the occurrunce of the dump and copies the same from primary dump device to /var/ras/adm
   
   
   - unmount /var and activate the paging space
   - mount /var
   - Now /, /usr and /var are mounted in rootvg in hdisk
   
   
   3. /etc/inittab is processed - Kernal remove RAMFS
   
   
   - init process is started from / in rootvg
   - in rc.boot3, init processes /etc/inittab and remaining devices are configured.
   - /etc/init starts /etc/inittab and runs /sbin/rc.boot 3
   - run fsck on /tmp and mount the same.
   - syncvg for rootvg and reports the stale PPs
   
   
   4. Relevant Services according to run level starts. srcmstr daemon controls this - starts the deamons like errdaemon, syncd etc..
   
   
   
   
   * AIX 6.1, November 9, 2007
   o Workload Partitions o Live Application Mobility
   o Role Based Access Control RBAC o AIX Security Expert hardening tool
   o Trusted AIX o Encrypting JFS2 filesystem
   o Trusted Execution o Concurrent Kernel Maintenance
   o Kernel exploitation of POWER6 storage keys o probevue dynamic tracing
   o Systems Director Console for AIX o Integrated filesystem snapshot
   o Partition mobility on POWER6
   
   
   * AIX 5L 5.3, August 13, 2004
   o NFS Version 4 support o Advanced Accounting
   o Virtual SCSI o Virtual Ethernet
   o Simultaneous multithreading (SMT) support o Micro-Partitioning support
   o POWER5 support o JFS2 quota support
   o JFS2 filesystem shrink support
   
   
   * AIX 5L 5.2, October 18, 2002
   o Introduced support for the IBM BladeCenter JS20 with the PowerPC 970.
   o Minimum level required for POWER5 hardware
   o Support for MPIO Fibre Channel disks
   o iSCSI Initiator software
   o Dynamic LPAR support
   * AIX 5L 5.1, May 4,2001
   o Introduced support for the IA-64 architecture, although this never went beyond beta,[1]
   o Minimum level required for POWER4 hardware and the last release that supported Micro Channel architecture
   o Introduction of 64-bit kernel, installed but not activated by default
   o JFS2
   o introduced Logical Partitioning on POWER4
   o The L stands for Linux affinity
   o Trusted Computing Base (TCB)
   
   
   Startup Mode
   Normal Mode
   Login Prompts
   All processes running
   Multi User Mode
   System Management Services
   Not AIX
   Runs from firmware
   sets boot list
   Maintainance Mode
   Maintainance Menu
   Recover root password
   Fix machines that wont boot
   Dignostic
   AIX diagnostic
   
   
   If device state is
   
   
   undefined------>Supported Devices------->Predefined Database
   defined--------->Not Usable------------------>Customized Database
   Available--- --->Ready for use-------------->Customized Database
   
   
   Seven types supported:
   Journaled File System (JFS)
   Enhanced Journaled File System (JFS2)
   CD-ROM File System (CDRFS)
   DVD-ROM File System (UDFS)
   Network File System (NFS)
   Common Internet Filesystem (CIFS)
   Proc File System (PROCFS)
   
   
   Defaults Lvs and Filesystems on it
   
   
   AIX Installation method
   New and Complete Overwrite Installation:
   You have a new machine without a prior or useful system installation. You want to install onto a hard disk that contains an existing root volume group that you wish to completely overwrite. You want to reassign your hard disks, that is, to make your rootvg smaller and assign less disk space to it.
   Migration installation
   Use the migration installation method to upgrade AIX Version 4.2, 4.3, AIX 5L Version 5.1, or Version 5.2 to AIX 5L Version 5.3 while preserving the existing root volume group. The installation process determines which optional software products must be installed. With the exception of /tmp, this method preserves most file systems, including the root volume group, logical volumes, and system configuration files.
   Preservation installation
   Use the preservation installation method when a version of the BOS is installed on your system, and you want to preserve the user data in the root volume group. However, this method overwrites the /usr, /tmp, /var, and / (root) file systems by default, so any user data in these directories is lost. These file systems are removed and recreated, so any other LPPs or filesets that you installed on the system will also be lost. System configuration must be done after doing a preservation installation.
   The /etc/preserve.list file contains a list of system files to be copied and saved during a preservation BOS installation. The /etc/filesystems file is listed by default. You can add the full path names of any additional files that you want to
   save during the Preservation installation to the preserve.list file.
   
   
   Trusted Computing Base
   The Trusted Computing Base (TCB) is the part of the system that is responsible for enforcing the information security policies of the system. By installing a system with the TCB option, you enable the trusted path, trusted shell, trusted
   processes, and system-integrity checking. Because every device is part of the TCB, every file in the /dev directory is monitored by the TCB
   
   
   Network Installation Management
   Network Installation Management (NIM) allows you to manage an automated installation of the Base Operating System (BOS) and optional software on one or more machines. You can install a group of machines with a common configuration or customize an installation for your specific needs. The number of machines you can install simultaneously depends on the throughput of your network, the disk access throughput of the installation servers, and the platform type of your servers.
   The types of machines that can be managed in the NIM environment are stand-alone, diskless, and dataless clients.
   NIM resource objects represent files and directories that are used to support some type of NIM operation a copy of the current running rootvg to another disk, be sure to have all the file systems mounted that you want cloned across.
   
   
   Alternate Disk Installation
   Alternate disk installation, available starting with AIX Version 4.3, allows for system installation on a system while it is still up and running. Install or upgrade downtime decreases considerably. It also allows large facilities to manage an
   upgrade, while the systems are still running at the existing version. The switch over to the new version can then happen with a simple reboot, with the possibility to roll back to the original situation in case of problems.
   Cloning the rootvg to an alternate disk has many advantages. One advantage is having an online backup available, as in the case of a disk crash. Keeping an online backup requires an extra disk or disks to be available on the system. where altinst_rootvg is the cloned non-active/varied off rootvg. The cloned rootvg has all its logical volumes prefixed with the name 'alt'. The boot list is also changed to boot off altinst_rootvg. AIX likes to do things like this; it assumes you will want to boot off the cloned and not the real rootvg.
   Alternate disk installation can be used in one of two ways:
   1) Cloning the current running rootvg to an alternate disk. smitty alt_clone
   2) Installing a mksysb image on another disk. smitty alt_mksysb
   With a mksysb image, you can clone one system image onto multiple target systems. However, the target systems might not contain the same hardware.
   
   
   By default, using the alt_disk_install command does the following:
   1. Creates an /image.data file based on the current rootvg's configuration. A customized image.data file can be used.
   2. Creates an alternate rootvg (altinst_rootvg).
   3. Creates logical volumes and file systems with the alt_inst prefix.
   4. Generates a backup file list from the rootvg, and if an exclude.list file is given, those files are excluded from the list.
   5. Copies the final list to the altinst_rootvg's file systems.
   6. If specified, the installp command installs updates, fixes, or new filesets into the alternate file system.
   7. The bosboot command creates a boot logical volume on the alternate boot disk.
   8. If a customization script is specified, it runs at this point.
   9. The file systems are then unmounted, and the logical volumes and file systems are renamed.
   10.The logical volume definitions are exported from the system to avoid confusion with identical ODM names, but the altinst_rootvg definition is left as an ODM placeholder.
   11.By default, the bootlist is set to the new cloned rootvg for the next reboot.
   
   
   Maintenance Level
   A Maintenance Level (ML) is the service updates that are necessary to upgrade the base operating system (BOS) or an optional software product to the current release level.
   
   
   Technology Level
   A Technology Level (TL) is the new term for the twice yearly AIX 5L releases, which contain new hardware and software features and service updates. The first TL will be restricted to hardware features and enablement, as well as software service. The second TL will include hardware features and enablement, software service, and new software features.
   
   
   Fileset
   A fileset is the smallest installable base unit for the AIX 5L operating system.
   
   
   Package
   A package is a group of separately installable filesets that provide a set of related functions. For example, bos.net is a package
   
   
   Licensed Program Product
   A Licensed Program Product (LPP) is a complete software product including all packages associated with that licensed program. For example, the BOS is a licensed program.
   
   
   Bundle
   A bundle is a list of software that can contain filesets, packages, and LPPs that are suited for a particular use, such as providing personal productivity software or software for a client machine in a network environment
   
   
   PTF
   PTF is an acronym for Program Temporary Fix. A PTF is an updated fileset or a new fileset that fixes a previous system problem. PTFs are installed in the same way as regular filesets by the use of the installp command
   
   
   APAR
   APAR is an acronym for Authorized Program Analysis Report. An APAR is an emergency fix, or interim fix, to a unique problem on the system. APARs will eventually become PTFs after testing and verification. APARs are applied to the
   system through the use of the instfix command
   
   
   Applied State
   The applied state places software on the system and retains the previous version of the software. When an update is in the applied state, the previous version is stored in the /usr/lpp/PackageName directory, where PackageName could be bos.net which is a package.
   
   
   Commited State
   The committed state places software on the system and removes all previous levels of the software from the /usr/lpp/PackageName directory. If committed software needs to be removed, you cannot go back to the previous version without a complete reinstall of the previous version software.
   
   
   SUMA
   automatic download, scheduling, and notification capabilities through the new Service Update Management Assistant (SUMA) tool
   
   
   Object Data Manager
   The ODM is a repository in which the operating system keeps information regarding your system, such as devices, software, or TCP/IP configuration. The ODM is an object-oriented database that contains vital data, keeps this data
   consistent with the actual state of the system, and prevents the administrator from altering it by mistake.
   System data managed by the ODM includes:
   Device configuration information
   Display information for SMIT (menus, selectors, and dialogs)
   Vital product data for installation and update procedures
   Communication configuration information
   System resource controller data information
   Error log and dump information
   Network Installation Manager (NIM) information
   ODM data is stored in binary format. You cannot modify ODM files with a text editor. You must use special commands that are designed to interact with the ODM.
   
   
   The basic components of the ODM are
   Object classes Each file of the database is an object class. Each object class consists of objects having similar definitions.
   Objects Each object is one record in an object class. It is a stand-alone entity and has one or more descriptors.
   Descriptors The descriptors describe the layout of the objects. They determine the name and data type of the fields that are part of the object class. The descriptors of an object and their associated values can be located and changed using ODM commands.
   
   
   ODM information is divided in three parts in order to support diskless or dataless systems. The names of these three directories as follows:
   /usr/lib/objrepos Contains the predefined objects classes, SMIT menu object classes and the four object classes used by SWVPD for the /usr part of the installable software product. The object classes in this repository can be shared across the network by /usr clients, dataless and diskless workstations. Software installed in the /usr part can be shared among several machines with compatible hardware architecture.
   
   
   /usr/share/lib/objrepos Contains the four object classes used by the SWVPD for the /usr/share part of the installable software product. The /usr/share part of a software product contains files that are not hardware dependent. They can be shared among several systems, even if these have a different hardware architecture. An example are terminfo files that describe terminal capabilities. Because terminfo is used on many UNIX systems, terminfo files are part of the /usr/share part of the software product.
   
   
   /etc/objrepos Contains the customized devices object classes and the four object classes used by SWVPD for the / part of the installable software product. To access information in the other directories, this directory contains symbolic links to the predefined devices object classes. These links are needed because the ODMDIR variable points to only
   /etc/objrepos. It contains the part of the product that cannot be shared with other systems. Most of this
   software requiring a separate copy for each machine is associated with the configuration of the machine or
   product.
   
   
   The ODM commands are:
   odmadd Adds objects to an object class.
   odmchange Changes specific objects in a specified object class.
   odmcreate Creates empty object classes.
   odmdelete Removes objects from an object class.
   odmdrop Removes an entire object class.
   odmget Retrieves objects from object classes and puts the object information into odmadd command format.
   odmshow Displays the description of an object class.
   
   
   System Management Interface Tool
   System Management Interface Tool (SMIT) provides an alternative to the typical method of using complex command syntax, valid parameter values, and custom shell path names for managing and maintaining your operating
   system configuration.
   Software Installation and Maintenance
   Software License Management
   Devices
   System Storage Management (Physical & Logical Storage)
   Security & Users
   Communications Applications and Services
   Print Spooling
   Advanced Accounting
   Problem Determination
   Performance & Resource Scheduling
   System Environments
   Processes & Subsystems
   Applications
   Installation Assistant
   Cluster Systems Management
   Using SMIT (information only)
   
   
   SMIT runs in two modes: ASCII (non-graphical) and X-Window (graphical). ASCII SMIT can run on both terminals and graphical displays. The graphical mode, which supports a mouse and point-and-click operations, can be run only on a
   graphical display and with X-Window support. The ASCII mode is often the preferred way to run SMIT because it can be run from any machine.
   To start the ASCII mode, type at the command line:
   smitty or smit -a
   To start the graphical mode, type:
   smit or smit -m
   SMIT is an interactive, menu-driven user interface that allows you to more easily perform routine system management tasks and to manage and maintain your operating system configuration.
   
   
   SMIT uses three types of screens: menu, selector, and dialog screens. Menu screens display a list of items that you can select. Selector screens, often presented as a pop-up menu, display a list of items from which you specify or select a particular item Dialog screens are the interface to a command or task that you perform
   
   
   Trusted Program,
   A trusted program, or trusted process, is a shell script, a daemon, or a program that meets a particular standard of security.
   Examples of trusted daemons are:
   _ ftpd
   _ rexecd
   _ telnetd
   Examples of non-trusted daemons are:
   _ rshd
   _ rlogind
   _ tftpd
   
   
   Bootlist Command
   The bootlist command allows the user to display and alter the list of possible boot devices from which the system may be booted. This command supports the updating of the following:
   Normal boot list The normal list designates possible boot devices for when the system is booted in normal mode.
   Service boot list The service list designates possible boot devices for when the system is booted in service mode.
   Previous boot device This entry designates the last device from which the system booted. Some hardware platforms may attempt to boot from the previous boot device before looking for a boot device in one of the other lists.
   
   
   Network Configuration Files
   $HOME/.netrc
   The $HOME/.netrc file contains information used by the automatic login feature of the rexec and ftp commands. It is a hidden file in a user's home directory and must be owned either by the user executing the command or by the root user.
   $HOME/.forward
   When mail is sent to a local user, the sendmail command checks for the $HOME/.forward file for that user. The $HOME/.forward file can contain one or more addresses or aliases. Any messages are then sent to the addresses or
   aliases in the $HOME/.forward file.
   /etc/hosts.equiv and $HOME/.rhosts
   The /etc/hosts.equiv file, along with any local $HOME/.rhosts files, defines the hosts (computers on a network) and user accounts that can invoke remote commands on a local host without supplying a password. A user or host that is
   not required to supply a password is considered trusted, though the daemons that initiate the connections may be non-trusted in nature (for example, rlogind).
   
   
   Intreduction to rc.* files
   rc.boot file
   The /sbin/rc.boot file is a shell script that is called by the simple shell init and the standard init command to bring up a system. It controls the machine boot process. When the system is booting, the /sbin/rc.boot file is called on each boot
   phases, each time being passed a different parameter.
   Depending upon the type of boot device, the rc.boot file configures devices and also calls the appropriate applications.
   Appropriate applications include:
   _ Booting from disk (boot phase 1)
   _ Varying on a root volume group (boot phase 2)
   _ Enabling file systems (boot phase 2)
   _ Calling the BOS installation programs or diagnostics
   /etc/rc file
   The /etc/rc file performs normal startup initialization; its entry in the /etc/inittab file is located after the rc.boot entry. The init command reads the /etc/inittab file and creates a process for the /etc/rc file. The contents of the /etc/rc file are installation specific. If all of the necessary operations complete successfully, the file exits with a zero return code that allows the init command to start loggers to complete normal initialization and startup.
   Many bringup functions are done by the /etc/rc file, such as:
   _ Vary on all volume groups marked as auto-varyon.
   _ Activate all paging spaces listed on /etc/swapspaces (using the swapon –a command).
   _ Configure all dump devices (using the sysdumpdev -q command).
   _ Perform file system checks (using the fsck -fp command).
   _ Perform mounting of file systems marked as mount=true on the /etc/filesystems file (using the mount all command).
   rc.net file
   The /etc/rc.net file is a shell script that contains network configuration information The stanzas allow you to enable the network interfaces and set the host name, the default gateway, and any static routes for the current host. This file can be used as a one-step configuration alternative to using individually the set of commands and files necessary to configure a host.
   The rc.net shell script is run by the configuration manager program during the second phase of configuration. If TCP/IP is installed, a second script, rc.tcpip, is run from the init command after the second phase of configuration has completed and after the init command has started the SRC master.
   rc.tcpip file
   The /etc/rc.tcpip file is a shell script that, when executed, uses SRC commands to initialize selected daemons. The rc.tcpip shell script is automatically executed with each system restart. It can also be executed at any time from the command line.
   Most of the daemons that can be initialized by the rc.tcpip file are specific to TCP/IP. These daemons are:
   _ inetd (started by default)
   _ gated
   _ routed
   _ named
   _ timed
   _ rwhod
   /etc/tcp.clean can be used to stop TCP/IP daemons.
   
   
   System boot without starting rc.tcpip
   Removing the rc.tcpip entry in /etc/inittab means that you are not starting any server applications during IPL.
   Without the server applications started, you will not be able to telnet or ftp to this machine from another host.
   However, as long as you have not brought down the network interface, you can still utilize the client network services. You can still ping other hosts, and you can still telnet or ftp to other hosts.
   
   
   The /etc/services file
   The /etc/services file contains information about the known services used in the DARPA Internet network by inetd. Each service listed in /etc/services runs on a specific port number for communications, in a specific format, such as TCP or UDP.
   If you edit the /etc/services file, run the refresh -s inetd command, in order for your changes to be used.
   
   
   File System Issues
   
   
   
   
   
   
   
   
   Network File System
   The Network File System (NFS) is a distributed file system that allows users to access files and directories of remote servers as though they were local. For example, you can use operating systems commands to create, remove, read,
   write, and set file attributes for remote files and directories. NFS is independent of machine types, operating systems, and network architectures because of its use of remote procedure calls (RPC) for these services.
   For the successful implementation of an NFS environment, you need the following things:
   1. The NFS daemons should be running on the server and the clients.
   2. The file systems that need to be remotely available will have to be exported.
   3. The exported file systems need to be mounted on the remote (client) systems.
   
   
   The following are a list of terms that are used throughout this discussion:
   Server A computer that makes its file systems, directories, and other resources available for remote access.
   Clients The computers, or their processes, that use a server’s resources.
   Export The act of making file systems available to remote clients.
   Mount The act a client needs to do to access the file systems that a server exports.
   
   
   The following describes the mounting process:
   When the server starts, the /etc/rc.nfs script runs the exportfs command, which reads the server /etc/exports file and then tells the kernel which directories are to be exported and which access restrictions they require.
   The rpc.mountd daemon and several nfsd daemons (eight, by default) are then started by the /etc/rc.nfs script.
   When the client starts, the /etc/rc.nfs script starts several biod daemons (eight, by default), which forward client mount requests to the appropriate server.
   Then the /etc/rc.nfs script executes the mount command, which reads the file systems listed in the /etc/filesystems file.
   The mount command locates one or more servers that export the information the client wants and sets up communication between itself and that server. This process is called binding.
   The mount command then requests that one or more servers allow the client to access the directories in the client /etc/filesystems file.
   The server rpc.mountd daemon receives the client mount requests and either grants or denies them. If the requested directory is available to that client, the rpc.mountd daemon sends the client's kernel an identifier called a file handle.
   The client kernel then ties the file handle to the mount point (a directory) by recording certain information in a mount record.
   
   
   There are three types of NFS mounts: predefined, explicit, and automatic.
   Predefined mounts are specified in the /etc/filesystems file.
   Explicit mounts are usually made for short periods of time when there is a requirement for occasional unplanned mounts. There is no entry for shared file system in /etc/filesystems
   Automatic mounts are controlled by the automount command, which causes the AutoFS kernel extension to monitor specified directories for activity. If a program or user attempts to access a directory that is not currently mounted, then AutoFSintercepts the request, arranges for the mount of the file system, and then services the request.
   
   
   The following describes the mounting process:
   1. When the server starts, the /etc/rc.nfs script runs the exportfs command, which reads the server /etc/exports file and then tells the kernel which directories are to be exported and which access restrictions they require.
   2. The rpc.mountd daemon and several nfsd daemons (eight, by default) are then started by the /etc/rc.nfs script.
   3. When the client starts, the /etc/rc.nfs script starts several biod daemons (eight, by default), which forward client mount requests to the appropriate server.
   4. Then the /etc/rc.nfs script executes the mount command, which reads the FS listed in the /etc/filesystems file.
   5. The mount command locates one or more servers that export the information the client wants and sets up communication between itself and that server. This process is called binding.
   6. The mount command then requests that one or more servers allow the client to access the directories in the client /etc/filesystems file.
   7. The server rpc.mountd daemon receives the client mount requests and either grants or denies them. If the requested directory is available to that client, the rpc.mountd daemon sends the client's kernel an identifier called a file handle.
   8. The client kernel then ties the file handle to the mount point (a directory) by recording certain information in a mount record.
   
   
   The inetd daemon
   The /usr/sbin/inetd daemon provides Internet service management for a network. This daemon reduces system load by invoking other daemons only when they are needed.
   If you change the /etc/inetd.conf using SMIT, then the inetd daemon will be refreshed automatically and will read the new /etc/inetd.conf file. If you change the file using an editor, run the
   # refresh -s inetd
   or
   # kill -1 InetdPID
   Existing sessions are not affected when the inetd daemon is stopped, but no new telnet and ftp sessions can be established without first restarting the inetd daemon.
   
   
   The portmap daemon
   The portmap daemon converts remote procedure call (RPC) program numbers into Internet port numbers.
   
   
   /etc/netsvc.conf Specifies default order for Host name resolutions
   /etc/hosts provides a list of server names or aliases and their IP addresses
   /etc/resolv.conf Name resolution file
   
   
   Maximum transmission unit:
   MTU size is critical for proper network communications. Packets that are too small in length may be lost during transmission. Packets that are too long in length may collide with other packets that are being transmitted. These factors can lead to slower transmission rates and other network problems as packets must then be retransmitted.
   
   
   
   
   To automate the NTP start after reboot:
   # vi /etc/inittab
   ntp:2:wait:/usr/bin/startsrc -sxntpd
   OR
   Uncommented the commented the line from /etc/rc.tcpip
   start /usr/sbin/xntpd "$src_running"
   
   
   
   
   Virtual Ethernet
   Virtual Ethernet enables inter-partition communication without the need for physical network adapters assigned to each partition. Virtual Ethernet allows the administrator to define in-memory connections between partitions handled at system level
   
   
   Paging Space.
   To accommodate a large virtual memory space with a limited real memory space, the system uses real memory as a work space and keeps inactive data and programs on disk. The area of the disk that contains this data is called the
   system paging space.
   *Do not allocate more than one paging space logical volume on a physical volume.
   *Avoid putting a paging space logical volume on a heavily active logical volume.
   *Make each paging space logical volume equal in size.
   *Do not extend a paging space logical volume onto multiple physical volumes.
   
   
   
   
   LVM Concepts
   The fundamental concepts used by LVM are physical volumes, volume groups, physical partitions, logical volumes, logical partitions, file systems, and raw devices. Some of their characteristics are presented as follows:
   Each individual disk drive is a named physical volume (PV) and has a name such as hdisk0 or hdisk1.
   One or more PVs can make up a volume group (VG). A physical volume can belong to a maximum of one VG.
   You cannot assign a fraction of a PV to one VG. A physical volume is assigned entirely to a volume group.
   Physical volumes can be assigned to the same volume group even though they are of different types, such as SCSI or SSA.
   Storage space from physical volumes is divided into physical partitions (Pps). The size of the physical partitions is identical on all disks belonging to the same VG.
   Within each volume group, one or more logical volumes (LVs) can be defined. Data stored on logical volumes appears to be contiguous from the user point of view, but can be spread on different physical volumes from the same
   volume group.
   Logical volumes consist of one or more logical partitions (LPs). Each logical partition has at least one corresponding physical partition. A logical partition and a physical partition always have the same size. You can have up to three
   copies of the data located on different physical partitions. Usually, physical partitions storing identical data are located on different physical disks for redundancy purposes.
   Data from a logical volume can be stored in an organized manner, having the form of files located in directories. This structured and hierarchical form of organization is named a file system.
   Data from a logical volume can also be seen as a sequential string of bytes. This type of logical volumes are named raw logical volumes. It is the responsibility of the application that uses this data to access and interpret it correctly.
   
   
   Volume Group Descriptor Area
   The volume group descriptor area (VGDA) is an area on the disk that contains information pertinent to the volume group that the physical volume belongs to. It also includes information about the properties and status of all physical and logical volumes that are part of the volume group. The information from VGDA is used and updated by LVM commands. There is at least one VGDA per physical volume. Information from VGDAs of all disks that are part of the
   same volume group must be identical. The VGDA internal architecture and location on the disk depends on the type of the volume group (original, big, or scalable).
   
   
   Volume Group Status Area
   The volume group status area (VGSA) is used to describe the state of all physical partitions from all physical volumes within a volume group. The VGSA indicates if a physical partition contains accurate or stale information. VGSA is used for monitoring and maintained data copies synchronization. The VGSA is essentially a bitmap and its architecture and location on the disk depends on the type of the volume group.
   
   
   Logical Volume Control Block
   A logical volume control block (LVCB) contains important information about the logical volume, such as the number of the logical partitions or disk allocation policy. Its architecture and location on the disk depends on the type of the volume group it belongs to. For standard volume groups, the LVCB resides on the first block of user data within the LV. For big volume groups, there is additional LVCB information in VGDA on the disk. For scalable volume groups, all relevant logical volume control information is kept in the VGDA as part of the LVCB information area and the LV entry area.
   
   
   
   
   Logical Track Group
   Logical track group (LTG) size is the maximum allowed transfer size for an I/O disk operation.
   # lquerypv -M hdisk0
   
   
   Quorum
   The quorum is one of the mechanisms that the LVM uses to ensure that a volume group is ready to use and contains the most up-to-date data.
   A quorum is a vote of the number of Volume Group Descriptor Areas and Volume Group Status Areas (VGDA/VGSA) that are active. A quorum ensures data integrity of the VGDA/VGSA areas in the event of a disk failure. Each physical disk in a volume group has at least one VGDA/VGSA. When a volume group is created onto a single disk, it initially has two VGDA/VGSA areas residing on the disk. If a volume group consists of two disks, one disk still has two VGDA/VGSA areas, but the other disk has one VGDA/VGSA. When the volume group is made up of three or more disks, then each disk is allocated just one VGDA/VGSA.
   A quorum is lost when at least half of the disks (meaning their VGDA/VGSA areas) are unreadable by LVM. In a two-disk volume group, if the disk with only one VGDA/VGSA is lost, a quorum still exists because two of the three VGDA/VGSA areas still are reachable. If the disk with two VGDA/VGSA areas is lost, this statement is no longer true. The more disks that make up a volume group, the lower the chances of quorum being lost when one disk fails.
   When a quorum is lost, the volume group varies itself off so that the disks are no longer accessible by the LVM. This prevents further disk I/O to that volume group so that data is not lost or assumed to be written when physical problems occur. Additionally, as a result of the vary-off, the user is notified in the error log that a hardware error has occurred and service must be performed.
   There are cases when it is desirable to continue operating the volume group even though a quorum is lost. In these cases, quorum checking can be turned off for the volume group. This type of volume group is referred to as a nonquorum volume group. The most common case for a nonquorum volume group occurs when the logical volumes have been mirrored. When a disk is lost, the data is not lost if a copy of the logical volume resides on a disk that is not disabled and can be accessed. However, there can be instances in nonquorum volume groups, mirrored or nonmirrored, when the data (including copies) resides on the disk or disks that have become unavailable. In those instances, the data might not be accessible even though the volume group continues to be varied on.
   
   
   Unlock VG
   A volume group can become locked after an abnormal termination of an LVM command. You can remove the lock using the chvg -u command.
   
   
   Journaled file system
   This type of file system is named journaled because the system uses journaling techniques to maintain the
   integrity of control structures. Each journaled file system must reside on a distinct jfs logical volume. Therefore, the
   file system size will be a multiple of the size of a logical partition.
   
   
   Enhanced journaled file system
   This is the enhanced version of the initial journalized file system. It uses extent based allocation to allow higher
   performance, larger file systems, and a larger file size. Each enhanced journaled file system must reside on a
   distinct jfs2 logical volume. When the operating system is installed using the default options, it creates JFS2 file
   systems.
   
   
   Controll Growing file
   /var/adm/wtmp
   /etc/security/failedlogin
   /var/adm/sulog
   /var/spool/*/*
   $HOME/smit.log
   $HOME/smit.script
   $HOME/websm.log
   $HOME/websm.script
   JFS and JFS2 Difference
   
   
   Superblock
   The superblock contains control information about a file system, such as the overall size of the file system in 512 byte blocks, the file system name, the file system log device, the version number, the number of inodes, the list of free
   inodes, the list of free data blocks, date and time of creation, and file system state. All this data is stored in the first logical block of the file system. Corruption of this data may render the file system unusable. This is why the system keeps a second copy of the superblock on logical block 31.
   
   
   Allocation group
   An allocation group consists of inodes and its corresponding data blocks. An allocation groups spans multiple adjacent disk blocks and improves the speed of I/O operations. Both JFS and JFS2 file systems use allocation groups. For a JFS file system, the allocation group size can be specified when the file system is created.
   
   
   Inodes
   The inode contains control information about the file, such as type, size, owner, and the date and time when the file was created, modified, or last accessed. It also contains pointers to data blocks that store the actual data of the file. Every file has a corresponding inode.
   For JFS file systems, the maximum number of inodes, and hence the maximum number of files, is determined by the number of bytes per inode (nbpi) value, which is specified when the file system is created. For every nbpi bytes of your file system, there will be an inode created. The total number of inodes is fixed. The nbpi values needs to be correlated with allocation group size. The JFS restricts all file systems to 16 MB (224) inodes. JFS2 file systems manages the necessary space for inodes dynamically so there is not any nbpi parameter.
   
   
   Data blocks
   Data blocks store the actual data of the file or pointers to other data blocks. The default value for disk block size is 4 KB.
   
   
   Fragments
   Fragments of logical blocks can be used to support files smaller than the standard size of the logical block (4 KB). This rule applies only to the last block of a file smaller than 32 KB.
   For JFS file systems only, you have the option to use compression to allow all logical blocks of a file to be stored as a sequence of contiguous fragments. Compression for a file system will increase the amount of CPU and I/O activity
   when using that file system. These features can be useful to support a large number of small files. Fragment
   size must be specified for a file system at installation time. Different file systems can have different fragment sizes.
   
   
   Device logs
   The journaled file system log stores transactional information about file system metadata changes.This data can be used to roll back incomplete operations if the machine crashes. JFS file systems are used for logging logical volumes of type jfslog, while JFS2 file systems are used for logging logical volumes of type jfs2log.
   Data from data blocks are not journaled. Log devices ensure file system integrity, not data integrity. After the operating system is installed, all file systems within the rootvg volume group use logical volume hd8 as a common log. You can create a JFS2 file system that can use inline logs. This means the log data is written into the same logical volume as the file system, and not into the log logical volume.
   Full backup
   All the files are put on media during a full backup.
   
   
   Differential Backup
   The differential backup strategy first looks for the modification time of a file and compares it with the last full backup time. In other words, only modified files are backed up, but only if they changed after the latest full backup. Differential backups are cumulative; once a file has been modified, it will be included in every differential backup until the next full backup.
   
   
   Incremental backups
   Incremental backups are similar to differential backups in that both back up only modified files. However, incremental backup checks the difference between the modification time of a file and the last backup time (either being full or
   incremental backup). If the modification date is more recent than the last backup date, the file is backed up.
   
   
   MKSYSB
   The mksysb command creates a bootable image of all mounted file systems on the rootvg volume group. You can use this backup command to restore a system to its original state. The tape format includes a BOS boot image, a BOS install image, and a dummy table of contents (TOC) followed by the system backup (root volume group) image. The root volume group image is in backup-file format, starting with the data files and then any optional map files.
   User-defined paging spaces, unmounted file systems, and raw devices are not backed up.
   
   
   The BOS boot image contains a copy of the system’s kernel and device drivers needed to boot from the mksysb tape. It is created by the bosboot command.
   There are three important files in the mkinsttape image (the second section of the mksysb tape): ./tapeblksz, ./bosinst.data, and ./image.data. The ./tapeblksz file contains the block size the tape drive was set to when the mksysb command was run.
   The ./bosinst.data file allows you to specify the requirements at the target system and how the user interacts with the target system. This file contains the customized BOS install procedures and dictates how the BOS install program will
   behave. You can customize this file before issuing the mksysb command or use a procedure to customize this file after the image backup is done.
   The ./image.data file contains information describing the image installed during the BOS installation process. This information includes the sizes, names, maps, and mount points of logical volumes and file systems in the rootvg. You can customize this file before using the mksysb command, or run mksysb -i to generate a new ./image.data file on the tape during a backup. The mkszfile command generates the ./image.data file. The ./image.data file is arranged in
   stanza format. Each stanza contains one or more fields.
   The dummy table of contents (TOC) is used so that the mksysb tape contains the same number of images as a BOS install tape.
   The rootvg data area contains all data in the rootvg volume group backed up by the mksysb command. The mksysb command uses the backup command to save the contents of mounted JFS data in rootvg, excluding raw data.
   
   
   When you need to make a mksysb backup of a system, and you want to exclude some data file systems from the system, you need to edit the /etc/exclude.rootvg file. Make sure that there are no empty lines.
   ^./tmp/
   
   
   Restoring mksysb
   An mksysb image enables you to restore the system image onto target systems that might not contain the same hardware devices or adapters, require the same kernel (uniprocessor or microprocessor), or be the same hardware platform (rs6k, rspc, or chrp) as the source system.
   You have several possibilities to restore the mksysb image:
   -If restoring on exactly the same machine, you can boot directly from the mksysb media and restore from there.
   -If restoring on a different type of machine, you use the cloning function
   -If you do not want to interfere with the production environment, you can use the alt_mksysb command.
   
   
   Multibos
   The multibos command allows the root level administrator to create multiple instances of AIX on the same rootvg. The multibos setup operation creates a standby Base Operating System (BOS) that boots from a distinct boot logical volume (BLV). This creates two bootable sets of BOS on a given rootvg. The administrator can boot from either instance of BOS by specifying the respective BLV as an argument to the bootlist command or using system firmware boot operations. Two bootable instances of BOS can be simultaneously maintained. The instance of BOS associated with the booted BLV is referred to as the active BOS. The instance of BOS associated with the BLV that has not been booted is referred to as the standby BOS. Currently, only two instances of BOS are supported per rootvg.
   
   
   The multibos command allows the administrator to access, install maintenance and technology levels for, update, and customize the standby BOS either during setup or in subsequent customization operations. Installing maintenance and technology updates to the standby BOS does not change system files on the active BOS. This allows for concurrent update of the standby BOS, while the active BOS remains in production.
   In this case, the biggest difference is that multibos will create and copy only the following Logical Volumes (LVs):
   /;
   /usr;
   /var;
   /opt, and;
   hd5 (Boot logical volume).
   All others LVs will be shared with the original root volume group, although more logical volumes can be specified and copied.
   Multibos supports a new TL update, but AIX version upgrades are not supported by multibos.
   
   
   Failed Disk Replacement
   
   
   If the disk you are going to replace is mirrored, we recommend following these steps:
   1. Remove copies of all logical volumes that were residing on that disk using either the rmlvcopy command or unmirrorvg command.
   2. Remove the disk from the volume group using the reducevg command.
   3. Remove the disk definition using the rmdev command.
   4. Physically remove the disk. If the disk is not hot-swappable, you may be required to reboot the system.
   5. Make the replacement disk available. If the disk is hot-swappable, you can run cfgmgr; otherwise, you may need to reboot the system.
   6. Include the newly added disk into the volume group using the extendvg command.
   7. Recreate and synchronize the copies for all logical volumes using either mklvcopy or mirrorvg.
   
   
   If the disk you are going to replace is not mirrored and is still functional, we recommend following these steps:
   1. Make the replacement disk available. If the disk is hot-swappable, you can run cfgmgr; otherwise, you may need to reboot the system.
   2. Include the newly added disk into the volume group using the extendvg command.
   3. Migrate all partitions from the failing disk to the new disk using either the migratepv command or the migratelp command. If the disks are part of the rootvg, you should consider the following:
   – If the disk to be replaced contains a copy of the BLV, you have to clear it using the chpv -c command.
   – A new BLV image must be created on the new disk using the bosboot command.
   – The bootlist must be updated to reflect these changes using the bootlist command.
   – If the disk to be replaced contains a paging space or a primary dump device, you should disable them. After the migratepv command completes, you should reactivate them.
   4. Remove the failing disk from the volume group using the reducevg command.
   5. Remove the disk definition using the rmdev command
   
   
   If the disk is not mirrored, has failed completely, and there are other disks available in the volume group, we recommend following these steps:
   1. Identify all logical volumes that have at least one partition located on the failed disk.
   2. Close the logical volumes and unmount all the corresponding file systems using the umount command.
   3. Remove the file systems and logical volumes using the rmfs command.
   4. Remove the failing disk from the volume group using the reducevg command.
   5. Remove the disk definition using the rmdev command.
   6. Physically remove the disk. If the disk is not hot-swappable, you may be required to reboot the system.
   7. Make the replacement disk available. If the disk is hot-swappable, you can run cfgmgr; otherwise, you may need to reboot the system.
   8. Include the newly added disk into the volume group using the extendvg command.
   9. Recreate all the logical volumes and the corresponding file systems using the mklv command and the crfs command.
   10.If you have a backup of your data, restore your data from backup.
   
   
   If the disk is not mirrored, has failed completely, there are no other disks available in the volume group (the volume group contained only one physical volume or all the physical volumes failed simultaneously), and the volume group is not rootvg, we recommend the following steps:
   1. Export the volume group definition from the system using the exportvg command.
   2. Ensure that /etc/filesystems does not contain any incorrect stanzas.
   3. Remove the disk definition using the rmdev command.
   4. Physically remove the disk. If the disk is not hot-swappable, you may be required to reboot the system.
   5. Make the replacement disk available. If the disk is hot-swappable, you can run cfgmgr; otherwise, you may need to reboot the system.
   6. If you have a volume group backup, restore it using the restvg command.
   7. If you do not have volume group backup, recreate the volume group, all the logical volumes, and the corresponding file systems using the mkvg command, the mklv command, and the crfs command.
   8. If you have a backup of your data, restore your data from backup.
   
   
   If the disk is not mirrored, has failed completely, there are not other disks available in the volume group (the volume group contained only one physical volume or all physical volumes failed simultaneously), and the volume group is
   rootvg, we recommend following these steps:
   1. Replace the failing disk.
   2. Boot the system in maintenance mode.
   3. Restore the system from an mksysb image.
   
   
   RAID Levels
   RAID 0 Also known as striping. Data is split into blocks of equal size and stored on different disks. There is no
   redundancy. If one disk fails, your data is lost.
   RAID 1 Also known as mirroring. Data is split into blocks of equal size. Duplicate copies are kept on separate
   physical disks. If one disk fails, the second copy is used and data is still available.
   RAID 5 Also known as striping with parity. Data is split into blocks of equal size. An additional data block
   containing parity information is generated. Both data blocks and the parity block are written onto separate
   physical disks. If one disk storing a block of data fails, the system will reconstruct the data from the failed
   drive using the parity information and the remaining data from the other drives.
   RAID 10 Also known as RAID 0+1 or enhanced RAID. It is a combination of mirroring (RAID 1) and striping (RAID
   0).
   
   
   SSH Securities:
   # vi /etc/ssh/sshd_config
   And make following changes for better security
   PermitRootLogin no Disabled the Direct root login
   Protocol 2 Good security concepts
   Banner file Set the banner in a file
   IgnoreRhosts yes If .rhosts is configured then ignored
   PermitEmptyPassword no Disabled the acceptance of null password
   HostBasedAuthentication no Disabled the host based authentication
   
   
   TCP Wrapper:
   TCP wrapper often called a s just a wrapper. It allows a system administrator to control access of TCP-based services or daemons that are wrapper aware. Download the “tcp_wrappers_7.6-ipv6.4.tar.gz” and install it.
   Replaced
   
   
   To
   
   
   
   
   
   
   and
   # refresh -s inetd
   Wrapper first check host.allow, if match found access is granted. If match found in host.deny the access is resticted for perticular services.
   # vi /etc/host.allow
   telnetd,sshd: .mydomain.com :allow
   telnetd,sshd:192.168.4.10 , 192.168.6. : allow
   
   
   # vi /etc/host.deny
   telnetd : 192.168.8., 192.168.9. : deny
   telnetd : 192.168.6. : allow
   # tcpdchk-v check the syntax in host.allow and host.deny
   
   
   
   
   Audits in AIX:
   AIX auditing provides a framework within which to capture pertinent system and security related information, such as failed login attempts, cron usage etc. It is recommended that auditing is enabled as part of a group of measures designed to provide enhanced logging of system and security changes.
   Create a /audit filesystem, at least 100 MB in size. The script always creates a standard jfs filesystem. If the /audit filesystem exists, this step is skipped:
   # mklv -y <LV name> -t jfs -u 1 -c 1 rootvg 1 hdisk0
   # crfs -v jfs -d auditlv -m /audit -A yes -t no mount /audit
   # vi /etc/security/audit/configt /audit
   start:
   binmode = on
   streammode = off
   
   
   bin:
   trail = /audit/trail
   bin1 = /audit/bin1
   bin2 = /audit/bin2
   binsize = 10240
   cmds = /etc/security/audit/bincmds
   
   
   Add the auditing entries for root and all other users below the pre-defined audit classes users:
   root = general,SRC,mail,cron,tcpip,ipsec,lvm
   <user 1> = general,SRC,cron,tcpip
   <user 2> = general,SRC,cron,tcpip
   etc.
   
   
   Update the /usr/lib/security/mkuser.default auditclasses entry to ensure that auditing is set up for any newly created users
   # chsec –f /usr/lib/security/mkuser.default –s user –a auditclasses=general,SRC,cron,tcpip
   
   
   Add the audit startup command into /etc/inittab.
   # mkitab "audit:2:boot:audit start > /dev/console 2>&1 # Start audit"
   
   
   
   
   Simultaneous Multi-Threading
   Simultaneous multithreading is the ability of a single physical processor to simultaneously dispatch instructions from more than one hardware thread context. Because there are two hardware threads per physical processor, additional instructions can run at the same time. The POWER5™ processor is a superscalar processor that is optimized to read and run instructions in parallel. Simultaneous multithreading allows you to take advantage of the superscalar nature of the POWER5™ processor by scheduling two applications at the same time on the same processor.
   Simultaneous multithreading is primarily beneficial in commercial environments where the speed of an individual transaction is not as important as the total number of transactions that are performed. Simultaneous multithreading is expected to increase the throughput of workloads with large or frequently changing working sets, such as database servers and Web servers.
   Multiple Hardware threads can run on one physical processor at the same time
   -A processor appears as two or four logical CPUs (lcpu) to AIX
   -Beneficial for most commercial environments
   -SMT is enabled by default with max no of logical CPUs
   Can change between SMT2 to SMT4 (POWER 7 only)
   Can Disabled and enabled
   
   
   
   
   
   
   AIX 6.1 Terminology
   
   
   What are WPARs?
   In contrast to LPARs, which are created and managed at the server's firmware level, AIX WPARs are software partitions that are created from, and share the resources of, a single instance of the AIX operating system. This means that you must have AIX 6.1 to create WPARs, but you can create WPARs on any System p hardware that supports AIX 6.1, including POWER4, POWER5, and POWER6 hardware. You don’t need an HMC or IVM to create or manage WPARs.
   There are two kinds of WPARs:
   System WPARs
   Application WPARs
   
   
   System WPARs
   System WPARs System WPARs are autonomous virtual system environments that have their own private file systems, users and groups, login, network space, and administrative domain. To users and applications, a system WPAR appears almost exactly like a full AIX system. Operating system services, such as telnet, are supported, so if network information has been configured, users can telnet into a system WPAR as root or any other defined user, issue commands, and run applications as they would on any other AIX system.
   -Autonomous virtual system environment
   Shared file system with global environment: /usr and /opt
   Private file system for wpar’s own use:/, /var, /tmp
   Unique set of users, groups, and network addresses
   -Can be access via Network protocol (telnet or ssh)
   Login from the global environment using the clogin command
   -Can be stopped and restarted
   
   
   Application WPARs
   Application WPARs provide an environment for isolation of applications and their resources to enable checkpoint, restart, and relocation at the application level. An application WPAR is essentially a wrapper around a running application or process for the purposes of isolation and mobility. It lacks some of the system services provided by system WPARs—for example, it’s not possible to log in or telnet into an application WPAR. When the application running in an application WPAR terminates, the WPAR also ceases to exist. Application WPARs are most useful when you want to enable Live Application Mobility—that is, when you want to be able to move a running application from one AIX system to another. You might want to relocate applications to avoid downtime resulting from scheduled maintenance or to improve performance by moving an application to a more powerful server
   -Isolate an individual application
   -Light weight; quick to create and remove
   Created with wparexec command
   Removed when stopped
   Stopped when the application finished
   -Shares file systems and devices with the global environment
   -No user login capabilities
   
   
   WPAR Manager
   IBM Workload Partitions Manager for AIX (WPAR Manager) is a platform management solution that provides a centralized point of control for managing workload partitions across a collection of managed systems running AIX 6.1. The managed systems might all be LPARs on a single physical server, or they might be located on multiple physical servers. Using WPAR Manager, you can monitor the health and status of multiple WPARs on multiple managed AIX systems. You can also perform all the basic WPAR life cycle operations—including create, view and manage properties, start, stop, and delete.
   WPAR Manager also supports relocation of WPARs between systems in a collection of managed servers. WPAR Managersupports two kinds of relocation:
   Manual relocation—This type of relocation is initiated by the user.
   Policy-based relocation—This type of relocation is initiated by WPAR Manager in response to workload conditions defined in a relocation policy.
   WPAR Manager is not part of AIX—it’s a separately purchased licensed program
   
   
   Multi-system management
   Managing WPARs on multiple AIX systems using the WPAR Manager requires two initial installation and configuration steps. First, you install and configure the management server software on an AIX system in your environment. Then, you install the WPAR Manager agent software on each AIX system that will be managed by WPAR Manager. The agent must then be configured to share WPAR data with a specific management server. After the WPAR Manager and agent components have been configured and started, the WPAR Manager automatically discovers all the managed systems, and begins to record data transmitted by the agents in an internal database.
   
   
   Live Application Mobility
   Live Application Mobility is the capability to relocate a WPAR from one hosting system to another without having to restart any applications or processes running in the WPAR. Partition mobility refers to the ability to move an entire running AIX LPAR from one physical server to another.
   
   
   Live Partition Mobility
   Live Partition Mobility allows you to migrate partitions that are running AIX and Linux operating systems and their hosted applications from one physical server to another without disrupting the infrastructure services. The migration operation, which takes just a few seconds, maintains complete system transactional integrity. The migration transfers the entire system environment, including processor state, memory, attached virtual devices, and connected users.
   Live Partition Mobility helps you meet increasingly stringent service-level agreements (SLAs) because it allows you to proactively move running partitions and applications from one server to another.
   Live Partition Mobility may also be used as a mechanism for server consolidation, because it provides an easy path to move applications from individual, stand-alone servers to consolidation servers. If you have partitions with workloads that have widely fluctuating resource requirements over time.
   Live Partition Mobility can be automated and incorporated into system management tools and scripts. Support for multiple concurrent migrations allows you to liberate system resources very quickly. For single-partition, point-in-time
   migrations, the Hardware Management Console (HMC) and the Integrated Virtualization Manager (IVM) interfaces offer easy-to-use migration wizards
   Partition Mobility is a hardware-based function, partition mobility is only supported on POWER6 hardware; application mobility is supported on any hardware that supports AIX 6.
   
   
   Partition Migration
   A partition migration operation can occur either when a partition is powered off (inactive), or when a partition is providing service (active).
   The migration process can be performed either with a powered-off or a live partition. The following two available migration types are discussed in more detail in the next sections:
   Inactive migration The logical partition is powered off and moved to the destination system.
   Active migration The migration of the partition is performed while service is provided, without disrupting user activities.
   
   
   Policy-based relocation
   WPAR Manager also has the capability to monitor performance of workloads running in WPARs and relocate those workloads to different AIX systems to improve performance. For example, if CPU or memory usage in a WPAR or group of WPARs is, on average, higher than a value that you specify, then the WPAR Manager might attempt to relocate one or more WPARs to a more powerful, or less busy, server in your datacenter. The detailed mechanics of how the policy engine works are beyond the scope of this article, but will be covered in a later article.
   
   
   Encrypted File System
   The Encrypted File System (EFS) is a J2 filesystem-level encryption through individual key stores. This allows for file encryption in order to protect confidential data from attackers with physical access to the computer. User authentication and access control lists can protect files from unauthorized access while the operating system is running; however, it’s easy to circumvent the control lists if an attacker gains physical access to the computer.
   One solution is to store the encrypted files on the disks of the computer.
   In EFS, a key is associated to each user. These keys are stored in a cryptographically protected key store and upon successful login, and the user's keys are loaded into the kernel and associated with the process credentials. When the process needs to open an EFS-protected file, the system tests the credentials. If the system finds a key matching the file protection, the process is able to decrypt the file key and file content. The cryptographic information is kept in the extended attributes for each file. EFS uses extended attribute Version 2, and each file is encrypted before being written on the disk. The files are decrypted when they are read from the disk into memory so that the file data kept in memory is in clear format. The data is decrypted only once, which is a major advantage. When another user requires access to the file, their security credentials are verified before being granted access to the data even though the file data is already in memory and in clear format. If the user is not entitled to access the file, the access is refused. File encryption does not eliminate the role of traditional access permissions, but it does add more granularity and flexibility.
   
   
   Snapshot
   The snapshot functionality was provided so that administrators could create consistent, integrated snapshots of an online (or offline) JFS2 file system. A point-in-time copy of the source file system is created. The snapshot operation executes quickly and requires very little disk space. Multiple snapshots can be taken, which can be very handy if you need to perform multiple changes to a system with corresponding backups at each stage.
   The snapshot retains the same permissions as the original file system. Once the image has been created, you can use it to restore files or an entire file system to a known point in time. Or, you can mount the snapped file system and perform a backup of it to tape (via Tivoli Storage Manager for example). This could help reduce your backup time requirements.
   There are two types of JFS2 snapshots.
   The first is an external snapshot which uses a separate logical volume for the snapshot image.
   The second type allocates space out of the original file system, this is known as an internal snapshot.
   
   
   An external snapshot can be mounted separately on its own mount point. A file system can use only one type of snapshot method at a time; that is, you cannot take an external snapshot of a file system and then take an internal snapshot of the same file system while the external exists (and vice versa).
   It is also important to note that you cannot use internal snapshots unless the file system was enabled to support them at the time of file system creation. So if you want to use snapshots on an existing file system and you did not enable it for internal snapshots, you will need either to recreate the file system with the snapshot option or use an external snapshot.
   One of the big advantages to using JFS2 snapshots is that we do not need to create a complete copy of all of the data. Nor do we need to recover the entire contents of the data. Thus reducing overhead and saving time.
   
   
   
   
   
   
   Network Installation Management
   
   
   Benefits of NIM
   NIM allows system administrators to install, upgrade, back up and maintain AIX 5L systems remotely
   Multiple machines can be installed or maintained at the same time
   Multiple AIX 5L versions, Maintenance Levels (MLs) or Technology Levels (TLs) can be used in the same NIM environment
   Disaster recovery - local systems can be recovered quickly with NIM
   Systems can be installed with standard and consistent AIX 5L operating system images
   Recovering a system backup (mksysb) from tape can be difficult when booting from CD media
   Cloning systems is another excellent feature of NIM which can assist you in moving from one server to another, or even from one site to another site
   
   
   NIM Overview
   A basic NIM environment consists of several IBM System p machines (at least two) connected via a TCP/IP network. A physical network can be shared by several NIM environments, therefore the machines attached to the same
   physical network can be part of several NIM environments
   The machines (or clients) can be standalone systems, LPARs, diskless, and dataless clients (also known as “thin clients”). The machines can be controlled by one (or more) Hardware Service Console
   
   
   Master
   Master refers the machine where you set up and maintain your NIM environment. You can also initiate installations from here (push mode). It is the key piece of the NIM environment. Refer to 2.1.4, “NIM master selection” on page 26, for information about how to chose a machine to become the NIM master.
   Client
   The NIM client can be the target for NIM master-initiated operations such as installation, updates, and so forth (push mode). Also, a client can initiate its own installation or update (pull mode). A NIM client automatically becomes a
   resource server when it holds NIM resources.
   
   
   Resource server
   Any machine (the master or a standalone client) can be configured by the master as a server for a particular software resource. In most environments, the master is also resource server.
   If other machines are already reporting to the master and they are installed (AIX), you can chose one of them to act as a resource server, thus relieving the NIM master of the heavy I/O load (disk and network). In such cases, the NIM master is only used to run administrative tasks.
   
   
   Push and pull modes
   The push mode operation is initiated from the master. The pull mode operation is initiated from the client. The very first time a client is installed, only the pull mode can be used.
   
   
   NIM database
   The NIM database is stored in the AIX Object Data Management (ODM) repository on the NIM master and is divided into four classes: machines, networks, resources, groups.
   
   
   Networks class
   The network is what allows the machines in a NIM environment to communicate which each other. If the network is a simple local area network (LAN), the definition of the network object is simplified. The purpose of the network object is to depict the network topology used by the NIM environment. Each modification made on the physical network must be reflected to the NIM database.
   
   
   Resources class
   A NIM resource is a pointer to a file or a directory located on a Resource Server, and the NIM Master is the default Resource Server. For example, the bosinst_data resource points to a file that contains information used to perform
   the installation process without requiring any manual intervention. The basic characteristics of a resource are the NIM name, the location (the location of the file or directory), and the resource server hosting the resource
   
   
   Groups class
   A group is a collection of either machines or resources. Only two types are available:
   # res_group, for grouping a set of resources
   # mac_group, for grouping a set of machines
   
   
   SPOT
   SPOT, or Shared Product Object Tree, is a directory of code (installed filesets) that is used during client booting procedure. It is equivalent in content to the code that resides in the /usr file system on a system running AIX 5L
   (binary objects - executables and libraries, header files and shell scripts). This resource (directory) replaces the content of the basic ramdisk image available on installation CDs.
   The SPOT also contains the code needed to generate the boot images (kernels, which will be stored in the /tftpboot directory) that the client uses until it can manage to NFS-mount the SPOT directory.
   
   
   lpp_source
   An lpp_source is a directory similar to AIX install CDs. It contains AIX Licensed Program Products (LLPs) in Backup File Format (BFF) format and RPM Package Manager (RPM) filesets that you can install
   
   
   mksysb
   This resource is a file containing the image of the root volume group (generated with the AIX mksysb command) of a machine. It is used to restore a machine, or to install it from scratch (also known as “cloning” a client). A mksysb resource can be defined by first creating the mksysb image with SMIT or the mksysb command, and then defining the resource that references the backup image file.
   
   
   bosinst_data
   The bosinst_data resource is a flat ASCII file similar to the bosinst.data file used for restoring system backup images from tape or CD/DVD. When you start the installation of a IBM System p machine, you will be prompted to
   select the console, language, installation method, the target disk(s) for rootvg, and so on. This resource comes in handy for both push or pull installation of multiple machines at the same time, because it will automate the installation
   process without requiring interactive answers for the installation parameters.
   
   
   script
   The script resource is a file. After the BOS installation is finished on your client, you can perform customization such as file system resizing, additional user creation, and so forth. The script resource points to a file (usually a shell
   script) that contains all the commands needed to perform customization.
   
   
   To rebuild and recover a NIM client /etc/niminfo file, use the niminit command on the client:
   niminit -a master=<MASTER_HOSTNAME> -a name=<CLIENT_NIM_NAME>
   
   
   NIM improovement in AIX 5.3
   nimsh
   Alternate NIM master
   Creating an SPOT resource from a mksysb
   mksysb migration using NIM
   
   
   Removing a NIM client definition
   /tftpboot This is used for storing NIM master boot images (kernels) and info files for the NIM clients.
   /export/lpp_source This is used for storing versions of AIX base level filesets in specific directories; a NIM lpp_source resource represents a directory in which software installation images are stored
   /export/spot This is used for storing non-/usr Shared Product Object Three (SPOT) in individual directories (one per SPOT version). A SPOT is required to install or initialize all types of machine configurations, as well as to generate a
   specific kernel image used for network booting a client system. Everything that a client machine requires in a /usr
   file system, such as the AIX kernel, executable commands, libraries, and applications, should be included in the
   SPOT.
   /export/images This is used for storing system backup images. These images can be created by using the NIM mksysb operation (“pulling” a mksysb image from a NIM client), or by copying a system backup as a file from a previously created backup file, tape, or DVD. To create subdirectories during NIM mksysb creation, you must
   export the NIM_MKSYSB_SUBDIRS=yes variables before using the command
   # nim -o define -t mksysb
   
   
   Basic Naming Conventions
   lpp_source lpp<OS#><TL#><SP#>
   spot spot<OS#><TL#><SP#>
   mksysb mksysb<OS#><TL#><SP#>
   network net_<IP#NET>
   
   
   Initializing NIM master
   nimconfig command can be used to perform a nim initializing
   Configuring the NIM master using the nimconfig command creates the master, boot, the first network object, nim_script with the /export/nim directory; the master (nimesis) daemon is also started.
   root@master:/: lsnim
   master machines master
   boot resources boot
   nim_script resources nim_script
   net_10_1_1 networks ent
   
   
   To convert an old NIM master into a client:
   Create a client definition on the NIM master.
   Remove the /etc/niminfo file (this will remove also the nim command from the system).
   Uninstall the bos.sysmgt.nim.master fileset.
   Check whether the bos.sysmgt.nim.client fileset is installed.
   Use the niminit command to register with the new NIM master (client registration must be enabled for this procedure to work).
   
   
   Verify auxiliary services (inetd, bootpd and tftpd)
   root@msater:/: lssrc -ls inetd
   tftp /usr/sbin/tftpd tftpd -n active
   bootps /usr/sbin/bootpd bootpd /etc/bootptab active
   
   
   The NIM master uses the bootpd (BOOT Protocol) and tftpd (Trivial File Transfer Protocol) daemons (services). Both services are normally started by the inetd daemon (InterNET master daemon).
   
   
   SMS and Console flow during NIM client installation
   At the Initial Program Load (IPL) menu, press the 1 key to access SMS Menu.
   select 2. Setup Remote IPL (Initial Program Load
   
   
   Select the desired adapter from the NIC Adapters list,
   
   
   
   
   select 1. IP Parameters to access the IP Parameters menu
   
   
   
   
   1. From the IP Parameters menu select 1. Client IP Address, to set the Client IP Address.
   2. From the IP Parameters menu select 2. Server IP Address, to set the Server IP Address (NIM master).
   3. From the IP Parameters menu select 3. Gateway IP Address. Leave it if the NIM master and client are on the same IP subnet.
   4. From the IP Parameters menu select 4. Subnet Mask, to set the Subnet Mask for the IP network.
   5. Press ESC and return to the previous menu
   
   
   
   
   Network Parameters menu, select 3. Ping Test
   
   
   
   
   From the Network Parameters menu, select 1. Execute Ping Test
   
   
   
   
   
   
   Next, press M from the Ping Test menu to return to the Main Menu
   
   
   From the Main Menu, choose 5. Select Boot Options
   
   
   
   
   From the Multiboot menu, choose 1. Select Install/Boot Device
   
   
   
   
   From the Select Device Type menu, select 6. Network to choose a network
   
   
   
   
   From the NIC Adapters list, in this case, select 1. to access the Select Task menu
   
   
   
   
   From the Select Task menu, select 2. Normal Mode Boot
   
   
   
   
   From the exit SMS menu select 1. Yes to let the network installation begin
   
   
   
   
   First the network boot (IPL) is initiated for the LPAR.
   Next, the LPAR issues BOOTP requests to the server IP-address specified in the IP Parameters menu. It receives the BOOTP record information from /etc/bootptab on the NIM master. This record specifies the TFTP server for sending a bootable kernel. The LPAR issues TFTP requests to the server listed in the /etc/bootptab sa field from the NIM master.
   
   
   
   
   Then control is passed to the transferred and loaded AIX 5L kernel.
   In this case the installation is made using a NIM mksysb resource.
   After installing the software, the boot image is created.
   Once the installation is finished and the LPAR is restarted and The newly installed kernel is loaded and the LPAR is restarted
   
   
   
   
   
   
   LPAR and VIO Server Terminology
   
   
   Logical partitioning
   Logical partitioning (LPAR) is the ability to logically slice up a single system's CPU, memory, and other resources to create multiple and separate servers. Each LPAR has its own allocation of CPU, memory, and I/O devices. This type of partitioning is done at the firmware level, not at the physical resource level. Thus, with the IBM System p5 servers, you are able to create LPARs using Micro-Partitioning™ -- assigning less than one physical CPU per LPAR.
   
   
   Virtual I/O Server
   It is a special kind of partition called a Virtual I/O Server (VIO Server). The VIO Server provides the ability to share I/O resources among several LPARs. You define virtual Ethernet and disk devices on the VIO Server and then make them available to the other LPARs on the system. Without the ability to share I/O devices on the managed system, each LPAR would require its own dedicated devices. If you have two LPARs on a system, you would need at least two Ethernet cards and two disk controllers. However, if you have 15 LPARs, then you would need at least 15 Ethernet cards and 15 disk controllers. With the use of VIO LPARs, you could host 15 LPARs with a much smaller number of Ethernet and disk controllers.
   Of course, you are still able to dedicate I/O devices to an AIX partition if you need to for performance reasons. For example, if you have a large database LPAR that requires a large amount of throughput, you can dedicate a disk controller to that LPAR so that it won't have to compete for I/O resources with other LPARs using the VIO's disk controller.
   On the other hand, you might have several small LPARs that do not require a large amount of data throughput. They would be ideal candidates for using the VIO Server since each of them would not completely utilize the full capacity of an Ethernet card or disk controller (see Figure 3). Together they could take full advantage of the hardware's capacity
   
   
   Dynamic logical partitioning
   Not only are you able to logically carve up your hardware into multiple LPARs, but IBM provides the capability of dynamically adding, removing, or moving resources between the partitions while they are up and running. You can add or remove CPU, memory, or I/O slots to a running partition without first shutting that LPAR down.
   Dynamic logical partitioning (DLPAR) provides a great deal of flexibility to your computing environment. As conditions change in your environment, you are able to react by moving hardware resources to where they are needed without interrupting services to the LPARs. The options for using this feature are endless. A word of caution, though, not all applications are able to handle the removal of CPUs or memory gracefully, so testing is needed in your particular situation before you begin to use this feature in a production environment.
   In the rest of this article, I'll discuss the steps you need to follow to configure an installed p5 system. It is impossible, in an article of this length, to discuss all the options available to you in configuring an LPAR system. Throughout the article, I'll cover the configuration basics and then point you to documents that provide more detailed information for that particular component. I'm also assuming the hardware is installed and connected to your network.
   
   
   Micro-Partitioning
   Micro-Partitioning is the ability to distribute the processing capacity of one or more physical processors among one or more logical partitions. Thus, processors are shared among logical partitions.
   
   
   System Profile
   A system profile is a collection of one or more partition profiles. System profiles can be used to specify which partition profiles are activated at the same time.
   
   
   Partition Profile
   A partition profile represents a particular configuration for a logical partition. A partition profile contains information about the resources assigned to the partition. These resources include memory, processor processing capacity, and physical I/O slots. Partition profiles also include information about which devices provide important partition functions
   
   
   Memory in LPAR
   There are three memory values for a partition profile:
   # Minimum memory: This amount of memory is required for the partition. The profile will fail to activate if the minimum memory is not met.
   # Desired memory: This is the requested amount of memory for the partition. On profile activation, the partition will receive an amount of memory between the minimum and desired amounts depending on what is available.
   # Maximum memory: The maximum represents the upper limit for memory. Memory allocations cannot go above the maximum. In order to go above the maximum, the maximum value needs to be changed.
   
   
   Dedicated Processor
   Dedicated processor means you are working with whole processors that are dedicated to a single partition. The dedicated processor handles the processing for one specific logical partition. If you choose to assign dedicated processors to a logical partition, you must assign at least one processor to that partition.
   
   
   Shared Processor
   The shared processing pool allows you to assign partial processors to a logical partition. The physical processors are held in the shared processing pool and are shared among logical partitions. At partition creation time, the shared processing units can be defined as 0.1.
   There are two types
   Capped and
   Uncapped
   Capped prohibits the LPAR from using more processing units than is currently allocated to it. If an LPAR is allocated 1.5 processing units but the workload requires 2.2 units, the LPAR would not be allowed access to the additional units, even if they were available in the shared processor pool.
   Uncapped allows the LPAR to use more processing units than is currently allocated. In this example, the LPAR would have access to the additional 0.7 processing units needed for the workload. If Uncapped is selected, you need to provide the Weight value for this LPAR. LPARs with higher Weight values receive higher priority when shared pool resources are fully used.
   
   
   Virtual Processor
   Virtual processors tell the LPAR's OS how many physical processors it has. The OS cannot use parts of a processor, so you have to tell it in whole numbers how many processors it can use. Also, the number of virtual processors limits how many physical processors an LPAR can use. For example, if you give an LPAR two virtual processors, it cannot use more than two physical processors even though Maximum processing units is higher than two.
   ■Minimum number of virtual processors: You must have at least one virtual processor for every part of a physical processor assigned to the LPAR. For example, if you have assigned 2.5 processing units to the LPAR, the minimum number of virtual processors is three.
   ■Desired number of virtual processors: You can assign a virtual processor to every 0.1 processing unit allocated to the LPAR. There is no recommended value for this configuration setting. You need to use trial and error to determine what is the best setting for your application(s).
   ■Maximum number of virtual processors: You can only have 10 virtual processors per processing unit. Therefore, you cannot assign a value greater than 10 times the maximum processing units value.
   
   
   Virtual I/O Adapter
   Virtual IO adapters give a partition the flexibility to use certain types of resources with requiring the physical hardware to be present. If the partition will be using virtual IO, make sure that the Yes radio button is selected. Otherwise, select the No radio button.
   The following virtual IO adapters can be created:
   Virtual Ethernet
   Virtual Serial
   Virtual SCSI
   
   
   Virtual Ethernet
   Virtual Ethernet technology is supported on AIX® 5.3 on POWER5™ hardware. This technology enables IP-based communication between logical partitions on the same system using a VLAN capable software switch in POWER5 systems. Shared Ethernet Adapter technology (part of the optional Virtual I/O Server feature on POWER5 hardware) enables the logical partitions to communicate with other systems without assigning physical Ethernet slots to the logical partitions.
   The number of virtual Ethernet adapters for each LPAR varies by operating system. AIX 5.3 limits the number of virtual Ethernet adapters to 256 virtual Ethernet for each LPAR. Besides a PVID, the number of additional VID values that can be assigned for each virtual Ethernet adapter is 20, which indicates that each virtual Ethernet adapter can be used to access 21 networks. The HMC generates a locally administered Ethernet MAC address for the virtual Ethernet adapters so that these addresses do not conflict with physical Ethernet adapter MAC addresses. To ensure uniqueness among the virtual Ethernet adapters, the address generation is based on the system serial number, LPAR ID, and adapter ID.
   When using the Integrated Virtualization Manager, only PVID is allowed (no additional VLANs), and only the PVID may only be 1-4.
   
   
   Virtual Serial
   Virtual serial adapters provide a point-to-point connection from one logical partition to another, or from the Hardware Management Console (HMC) to each logical partition on the managed system. Virtual serial adapters are used primarily to establish terminal or console connections to logical partitions. When you create a logical partition, the HMC automatically creates two virtual server serial adapters on the logical partition. These virtual server serial adapters allow you to establish a terminal or console connection to the logical partition through the HMC.
   You can also create pairs of virtual serial adapters on logical partitions so that you can access and control one logical partition directly from another logical partition. For example, one logical partition uses the disk resources of another logical partition using virtual SCSI adapters. You can create a server serial adapter on the logical partition that uses the disk resources and a client serial adapter on the logical partition that owns the disk resources. This connection allows the logical partition that owns the disk resources to shut down the logical partition that uses the disk resources before you back up data on the logical partition that owns the disk resources.
   
   
   
   Virtual SCSI
   Virtual SCSI (Small Computer Systems Interface) adapters provide one logical partition with the ability to use storage I/O (disk, CD, and tape) that is owned by another logical partition.A virtual SCSI client adapter in one logical partition can communicate with a virtual SCSI server adapter in another logical partition. The virtual SCSI client adapter allows a logical partition to access a storage device being made available by the other logical partition. The logical partition owning the hardware is the server logical partition, and the logical partition that uses the virtualized hardware is the client logical partition. With this arrangement, the system can have many server logical partitions.
   
   
   NPIV (Network Port ID Virtualization)
   N_Port ID Virtualization is a fibre channel industry standerd method for virtualizing a physical fibre channel port. NPIV allows one F_Port to be associated with multiple N_Port Ids, so a physical fibre channel HBA can be shared accross multiple guest operating systems. On POWER, NPIV allows logical partitions (LPARs) to have dedicated N_Port IDs, giving the OS a unique identity to the SAN, just as if it had a dedicated physical HBA(s).