Tag Archives: Aix

aix disks that are currently not being used

Lists SSA disks that are currently not being used by either the OS or other  applications.  Lists what size the disk is and which enclosure and slot the disk is located in.


printf “Please wait, this could take a while… nn”

for pdisk in `lsdev -Cc pdisk | awk ‘/SSA/{print $1}’`
hdisk=`ssaxlate -l ${pdisk}`
if [ “${hdisk}” ]
vg=`lspv |grep ${hdisk}| awk ‘{print $3}’| head -1`
vgstatus=`lsvg -o | grep “${vg}”`
if [ “${vgstatus}” = “${vg}” ]
diskinfo=`lspv -l ${hdisk}`

if [ ! “${diskinfo}” ]
size=`lsattr -El ${pdisk} | awk ‘/size_in_mb/{print $2}’`
slot=`lsdev -Cc pdisk | grep ${pdisk} | awk -F”-” ‘{print $3,$4}’ | head -1`
echo “${hdisk}: size=${size}”
echo “Location: ${slot}”

Boot the IBM Aix system into Service mode

This document describes how to boot the system into Service mode (also known as Maintenance mode) to install the machine, restore an operating system backup, or perform maintenance on the rootvg volume group.

The information in this document applies to AIX Versions 3.x, 4.x and 5.x.

Booting microchannel systems into Service mode Booting  PCI-based systems into Service mode PCI machine-specific information Accessing rootvg and mounting file systems
Related documentation


Booting microchannel systems into Service mode

To boot microchannel systems into Service mode, turn the key to the Maintenance  position and press the yellow reset button twice. You must boot from bootable  media, such as an installation CD-ROM, installation tape, or a bootable backup  tape made via the mksysb command or the Sysback product of the correct level for  this  machine.

For AIX Version 3.2, you may use bootable bosboot diskettes. To boot from these,  insert the first bosboot diskette into the diskette drive. When you see LED c07,  insert the next diskette, which is usually the display extensions diskette.  After this diskette is read, you should receive a menu prompting you for the  installation diskette.

For information on accessing your rootvg volume group, see the section entitled  “Accessing rootvg and mounting file systems”.

The preceding discussion assumes that the Service mode bootlist has not been  modified from the default bootlist. If the bootlist has been modified, it must  be reset such that one of the boot media types from the preceding selections is  before the standard boot media, such asthe hard disk.

If the machine is an SMP model (7012-Gxx, 7013-Jxx, and 7015-Rxx) and the  Autoservice IPL flag is disabled, then a menu like the following will display  when it is booting in Service mode:


You can boot these machines into Service mode or even Normal mode with the Fast  IPL Flag set. If you do not, the machine can take anywhere from 30 to 60 minutes  to boot up. There are a few ways to set the Fast IPL Flag for these machines.

NOTE: The console must be an ASCII type and connected to the S1 port of the  system. Graphic monitors will not work.

Use the following instructions to boot SMP machines into service with Fast IPL set.

Insert the bootable media of the same OS Level. Use the mksysb/cd-rom command.
Turn off the machine by pressing the white button on front.
Turn the key to the Wrench or Service position.
The LCD should read STAND-BY.
Press the Enter key on the console.
A greater-than prompt (>) should display on the monitor.
Type in sbb followed by the Enter key.
The menu Stand By Menu should now display.
Select 1 Set Flags. This will take you to another set of menus.
Select 6 Fast IPL. This should change to enable after it is selected.
Enter x to exit the second set of menus.
Enter x to exit the first menu.
At a blank screen, press the Enter key to obtain the greater-than prompt (>).
Type in the word power followed by the Enter key.
Turn the machine back on. It should start to boot up. A prompt may display asking
if you want to update the firmware. Do not respond; let it continue.
Now you may be at the Maintenance Menu with 10 options displayed, 0 through 9. If
that is the case, select option 6, System Boot. This will take you to another
menu. Select option 0, Boot from the list.
The Standard Maintenance Menu should display. System recovery and maintenance
can be completed from here.
After system recovery and maintenance has been performed, the system is ready to
be rebooted into Normal mode. Enter the command mpcfg -cf 11 1 at the command
line prompt, then press Enter. This will set the Fast IPL Flag. The system is
ready to reboot.
Turn the key back to the OK/Normal position.
Enter shutdown -Fr, followed by the Enter key.


Booting PCI-based systems into Service mode

When booting a PowerPC into Service mode, cd0 or rmt0 must be before the hdisk in the bootlist. If not, change the bootlist at boot time. On some models, you can set the machine to use a default bootlist that includes both cd0 and rmt0. If a bootable CD or tape is in the CD-ROM or tape drive, the machine will boot from this device.

For most of the newer PCI-based models, selecting the default bootlist, with a bootable tape or CD loaded in the machine, causes the system to automatically boot from that device. Generally, the next menu on the screen asks the administrator to define the system console.

For all machines discussed here, if you are using a graphical terminal, you will use a function key such as F5. If you are using an ASCII terminal, use an equivalent number key such as 5. Use the numbers across the top of the keyboard, not the numbers on the numeric keypad. On ASCII terminals, the icons may not be displayed on the screen; the number can be pressed between the second and third beeps, the second beep being a series of three clicks.


PCI machine-specific information
The following systems all use the F5 or 5 key to read from the default boot list, which is written into the system firmware:

MODEL       7017       7024       7025       7026       7043       7137
——-   ——-    ——-    ——-    ——-    ——-    ——-
TYPE      S70        E20        F30        H10        43P-140    F3L
S7A        E30        F40        H50        43P-150
S80                   F50        H70        43P-240
B80        43P-260

On these machines, use 5 (on the keyboard, not the keypad) if you are using an ASCII terminal. On a locally attached graphics console, use the F5 function key. The F5 or 5 key must be pressed just after the keyboard icon or message is displayed on the console. If you have either a 7026-M80, 7026-H80 or a 7025-F80, then the 5 key will be the default whether you have an ascii or graphics console.

The following systems use the F1 key to enter System Management Services mode (SMS):

MODEL       6040       7042       7247       7249
——-   ——-    ——-    ——-    ——-
TYPE        620        850        82x        860

You should be in an Easy-Setup menu. Select the Start Up menu. Clear the current bootlist settings and then select the CD-ROM for choice 1 and hdd (the hard disk) for choice 2. Select OK. Insert the CD-ROM and select the EXIT icon. The machine should now boot from the CD-ROM.

The following systems use the F2 key to enter SMS:

MODEL         6015       6050       6070       7020       7248
——-     ——-    ——-    ——-    ——-    ——-
TYPE          440        830        850        40P        43P

Select Select Boot Device from the initial menu on the screen, and then select Restore Default Settings from the list. Press the Esc key to exit all the menus, and then reboot the machine. The system should boot from your bootable media.

For information on accessing the rootvg volume group, see the next section in this document.


Accessing rootvg and mounting file systems
For AIX Version 3, choose the limited function maintenance shell (option 5 for AIX 3.1, option 4 for AIX 3.2).

If you only have one disk on the system, then hdisk0 will be used in the execution of the getrootfs or /etc/continue commands, which follow. If you have more than one disk, determine which disk contains the boot logical volume in this manner:

AIX 3.2.4 or AIX 3.2.5:

Run getrootfs; the output will indicate which disk contains the hd5 logical volume.

AIX 3.1 to AIX 3.2.3e:

Run lqueryvg -Ltp hdisk# for each hdisk. You can obtain a listing of these with the command lsdev -Cc disk. Repeat this command until you get output similar to the following:

00005264feb3631c.2  hd5  1

If more than one disk contains this output, use any disk when running getrootfs.
Now, access the rootvg volume group by running one of the following commands, using the disk you obtained in the preceding step:

AIX 3.1:                     /etc/continue hdisk#
AIX 3.2.0-3.2.3e:            getrootfs -f hdisk#
AIX 3.2.4-3.2.5:             getrootfs hdisk#

NOTE: If you want to leave the primary OS file systems (/, /usr, /tmp, and /var) unmounted after this command has completed, to run fsck, for instance, place a space and the letters sh after the hdisk in the preceding command. For example:

getrootfs hdisk0 sh

For AIX Versions 4 and 5, choose Start Maintenance Mode for System Recovery , option 3. The next screen will be called Maintenance; select option 1, Access a Root Volume Group. At the next screen, type 0 to continue, and select the appropriate volume group by typing the number next to it. A screen like the following will display.

Access a Root Volume Group

Type the number for a volume group to display the logical volume information and press Enter.

1)  Volume Group 0073656f2608e46a contains these disks:
hdisk0  2063 04-C0-00-4,0

Once a volume group has been selected, information will be displayed about that volume group.


Volume Group Information
Volume Group ID 0073656f2608e46a includes the following logical volumes:
hd6         hd5         hd8         hd4         hd2      hd9var
hd3         hd1

Type the number of your choice and press Enter.

1) Access this Volume Group and start a shell
2) Access this Volume Group and start a shell before mounting filesystems
99) Previous Menu

If the logical volumes listed do not include logical volumes like hd4, hd2, hd3, and so on, you may have selected the wrong volume group. Press 99 to back up one screen and select again.

Now you may select one of two options: Access this volume group and start a shell , option 1, or Access this volume group and start a shell before mounting file systems , option 2. Option 2 allows you to perform file system maintenance on /, /usr, /tmp, and /var before mounting them.

NOTE: If you intend to use SMIT or vi, set your terminal type in preparation for editing the file. xx stands for a terminal type such as lft, ibm3151, or vt100.

export TERM

Errors from these steps may indicate failed or corrupt disks in rootvg. These problems should
be corrected. For additional assistance, contact your vendor, your local branch office, or your AIX support center.


Related documentation
For more in-depth coverage of this subject, the following IBM publication is recommended:
AIX Version 4.3 System Management Guide: Operating System and Devices
AIX Version 5.1 System Management Guide: Operating System and Devices

IBM documentation can also be accessed online through the following URL:

Similar documents can be accessed through the following URL:

Add a RAM File System in Aix

Create a RAM disk of 10 MB

# mkramdisk 10M


Create a JFS File System on this RAM disk

# mkfs -V jfs /dev/rramdisk0

mkfs:destroy /dev/rramdisk0 (yes) ? y

Create Mountpoint

# mkdir /ramdisk

Mount  RAM File System

# mount -V jfs -o nointegrity /dev/ramdisk0 /ramdisk

The purpose of the mkramdisk command is to create file systems directly in memory. This is useful for applications that make many temporary files. Use ramdisk only for data that can be lost. After each reboot the ramdisk file system is destroyed and must be rebuilt.

Aix: Hot spot management in logical volumes

You can identify hot spot problems with your logical volumes and remedy those problems without interrupting the use of your system.

A hot-spot problem occurs when some of the logical partitions on your disk have so much disk I/O that your system performance noticeably suffers.

The first step toward solving the problem is to identify it. By default, the system does not collect statistics for logical volume use. After you enable the gathering of these statistics, the first time you enter the lvmstat command, the system displays the counter values since the previous system reboot. Thereafter, each time you enter the lvmstat command, the system displays the difference since the previous lvmstat command.

By interpreting the output of the lvmstat command, you can identify the logical partitions with the heaviest traffic. If you have several logical partitions with heavy usage on one physical disk and want to balance these across the available disks, you can use the migratelp command to move these logical partitions to other physical disks.

In the following example, the gathering of statistics is enabled and the lvmstat command is used repeatedly to gather a baseline of statistics:

# lvmstat -v rootvg -e
# lvmstat -v rootvg -C
# lvmstat -v rootvg

The output is similar to the following:

Logical Volume            iocnt      Kb_read     Kb_wrtn      Kbps
  hd8                         4            0          16      0.00
  paging01                    0            0           0      0.00
  lv01                        0            0           0      0.00
  hd1                         0            0           0      0.00
  hd3                         0            0           0      0.00
  hd9var                      0            0           0      0.00
  hd2                         0            0           0      0.00
  hd4                         0            0           0      0.00
  hd6                         0            0           0      0.00
  hd5                         0            0           0      0.00

The previous output shows that all counters have been reset to zero. In the following example, data is first copied from the /unix directory to the /tmp directory. The lvmstat command output reflects the activity for the rootvg:

# cp -p /unix /tmp
# lvmstat -v rootvg

Logical Volume            iocnt      Kb_read     Kb_wrtn      Kbps
  hd3                       296            0        6916      0.04
  hd8                        47            0         188      0.00
  hd4                        29            0         128      0.00
  hd2                        16            0          72      0.00
  paging01                    0            0           0      0.00
  lv01                        0            0           0      0.00
  hd1                         0            0           0      0.00
  hd9var                      0            0           0      0.00
  hd6                         0            0           0      0.00
  hd5                         0            0           0      0.00

The output shows activity on the hd3 logical volume, which is mounted in the /tmp directory, on hd8, which is the JFS log logical volume, on hd4, which is / (root), on hd2, which is the /usr directory, and on hd9var, which is the /var directory. The following output provides details for hd3 and hd2:

# lvmstat -l hd3

Log_part    mirror#    iocnt    Kb_read    Kb_wrtn     Kbps
       1         1       299          0       6896     0.04
       3         1         4          0         52     0.00
       2         1         0          0          0     0.00
       4         1         0          0          0     0.00
# lvmstat -l hd2
Log_part    mirror#    iocnt    Kb_read    Kb_wrtn     Kbps
       2         1         9          0         52     0.00
       3         1         9          0         36     0.00
       7         1         9          0         36     0.00
       4         1         4          0         16     0.00
       9         1         1          0          4     0.00
      14         1         1          0          4     0.00
       1         1         0          0          0     0.00

The output for a volume group provides a summary for all the I/O activity of a logical volume. It is separated into the number of I/O requests (iocnt), the kilobytes read and written (Kb_read and Kb_wrtn, respectively), and the transferred data in KB/s (Kbps). If you request the information for a logical volume, you receive the same information, but for each logical partition separately. If you have mirrored logical volumes, you receive statistics for each of the mirror volumes. In the previous sample output, several lines for logical partitions without any activity were omitted. The output is always sorted in decreasing order on the iocnt column.

The migratelp command uses, as parameters, the name of the logical volume, the number of the logical partition (as it is displayed in the lvmstat output), and an optional number for a specific mirror copy. If information is omitted, the first mirror copy is used. You must specify the target physical volume for the move; in addition, you can specify a target physical partition number. If successful, the output is similar to the following:

# migratelp hd3/1 hdisk1/109
  migratelp: Mirror copy 1 of logical partition 1 of logical volume
        hd3 migrated to physical partition 109 of hdisk1.

After the hot spot feature is enabled, either for a logical volume or a volume group, you can define your reporting and statistics, display your statistics, select logical partitions to migrate, specify the destination physical partition, and verify the information before committing your changes.

migratelp Command


Moves allocated logical partition from one physical partition to another physical partition on a different physical volume.


migratelp LVname/LPartnumber[ /Copynumber ] DestPV[/PPartNumber]


The migratelp moves the specified logical partition LPartnumber of the logical volume LVname to the DestPV physical volume. If the destination physical partition PPartNumber is specified it will be used, otherwise a destination partition is selected using the intra region policy of the logical volume. By default the first mirror copy of the logical partition in question is migrated. A value of 1, 2 or 3 can be specified for Copynumber to migrate a particular mirror copy.

  1. You must consider the partition usage, reported by lvmstat, on the other active concurrent nodes in case of a concurrent volume group.
  2. Strictness and upper bound settings are not enforced when using migratelp.

The migratelp command fails to migrate partitions of striped logical volumes.


To use migratelp, you must have root user authority.


  1. To move the first logical partitions of logical volume lv00 to hdisk1, type:
    migratelp lv00/1 hdisk1
  2. To move second mirror copy of the third logical partitions of logical volume hd2 to hdisk5, type:
    migratelp hd2/3/2 hdisk5
  3. To move third mirror copy of the 25th logical partitions of logical volume testlv to 100th partition of hdisk7, type:
    migratelp testlv/25/3 hdisk7/100

Aix: Install and Configuration HACMP [ Overview]

1. Overview

The High Availability (HA) feature of application allows a properly configured application system to automatically recover from a number of possible failures, with the goal of eliminating all single points of failure in the system. The same functionality can be used to minimize the impact of regularly scheduled maintenance and/or software upgrades.

The High Availability feature is only available on AIX platforms.

Failures of the following components will be protected against when using a properly configured HA application system:

  • Core server
  • Network-related
  • adapters
  • cables
  • Disk-related
  • adapters
  • cables
  • disks
  • Power-related
  • node power supply
  • disk power supply
  • power distribution strip

High availability is not the same as fault tolerance. The failures above are “protected against” from the standpoint that the HA application system will be able to return to an operational state without intervention when any one of the above failures occur. There certainly may be some down-time, especially when the core server fails (crashes).

After a recovery, application will function properly, but it will no longer be in a Highly Available state. A subsequent failure may not be recoverable. For instance, if the core server crashes and the backup takes over, there is no longer a backup node. It will be necessary to correct the original failure in order to return the system to a Highly Available state.

1.1 Architecture

The following diagram shows the necessary components for an HA application configuration:

Figure G-1 HA application Architecture

This diagram does not include the power system, but it does have several features that are very important:

  • At any point in time, either Node 1 or Node 2 can act as the core application server.
  • The two shared disk busses are mirrored to one another and accessed by each node using separate adapter cards so that any single failure (disk, adapter, or bus) will result in accessibility of at least one good copy of the data.
  • Each node has two connections to the ethernet network. One is a “standby” that can take over the IP and hardware addresses of the primary adapter in case of failure.
  • There is an RS-232 serial cable connecting Node 1 and Node 2 to enable communication even in the event that the main network fails.

Aix mirror rootvg during System Restore

1. mkszfile
2. Edit /image.data and add in multiple copies -in the lv_data section change COPIES = 2  or each lv (might be some other fields to change – compare a mirrored to a non-mirrored lv to check).

##Command used for lv_data; /usr/sbin/lslv

        VOLUME_GROUP= rootvg
        LV_SOURCE_DISK_LIST= hdisk0
        LV_IDENTIFIER= 00075ef10000d60000000119e75995ad.1
        LOGICAL_VOLUME= hd5
        VG_STAT= active/complete
        TYPE= boot
        MAX_LPS= 512
        COPIES= 1
        LPs= 1
        STALE_PPs= 0
        INTER_POLICY= minimum
        INTRA_POLICY= edge
        VOLUME_GROUP= rootvg
        LV_SOURCE_DISK_LIST= hdisk0 hdisk1
        LV_IDENTIFIER= 0005e4d40000d70000000133abd69497.2
        LOGICAL_VOLUME= hd6
        VG_STAT= active/complete
        TYPE= paging
        MAX_LPS= 512
        COPIES= 2
        LPs= 64
        STALE_PPs= 0

3. Take the mksysb but DO NOT use the -i option (since this will
create a new image.data file which overwrites your old one).
4. Restore the mksysb.

Note: please do it on your own risk……

Aix: Export and Import a Volume Group After System Crash

  1. ibmcl01 is the hostname of the LPAR… which is a VIOC too
  2. oravg is the name of volume group which resides on the SAN disks impacted by the export/reimport

Assuming that we want to migrate, on a VIOC, one or more currently SAN disks attached on a local fibre channel adapter to the same one or more SAN disks but now presented as SCSI storage media, seen — this time — through a VIOS.

Here is the logical steps to follow… when all things doesn’t work as expected (real life example)!

Get the list of the physical and logical volumes corresponding to the volume group:

# lsvg -p oravg
hdisk4            active            999         18          00..00..00..00..18

# lsvg -l oravg
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv00             jfs2log    1       1       1    open/syncd    N/A
fslv00              jfs2       980     980     1    open/syncd    /aspora11gdb01

Unmount the already mounted file systems:

# umount /aspora11gdb01

Deactivate a volume group and export the definition of a volume group from a set of physical volumes:

# varyoffvg oravg
# exportvg oravg

Having verified that there is no physical volumes in the desired volume group using lspv, remove them from the devices list with the corresponding adapter:

# rmdev -l hdisk4 -Rd
# lsslot -c slot
# rmdev -l pci2 -Rd

We assume that the fibre channel adapter is now seen through a VIOS: it is not shown here how to dynamically move it from the LPAR to the VIOS and allocate the PVs to a particular VIOC, i.e. ibmcl01 in our case.

Make the new disks available to the OS and verify that the presented LUNs are the right ones:

# cfgmgr
# lscfg -l hdisk4
  hdisk4           U9113.650.95A3E0C-V5-C4-T1-L6500000000  Virtual SCSI Disk Drive

Generally, we just have to import the oravg volume group, activate it, mount the file systems on it and… enjoy. Since we encountered a problem during the import (the information between the VM and the ODM seems not synchronized accordingly), here are the steps we follow to recover the situation.

Reimport the volume group, redefine the set of PVs of the given VG in the device configuration database and activate it:

# importvg oravg               /* Ooops... something goes wrong here! */
# redefinevg -d hdisk4 oravg   /* One disk is sufficient to get the volume group information back. */
# varyonvg oravg

Ok, the PVs are back in the configuration but not the type of the LVs, according to:

# lsvg -l oravg
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv00             jfs2log    1       1       1    open/syncd    N/A
fslv00              jfs2       980     980     1    open/syncd    /aspora11gdb01

Synchronize or rebuild the logical volume control block, the device configuration database and the volume group descriptor areas on the PVs:

# synclvodm -v -P oravg
synclvodm: Physical volume data updated.
synclvodm: Logical volume loglv01 updated.
synclvodm: Logical volume fslv00 updated.

# lsvg -l oravg
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv00             jfs2log    1       1       1    open/syncd    N/A
fslv00              jfs2       980     980     1    open/syncd    /aspora11gdb01

Create complete boot image and device (in order to keep the type of LVs persistent across reboot):

# bosboot -a

bosboot: Boot image is 23145 512 byte blocks.

Mount the file systems and… enjoy :)