The Unix

IBM AIX - Creating a New LPAR using HMC GUI

2012-12-15T00:44:00.000+05:30

IBM AIX - Creating a New LPAR using HMC GUI - Dedicated Resource!!

Step1: Login into HMC GUI.
To create a new logical partition, you have to login into HMC either locally or remotely using WebSM or using web browser. Example below uses WebSM to login into the HMC

Type the hostname of HMC that you want to connect to and click on Log on tab.In this example we are logging into adcaphmc01 to create a new logical partition.

WebSM client then communicates with WebSM server services on HMC and prompts for user name and password. Enter the username and password for HMC and click on Log on tab.
A successful authentication allows you to access the HCM GUI as shown below.

Step 2: Plan for the resource allocation to a new LPAR.Before creating any new LPAR, one should plan thoroughly for the resource allocation. An agreement should be made on the minimum, desired and maximum value of processors & memory, shared or dedicated processors and type and number of I/O cards.
In the example to follow, we are creating a new LPAR adcapsap03-HRNEW with following resources
1. CPU – Mode - Shared Processing unit - 0.2 min, 0.5 desired, 1.0 max Virual CPU – 1 min, 1 desired, 2 max
2.Memory – 4 GB min, 8 GB desired , 10 GB Max
3.I/0 cards – 1 * SCSI controller with 4 SCSI disks
(U5791.001.99B064P-P1-T5)
2 * 2Gbps fiber channel cards (U5791.001.99B064P-P1-C05) (U5791.001.99B064P-P2-C08)
3 * Virtual Ethernet cards (U5791.001.99B0760-P2-C06)
Resource allocation for the SAP p590 is mentioned in a separate document.

Step 3: Creating new LPAR
On the left panel, click on adcaphmc01.uk.rweutil.net -> server and partitions ->server management. The right panel will now display the p590 server and the
partitions under it. Right click on thames-p50-01

select Create -> logical partition

This would start a wizard for creating the new LPAR

On this screen, type the partition name as adcapsap03-HR3NEW and select partition environment as AIX or Linux.

Click on Next

This screen prompts for adding the logical partition to a Workload group. Since we are not using any Workload group, so select NO and Click on Next. The following screen prompts for logical partition profile name. Type Profile name as Normal and Click on Next. The following wizard screen prompts for the minimum, desired and maximum value of memory.



As mentioned in step 2, we select the values of minimum, desired and maximum memory as 4GB, 8GB and 10GBrespectively.
Click on Next The following wizard screen prompts for the Processor allocation.

Because we are using micro partitioning for the development, test and training servers, so select the Shared radio button.
For production servers we would be assigning dedicated processors for the LPAR.I this example we are creating LPAR for a SAP development server, so we select Shared mode and Click on Next.
The following screen prompts for the processing setting



As mentioned in step 2, we enter the value of minimum, desired and maximum processing units as 0.2, 05 and 1.0 respectively.
click on Advance tab.



Select processing sharing mode as Uncapped with Weight as 128. Under Virtual processor panel, select minimum, desired and maximum values as 1,1 and 2 respectively. Click on OK tab. Again Click on Next to proceed further.
The following wizard screen will prompt for I/O resources.

Select the I/O resources as mentioned in step 2

Select U5791.001.99B064P-P1-T5 SCSI bus controller and click on Add as required.
This would add the I/O device to the LPAR profile in pane below.

In a similar way add I/O U5791.001.99B064P-P1-C05 Fiber channel card and
U5791.001.99B064P-P2-C08 Fiber channel card to the LPAR profile.

Similarly add U5791.001.99B0760-P2-C06 Ethernet adapter to the profile I/O devices.

Once all the resources are added to the profile I/O devices as required, Click on Next.
The following wizard screen prompts for I/O pools. Since we are not using any shared I/O pool, so ignore this screen.



Click on Next
The following wizard screen prompts for the Virtual I/O Adapters. We are not making any use of Virtual I/O devices in this example.

Select No and Click on Next
The following screen prompts for the power controlling partition. For the all the LPARS that we have defined, the default partition 83-8C6DB(1) is acting as the power controlling partition.

Ensure that the default partition 83-8C6DB(1) is displayed in the drop down list and click Next.
The following screen prompts for the Boot mode.

Select the Boot mode as Normal and click on next
The following wizard screen is a summary Screen. If you want to make any changes on previous screens, the you can use previous tab to scroll back and make changes if any. If you are sure of your selections, the click on Finish tab and this would create the new LPAR.
You will now see a status screen



Once the creation of LPAR is successful, the new LPAR is displayed under the managed system thames-p50-01.

You can see that the new LPAR adcapsap03-HRNEW under managed system thames-p590-01.
You can recheck the resource allocation by right clicking the profile and selecting properties.

This end the procedure to create a new LPAR using dedicated resources.

IBM AIX - Creating a New LPAR using HMC CLI

2012-12-15T00:31:00.002+05:30

IBM AIX - Creating a New LPAR using HMC CLI

Here is an example, for more information see '''man mksyscfg'''
mksyscfg -r lpar -m MACHINE -i name=LPARNAME, profile_name=normal, lpar_env=aixlinux, shared_proc_pool_util_auth=1, min_mem=512, desired_mem=2048, max_mem=4096, proc_mode=shared, min_proc_units=0.2, desired_proc_units=0.5, max_proc_units=2.0, min_procs=1, desired_procs=2, max_procs=2, sharing_mode=uncap, uncap_weight=128, boot_mode=norm, conn_monitoring=1, shared_proc_pool_util_auth=1

If you want to create more LPARS at once you can use a configuration file and provide it as input for mksyscfg.
Here is an example for 3 LPARs, each definition starting at new line:
name=LPAR1,profile_name=normal,lpar_env=aixlinux,all_resources=0,min_mem=1024,desired_mem=9216,max_mem=9216,proc_mode=shared,min_proc_units=0.3,desired_proc_units=1.0,max_proc_units=3.0,min_procs=1,desired_procs=3,max_procs=3,sharing_mode=uncap,uncap_weight=128,lpar_io_pool_ids=none,max_virtual_slots=10,"virtual_scsi_adapters=6/client/4/vio1a/11/1,7/client/9/vio2a/11/1","virtual_eth_adapters=4/0/3//0/1,5/0/4//0/1",boot_mode=norm,conn_monitoring=1,auto_start=0,power_ctrl_lpar_ids=none,work_group_id=none,shared_proc_pool_util_auth=1
name=LPAR2,profile_name=normal,lpar_env=aixlinux,all_resources=0,min_mem=1024,desired_mem=9216,max_mem=9216,proc_mode=shared,min_proc_units=0.3,desired_proc_units=1.0,max_proc_units=3.0,min_procs=1,desired_procs=3,max_procs=3,sharing_mode=uncap,uncap_weight=128,lpar_io_pool_ids=none,max_virtual_slots=10,"virtual_scsi_adapters=6/client/4/vio1a/12/1,7/client/9/vio2a/12/1","virtual_eth_adapters=4/0/3//0/1,5/0/4//0/1",boot_mode=norm,conn_monitoring=1,auto_start=0,power_ctrl_lpar_ids=none,work_group_id=none,shared_proc_pool_util_auth=1
name=LPAR3,profile_name=normal,lpar_env=aixlinux,all_resources=0,min_mem=1024,desired_mem=15360,max_mem=15360,proc_mode=shared,min_proc_units=0.4,desired_proc_units=1.0,max_proc_units=4.0,min_procs=1,desired_procs=4,max_procs=4,sharing_mode=uncap,uncap_weight=128,lpar_io_pool_ids=none,max_virtual_slots=10,"virtual_scsi_adapters=6/client/4/vio1a/13/1,7/client/9/vio2a/13/1","virtual_eth_adapters=4/0/3//0/1,5/0/4//0/1",boot_mode=norm,conn_monitoring=1,auto_start=0,power_ctrl_lpar_ids=none,work_group_id=none,shared_proc_pool_util_auth=1
Copy this file to HMC and run: mksyscfg -r lpar -m SERVERNAME -f /tmp/profiles.txt

If you already have LPARs created you can use this command to get their configuration which can be reused as template: lssyscfg -r prof -m SERVERNAME --filter "lpar_ids=X, profile_names=normal"

IBM AIX - OS Upgrade nimadm 12 phases

2012-12-15T00:13:00.001+05:30

IBM AIX - OS Upgrade nimadm 12 phases!!

The nimadm utility offers several advantages over a conventional migration. Following are the advantages of nimadm over other migration methods:

Reduced downtime for the client: The migration can execute while the system is up and running as normal. There is no disruption to any of the applications or services running on the client. Therefore, the upgrade can be done at a anytime time. Once upgrade complete we need take a downtime from the client and scheduled a reboot in order to restart the system at the later level of AIX.

Flexibility: The nimadm process is very flexible and it can be customized using some of the optional NIM customization resources, such as image_data, bosinst_data, pre/post_migration scripts, exclude_files, and so on.

Quick recovery from migration failures: All changes are performed on the copied rootvg (altinst_rootvg). If there are any problems with the migration, the original rootvg is still available and the system has not been impacted. If a migration fails or terminates at any stage, nimadm is able to quickly recover from the event and clean up afterwards. There is little for the administrator to do except determine why the migration failed, rectify the situation, and attempt the nimadm process again. If the migration completed but issues are discovered after the reboot, then the administrator can back out easily by booting from the original rootvg disk.
The nimadm command performs a migration in 12 phases. All migration activity is logged on the NIM master in the /var/adm/ras/alt_mig directory. It is useful to have knowledge of each phase before performing a migration. After starting the alt_disk process from NIM master we output as below, these are pre ALT_DISK steps

0513-029 The biod Subsystem is already active.
Multiple instances are not supported.
0513-059 The nfsd Subsystem has been started. Subsystem PID is 3780796.
0513-059 The rpc.mountd Subsystem has been started. Subsystem PID is 1237104.
0513-059 The nfsrgyd Subsystem has been started. Subsystem PID is 3477732.
0513-059 The gssd Subsystem has been started. Subsystem PID is 3743752.
0513-029 The rpc.lockd Subsystem is already active.
Multiple instances are not supported.
0513-029 The rpc.statd Subsystem is already active.
Multiple instances are not supported.
starting upgrade now
Initializing the NIM master.
Initializing NIM client webmanual01.
Verifying alt_disk_migration eligibility.
Initializing log: /var/adm/ras/alt_mig/webmanual01_alt_mig.log
Starting Alternate Disk Migration.

Explanation of Phase 1 : After starting nfsd , rpc.mountd , gssd , nfsrgyd,rpc.lockd, rpc.statd process in the pre ALT_DISK , the master issues the alt_disk_install command to the client, which makes a copy of the clients rootvg to the target disks. In this phase, the alternate root volume group (altinst_rootvg) is created.

+-----------------------------------------------------------------------------+
Executing nimadm phase 1.
+-----------------------------------------------------------------------------+
Cloning altinst_rootvg on client, Phase 1.
Client alt_disk_install command: alt_disk_copy -j -M 6.1 -P1 -d "hdisk0"
Calling mkszfile to create new /image.data file.
Checking disk sizes.
Creating cloned rootvg volume group and associated logical volumes.
Creating logical volume alt_hd5
Creating logical volume alt_hd6
Creating logical volume alt_hd8
Creating logical volume alt_hd4
Creating logical volume alt_hd2
Creating logical volume alt_hd9var
Creating logical volume alt_hd3
Creating logical volume alt_hd1
Creating logical volume alt_hd10opt
Creating logical volume alt_lg_dumplv
Creating logical volume alt_lv_admin
Creating logical volume alt_lv_sw
Creating logical volume alt_lg_crmhome
Creating logical volume alt_lv_crmhome
Creating logical volume alt_paging00
Creating logical volume alt_hd11admin
Creating /alt_inst/ file system.
Creating /alt_inst/admin file system.
Creating /alt_inst/adminOLD file system.
Creating /alt_inst/crmhome file system.
Creating /alt_inst/home file system.
Creating /alt_inst/opt file system.
Creating /alt_inst/software file system.
Creating /alt_inst/tmp file system.
Creating /alt_inst/usr file system.
Creating /alt_inst/var file system.
Generating a list of files
for backup and restore into the alternate file system...
Phase 1 complete.

Explanation of Phase 2 : The NIM master creates the cache file systems in the nimadmvg volume group. Some initial checks for the required migration disk space are performed.

+-----------------------------------------------------------------------------+
Executing nimadm phase 2.
+-----------------------------------------------------------------------------+
Creating nimadm cache file systems on volume group nimvg.
Checking for initial required migration space.
Creating cache file system /webmanual01_alt/alt_inst
Creating cache file system /webmanual01_alt/alt_inst/admin
Creating cache file system /webmanual01_alt/alt_inst/adminOLD
Creating cache file system /webmanual01_alt/alt_inst/crmhome
Creating cache file system /webmanual01_alt/alt_inst/home
Creating cache file system /webmanual01_alt/alt_inst/opt
Creating cache file system /webmanual01_alt/alt_inst/sw
Creating cache file system /webmanual01_alt/alt_inst/tmp
Creating cache file system /webmanual01_alt/alt_inst/usr
Creating cache file system /webmanual01_alt/alt_inst/var

Explanation of Phase 3 : The NIM master copies the NIM client’s data to the cache file systems in nimvg. This data copy is done by either rsh or nimsh.

+-----------------------------------------------------------------------------+
Executing nimadm phase 3.
+-----------------------------------------------------------------------------+
Syncing client data to cache ...
cannot access ./tmp/alt_lock: A file or directory in the path name does not exist.

Explanation of Phase 4 : If a pre-migration script resource has been specified, it is executed at this time.

+-----------------------------------------------------------------------------+
Executing nimadm phase 4.
+-----------------------------------------------------------------------------+
nimadm: There is no user customization script specified for this phase.

Explanation of Phase 5 : System configuration files are saved. Initial migration space is calculated and appropriate file system expansions are made. The bos image is restored and the device database is merged. All of the migration merge methods are executed, and some miscellaneous processing takes place.

+-----------------------------------------------------------------------------+
Executing nimadm phase 5.
+-----------------------------------------------------------------------------+
Saving system configuration files.
Checking for initial required migration space.
Setting up for base operating system restore.
/webmanual01_alt/alt_inst
Restoring base operating system.
Merging system configuration files.
Running migration merge method: ODM_merge Config_Rules.
Running migration merge method: ODM_merge SRCextmeth.
Running migration merge method: ODM_merge SRCsubsys.
Running migration merge method: ODM_merge SWservAt.
Running migration merge method: ODM_merge pse.conf.
Running migration merge method: ODM_merge vfs.
Running migration merge method: ODM_merge xtiso.conf.
Running migration merge method: ODM_merge PdAtXtd.
Running migration merge method: ODM_merge PdDv.
Running migration merge method: convert_errnotify.
Running migration merge method: passwd_mig.
Running migration merge method: login_mig.
Running migration merge method: user_mrg.
Running migration merge method: secur_mig.
Running migration merge method: RoleMerge.
Running migration merge method: methods_mig.
Running migration merge method: mkusr_mig.
Running migration merge method: group_mig.
Running migration merge method: ldapcfg_mig.
Running migration merge method: ldapmap_mig.
Running migration merge method: convert_errlog.
Running migration merge method: ODM_merge GAI.
Running migration merge method: ODM_merge PdAt.
Running migration merge method: merge_smit_db.
Running migration merge method: ODM_merge fix.
Running migration merge method: merge_swvpds.
Running migration merge method: SysckMerge.

Explanation of Phase 6: All system filesets are migrated using installp. Any required RPM images are also installed during this phase.

+-----------------------------------------------------------------------------+
Executing nimadm phase 6.
+-----------------------------------------------------------------------------+
Installing and migrating software.
Updating install utilities.
+-----------------------------------------------------------------------------+
Pre-installation Verification...
+-----------------------------------------------------------------------------+
Verifying selections...done
Verifying requisites...done
Results...

SUCCESSES
---------
Filesets listed in this section passed pre-installation verification
and will be installed.

Mandatory Fileset Updates
-------------------------
(being installed automatically due to their importance)
bos.rte.install 6.1.6.15 # LPP Install Commands

<< End of Success Section >>

+-----------------------------------------------------------------------------+
BUILDDATE Verification ...
+-----------------------------------------------------------------------------+
Verifying build dates...done
FILESET STATISTICS
------------------
1 Selected to be installed, of which:
1 Passed pre-installation verification
----
1 Total to be installed

+-----------------------------------------------------------------------------+
Installing Software...
+-----------------------------------------------------------------------------+

installp: APPLYING software for:
bos.rte.install 6.1.6.15

. . . . . << Copyright notice for bos >> . . . . . . .
Licensed Materials - Property of IBM

[LOTS OF OUTPUT]

Installation Summary
--------------------
Name Level Part Event Result
-------------------------------------------------------------------------------
lwi.runtime 6.1.6.15 USR APPLY SUCCESS
lwi.runtime 6.1.6.15 ROOT APPLY SUCCESS
X11.compat.lib.X11R6_motif 6.1.6.15 USR APPLY SUCCESS
Java5.sdk 5.0.0.395 USR APPLY SUCCESS
Java5.sdk 5.0.0.395 ROOT APPLY SUCCESS
Java5.sdk 5.0.0.395 USR COMMIT SUCCESS
Java5.sdk 5.0.0.395 ROOT COMMIT SUCCESS
lwi.runtime 6.1.6.15 USR COMMIT SUCCESS
lwi.runtime 6.1.6.15 ROOT COMMIT SUCCESS
X11.compat.lib.X11R6_motif 6.1.6.15 USR COMMIT SUCCESS 

install_all_updates: Generating list of updatable rpm packages.
install_all_updates: No updatable rpm packages found.

install_all_updates: Checking for recommended maintenance level 6100-06.
install_all_updates: Executing /usr/bin/oslevel -rf, Result = 6100-06
install_all_updates: Verification completed.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Result = SUCCESS
Known Recommended Maintenance Levels
------------------------------------
Restoring device ODM database.

Explanation of Phase 7 : If a post-migration script resource has been specified, it is executed at this time.

+-----------------------------------------------------------------------------+
Executing nimadm phase 7.
+-----------------------------------------------------------------------------+
nimadm: There is no user customization script specified for this phase.

Explanation of Phase 8 : The bosboot command is run to create a client boot image, which is written to the client’s alternate boot logical volume (alt_hd5)

+-----------------------------------------------------------------------------+
Executing nimadm phase 8.
+-----------------------------------------------------------------------------+
Creating client boot image.
bosboot: Boot image is 47136 512 byte blocks.
Writing boot image to client's alternate boot disk hdisk0.

Explanation of Phase 9 : All the migrated data is now copied from the NIM master’s local cache file and synced to the client’s alternate rootvg.

+-----------------------------------------------------------------------------+
Executing nimadm phase 9.
+-----------------------------------------------------------------------------+
Adjusting client file system sizes ...
Adjusting size for /
Adjusting size for /admin
Adjusting size for /adminOLD
Adjusting size for /crmhome
Adjusting size for /home
Adjusting size for /opt
Adjusting size for /sw
Adjusting size for /tmp
Adjusting size for /usr
Expanding /alt_inst/usr client filesystem.
Filesystem size changed to 12058624
Adjusting size for /var
Syncing cache data to client ...

Explanation of Phase 10 : The NIM master cleans up and removes the local cache file systems.

+-----------------------------------------------------------------------------+
Executing nimadm phase 10.
+-----------------------------------------------------------------------------+
Unmounting client mounts on the NIM master.
forced unmount of /webmanual01_alt/alt_inst/var
forced unmount of /webmanual01_alt/alt_inst/usr
forced unmount of /webmanual01_alt/alt_inst/tmp
forced unmount of /webmanual01_alt/alt_inst/sw
forced unmount of /webmanual01_alt/alt_inst/opt
forced unmount of /webmanual01_alt/alt_inst/home
forced unmount of /webmanual01_alt/alt_inst/crmhome
forced unmount of /webmanual01_alt/alt_inst/adminOLD
forced unmount of /webmanual01_alt/alt_inst/admin
forced unmount of /webmanual01_alt/alt_inst
Removing nimadm cache file systems.
Removing cache file system /webmanual01_alt/alt_inst
Removing cache file system /webmanual01_alt/alt_inst/admin
Removing cache file system /webmanual01_alt/alt_inst/admin
Removing cache file system /webmanual01_alt/alt_inst/crmhome
Removing cache file system /webmanual01_alt/alt_inst/home
Removing cache file system /webmanual01_alt/alt_inst/opt
Removing cache file system /webmanual01_alt/alt_inst/sw
Removing cache file system /webmanual01_alt/alt_inst/tmp
Removing cache file system /webmanual01_alt/alt_inst/usr
Removing cache file system /webmanual01_alt/alt_inst/var

Explanation of Phase 11 :The alt_disk_install command is called again to make the final adjustments and put altinst_rootvg to sleep. The bootlist is set to the target disk

+-----------------------------------------------------------------------------+
Executing nimadm phase 11.
+-----------------------------------------------------------------------------+
Cloning altinst_rootvg on client, Phase 3.
Client alt_disk_install command: alt_disk_copy -j -M 6.1 -P3 -d "hdisk0"
## Phase 3 ###################
Verifying altinst_rootvg...
Modifying ODM on cloned disk.
forced unmount of /alt_inst/var
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/sw
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/home
forced unmount of /alt_inst/crmhome
forced unmount of /alt_inst/admin
forced unmount of /alt_inst/admin
forced unmount of /alt_inst
Changing logical volume names in volume group descriptor area.
Fixing LV control blocks...
Fixing file system superblocks...
Bootlist is set to the boot disk: hdisk0 blv=hd5

Explanation of Phase 12: Cleanup is executed to end the migration.

+-----------------------------------------------------------------------------+
Executing nimadm phase 12.
+-----------------------------------------------------------------------------+
Cleaning up alt_disk_migration on the NIM master.
Cleaning up alt_disk_migration on client webmanual01.
Please review log to verify success
Initializing the NIM master.
Initializing NIM client webmanual01.
Verifying alt_disk_migration eligibility.
Initializing log: /var/adm/ras/alt_mig/webmanual01_alt_mig.log
Starting Alternate Disk Migration.

After the migration is complete, login to client and confirm bootlist is set to the altinst_rootvg disk.

# lspv | grep rootvg
Hdisk1 0000273ac30fdcfc rootvg active
hdisk0 000273ac30fdd6e altinst_rootvg active

# bootlist -m normal -o
Hdisk0 blv=hd5

Power 6 Video Tutorial / Training by Nigel Griffith

2012-10-25T21:37:00.001+05:30

Power Basic Introduction - by Nigel Griffith

Uploading more!! will be here in few days!!!!!!!!!!

HMC Upgrade using network images

2012-10-25T21:03:00.000+05:30

HMC Upgrade using network images

01. Download the appropriate HMC V7 network images and put them on an FTP server.

02. Verify that the following files have been downloaded:

initrd.gz, bzImage, disk1.img, disk2.img, and disk3.img

03. On the HMC, you must first save upgrade data by running the following commands:

   3a. To save data to both DVD and disk:
        mount /media/cdrom
        saveupgdata -r diskdvd
   3b. To save to disk alone:
        saveupgdata -r disk

04. Next, copy the files over to the bootable disk partition on the HMC from FTP server

    4a. getupgfiles -h remote_hostname -u --passwd -d
    Note: use -s to use sftp instead of ftp.
    4b. If you want to see the progress of copy process, run the following command
    while true; do ls -la /hmcdump; sleep 30; done

05. After the files are copied over, run the following command:

    chhmc -c altdiskboot -s enable --mode upgrade

    Now the HMC is ready to be rebooted and automatically upgraded with the code copied to the bootable disk partition.

06. Finally, reboot the HMC and start the upgrade.

    hmcshutdown -r -t now

How to find wwn in Redhat Linux?

2012-10-25T20:05:00.001+05:30

How to find wwn in Redhat Linux?

a.    Below is the simple command to find WWN on Redhat servers.

systool -c fc_host –v

# systool -c fc_host -v | grep "port_name"
    port_name           = "0x5001438001347fdc"
    port_name           = "0x5001438001347fde"
    port_name           = "0x50014380013471f0"
    port_name           = "0x50014380013471f2"
#

b.    Below is the simple steps to find WWN in Linux.

Step 1: cd /sys/class/fc_host
Step 2: cd to the host# directory.
Step 3: cat node_name

Useful command to find to list the FC Adapter

lspci | grep -i Fibre

c.    To find WWN on linux with Emulex:
If you find difficult to find WWN on linux with Emulex HBA use below hbacmd to list the HBAs. This only available if hbanyware installed.

cd /usr/sbin/hbanyware
[root@tilak_phy01 hbanyware]# ./hbacmd ListHBAs

Manageable HBA List
Port WWN   : 11:00:00:00:d9:58:bf:92
Node WWN   : 10:00:00:00:b9:58:ba:92
Fabric Name: 20:3f:01:04:51:a1:71:00
Flags      : 1100a980
Host Name : tilak_phy01
Mfg        : Emulex Corporation

Netmask in Bits|Decimal|Hexadecimal|Binary

2012-10-19T20:50:00.000+05:30

Netmask in Bits|Decimal|Hexadecimal|Binary

Subnetmask Converter / Calculator

Bitmask (Bits)	Dotted Decimal	Hexadecimal	Binary
/0	0.0.0.0	0x00000000	00000000 00000000 00000000 00000000
/1	128.0.0.0	0x80000000	10000000 00000000 00000000 00000000
/2	192.0.0.0	0xc0000000	11000000 00000000 00000000 00000000
/3	224.0.0.0	0xe0000000	11100000 00000000 00000000 00000000
/4	240.0.0.0	0xf0000000	11110000 00000000 00000000 00000000
/5	248.0.0.0	0xf8000000	11111000 00000000 00000000 00000000
/6	252.0.0.0	0xfc000000	11111100 00000000 00000000 00000000
/7	254.0.0.0	0xfe000000	11111110 00000000 00000000 00000000
/8	255.0.0.0	0xff000000	11111111 00000000 00000000 00000000
/9	255.128.0.0	0xff800000	11111111 10000000 00000000 00000000
/10	255.192.0.0	0xffc00000	11111111 11000000 00000000 00000000
/11	255.224.0.0	0xffe00000	11111111 11100000 00000000 00000000
/12	255.240.0.0	0xfff00000	11111111 11110000 00000000 00000000
/13	255.248.0.0	0xfff80000	11111111 11111000 00000000 00000000
/14	255.252.0.0	0xfffc0000	11111111 11111100 00000000 00000000
/15	255.254.0.0	0xfffe0000	11111111 11111110 00000000 00000000
/16	255.255.0.0	0xffff0000	11111111 11111111 00000000 00000000
/17	255.255.128.0	0xffff8000	11111111 11111111 10000000 00000000
/18	255.255.192.0	0xffffc000	11111111 11111111 11000000 00000000
/19	255.255.224.0	0xffffe000	11111111 11111111 11100000 00000000
/20	255.255.240.0	0xfffff000	11111111 11111111 11110000 00000000
/21	255.255.248.0	0xfffff800	11111111 11111111 11111000 00000000
/22	255.255.252.0	0xfffffc00	11111111 11111111 11111100 00000000
/23	255.255.254.0	0xfffffe00	11111111 11111111 11111110 00000000
/24	255.255.255.0	0xffffff00	11111111 11111111 11111111 00000000
/25	255.255.255.128	0xffffff80	11111111 11111111 11111111 10000000
/26	255.255.255.192	0xffffffc0	11111111 11111111 11111111 11000000
/27	255.255.255.224	0xffffffe0	11111111 11111111 11111111 11100000
/28	255.255.255.240	0xfffffff0	11111111 11111111 11111111 11110000
/29	255.255.255.248	0xfffffff8	11111111 11111111 11111111 11111000
/30	255.255.255.252	0xfffffffc	11111111 11111111 11111111 11111100
/31	255.255.255.254	0xfffffffe	11111111 11111111 11111111 11111110
/32	255.255.255.255	0xffffffff	11111111 11111111 11111111 11111111

IBM AIX - ODM

2012-10-11T10:20:00.002+05:30

What is ODM?

ODM

Maintains system config, device and vital product data
Provide a more robust, secure and sharable resource
Provide a reliable object oriented database facility

Data Managed By ODM

Device Configuration Information
Software Vital Product Data
SRC information
Communications configuration data
Menus and commands for SMIT

ODM has three components

Object class - These are datafiles.
Objects - Records within Datafiles
Descriptors - Field within a record

Where ODM Object Class files are stored?

This can be defined in /etc/environment file. The ODM object clases are held in three repositories

/etc/objrepos
/usr/lib/objrepos
/usr/share/lib/objrepos

Some important ODM Database files

Supported devices and attributes and connection information are stored in

PdDv, PdAt, PdCn, etc..

Records or customizrd Devices and attributes, VPD are stored in

CuDv, CuAt, CuDep, Config_Rules, CuVPD, etc ...

Have software information

lpp, history, product, inventory, etc..

SMIT menus, commands, options

sm_cmd_hdr, sm_cmd_opt, sm_menu_opt

NIM Resource and configuraion informations

nim_object, nim_pdattr, nim_altr

Errorlog, alog and dump file info

SWservAt

Useful ODM Commands

odmget - To retrives objects from an Object Class in stanza format

odmdelete - To delete objects what meet a specifig criteria. If no criteria specified, all objects are deleted

odmadd - To add a new object to an object class

odmchange - To change all objects with in an Object Class that meet a specifig criteria

odmshow - To display object class definition

odmcreate - To create Object Class for application that will use ODM DB

odmdrop - To remove an Oobject Class

Some ODM Command examples

To list all records with an Object Class CuDv

# odmget CuDv

To find out an object within CuAt with condition name=sys0 and attibute=maxuproc

# odmget -q "name=sys0 and attribute=maxuproc" CuAt CuAt: name = "sys0" attribute = "maxuproc" value = "2000" type = "R" generic = "DU" rep = "nr" nls_index = 20

To delete the above object

# odmget -q "name=sys0 and attribute=maxuproc" CuAt > file.1 # odmdelete -q "name=sys0 and attribute=maxuproc" -o CuAt

To add the deleted object again to the above object class

# odmadd file.1 # add the file content to appropriate Object class

Fix ODM related errors for devices (CuDv Object Class)

$ cfgmgr
cfgmgr: 0514-604 Cannot access the CuDv object class in the
device configuration database.

The Fix:

01. cd /etc/oberepos 02. cp Config_Rules Config_Rules.backup 03. odmget -q rule="/etc/methods/darcfgrule" Config_Rules 04. odmdelete -q rule="/etc/methods/darcfgrule" -o Config_Rules 05. savebase -v 06. cfgmgr

IBM AIX - Boot Process

2012-10-10T01:47:00.000+05:30

AIX Boot Process

When the server is Powered on Power on self test(POST) is run and checks the hardware
On successful completion on POST Boot logical volume is searched by seeing the bootlist
The AIX boot logical contains AIX kernel, rc.boot, reduced ODM & BOOT commands. AIX kernel is loaded in the RAM.
Kernel takes control and creates a RAM file system.
Kernel starts /etc/init from the RAM file system
init runs the rc.boot 1 ( rc.boot phase one) which configures the base devices.
rc.boot1 calls restbase command which copies the ODM files from Boot Logical Volume to RAM file system
rc.boot1 calls cfgmgr –f command to configure the base devices
rc.boot1 calls bootinfo –b command to determine the last boot device
Then init starts rc.boot2 which activates rootvg
rc.boot2 calls ipl_varyon command to activate rootvg
rc.boot2 runs fsck –f /dev/hd4 and mount the partition on / of RAM file system
rc.boot2 runs fsck –f /dev/hd2 and mounts /usr file system
rc.boot2 runs fsck –f /dev/hd9var and mount /var file system and runs copy core command to copy the core dump if available from /dev/hd6 to /var/adm/ras/vmcore.0 file. And unmounts /var file system
rc.boot2 runs swapon /dev/hd6 and activates paging space
rc.boot2 runs migratedev and copies the device files from RAM file system to /file system
rc.boot2 runs cp /../etc/objrepos/Cu* /etc/objrepos and copies the ODM files from RAM file system to / filesystem
rc.boot2 runs mount /dev/hd9var and mounts /var filesystem
rc.boot2 copies the boot log messages to alog
rc.boot2 removes the RAM file system
Kernel starts /etc/init process from / file system
The /etc/init points /etc/inittab file and rc.boot3 is started. Rc.boot3 configures rest of the devices
rc.boot3 runs fsck –f /dev/hd3 and mount /tmp file system
rc.boot3 runs syncvg rootvg &
rc.boot3 runs cfgmgr –p2 or cfgmgr –p3 to configure rest of the devices. Cfgmgr –p2 is used when the physical key on MCA architecture is on normal mode and cfgmgr –p3 is used when the physical key on MCA architecture is on service mode.
rc.boot3 runs cfgcon command to configure the console
rc.boot3 runs savebase command to copy the ODM files from /dev/hd4 to /dev/hd5
rc.boot3 starts syncd 60 & errordaemon
rc.boot3 turn off LED’s
rc.boot3 removes /etc/nologin file
rc.boot3 checks the CuDv for chgstatus=3 and displays the missing devices on the console
The next line of Inittab is executed

/etc/inittab file format: identifier:runlevel:action:command

Mkitab-----Add records to the /etc/inittab file

Lsitab-----List records in the /etc/inittab file

Chitab-----changes records in the /etc/inittab file

Rmitab-----removes records from the /etc/inittab file

zLinux - LVM using Multipath disks!!

2012-10-05T05:56:00.002+05:30

1. Take a backup of /etc/zfcp.conf file.

2. Add the LUN entries which are provided in /etc/zfcp.conf file.

Example:

## 300GB LUN for the FS /opt/tibcoBPM

0.0.dc00 0x50060e800571f006 0x0051000000000000

0.0.dd00 0x50060e800571f007 0x0051000000000000

0.0.de00 0x50060e800571f016 0x0051000000000000

0.0.df00 0x50060e800571f017 0x0051000000000000

## 200GB LUN for the FS /opt/dataSTG

0.0.dc00 0x50060e800571f006 0x0052000000000000

0.0.dd00 0x50060e800571f007 0x0052000000000000

0.0.de00 0x50060e800571f016 0x0052000000000000

0.0.df00 0x50060e800571f017 0x0052000000000000

Make note of the LUN ID as highlighted above (51 & 52)

3. Take the fdisk -l | grep -i "/dev/dm-" and multipath -ll output.

4. Execute this sbin script zfcpconf.sh from anywhere as root to get the allocated disk.

5. Take fdisk -l and multipath -ll output and cross verify multipath -ll with the previous one, to get the newly added disks mpath. For the newly added mpath name will look like this /dev/dm-xx, add /dev to the mpath name for the device name. Example /dev/dm-xx.

Example : from Fdisk Output, found the below were the new disk after comparing with previous output.

Disk /dev/dm-12 doesn't contain a valid partition table

Disk /dev/dm-23 doesn't contain a valid partition table

Example : from multipath -ll output got the below new mpath with disk name

mpath8 (360060e800571f000000071f00000fd52) dm-23 HITACHI,OPEN-V

[size=200G][features=1 queue_if_no_path][hwhandler=0][rw]

\_ round-robin 0 [prio=0][active]

\_ 3:0:0:7 sdy 65:128 [active][ready]

\_ 0:0:0:9 sdz 65:144 [active][ready]

\_ 1:0:0:6 sdaa 65:160 [active][ready]

\_ 2:0:0:6 sdab 65:176 [active][ready]

mpath7 (360060e800571f000000071f00000fd51) dm-12 HITACHI,OPEN-V

[size=300G][features=1 queue_if_no_path][hwhandler=0][rw]

\_ round-robin 0 [prio=0][enabled]

\_ 0:0:0:8 sdv 65:80 [active][ready]

\_ 1:0:0:5 sdw 65:96 [active][ready]

\_ 2:0:0:5 sdx 65:112 [active][ready]

\_ 3:0:0:8 sdac 65:192 [active][ready]

Make sure all the paths available in mpath. Like if you see the zfcp.conf entry for each disk 4 entries made, so 4 path should be available in the multipath –ll output aswell.

If not contact Storage Team or Mainframe team to get the failed paths fixed before creating the Physical Volume.

6. Create the PV with the mpath device name.

Example : pvcreate /dev/dm-12 /dev/dm-23

Cross check in pvdisplay or pvs output

/dev/dm-12 lvm2 -- 300.00G 300.00G

/dev/dm-23 lvm2 -- 200.00G 200.00G

7. Create the mountpoint if it is not available already.

mkdir /opt/tibcoBPM and /opt/dataSTG.

8. Set the ownership for the mount points created, verify with the requester.

Example:

chown -R tibco_u:tibco_g /opt/tibcoBPM

chown -R datastg_u:datastg_g /opt/dataSTG

9. Here, I am creating separate volume groups for each filesystem as per the request.

vgcreate (You can identify from multipath –ll for the new disk size)

vgcreate tibcoBPM_vg /dev/dm-12

vgcreate dataSTG_vg /dev/dm-23

Verify it with vgdisplay and vgs output.

tibcoBPM_vg 1 0 0 wz--n- 300.00G 300.00G

dataSTG_vg 1 0 0 wz--n- 200.00G 200.00G

10. Create the LV on the appropriate VG with the requested FS size. I had used the below command to use the entire VG space.

lvcreate -l 100%FREE -n tibcoBPM_lv tibcoBPM_vg

lvcreate -l 100%FREE -n dataSTG_lv dataSTG_vg

Verify with lvdisplay and lvs outputs

tibcoBPM_lv tibcoBPM_vg -wi-a- 300.00G

dataSTG_lv dataSTG_vg -wi-a- 200.00G

lvscan output

ACTIVE '/dev/tibcoBPM_vg/tibcoBPM_lv' [300.00 GB] inherit

ACTIVE '/dev/dataSTG_vg/dataSTG_lv' [200.00 GB] inherit

11. Format it to ext3 filesystem with the below command. Get the LV path from lvscan output.

mkfs.ext3 /dev/tibcoBPM_vg/tibcoBPM_lv

mkfs.ext3 /dev/dataSTG_vg/dataSTG_lv

12. Mount the LV to the created mount point, by making the entry to /etc/fstab. Manual mount is not recommended.

Similar way get the LV full path from lvscan output and make the entry as below. Take a backup of /etc/fstab “cp /etc/fstab /etc/fstab_bkp_”.

/dev/tibcoBPM_vg/tibcoBPM_lv /opt/tibcoBPM ext3 defaults 1 2

/dev/dataSTG_vg/dataSTG_lv /opt/dataSTG ext3 defaults 1 2

13. Take df –hT output prior mounting the FS and use “mount /opt/tibcoBPM” and “mount /opt/dataSTG”

[root@zos_linux1 /]# df -hT /opt/tibcoBPM /opt/dataSTG

Filesystem Type Size Used Avail Use% Mounted on

/dev/mapper/tibcoBPM_vg-tibcoBPM_lv

ext3 296G 191M 281G 1% /opt/tibcoBPM

/dev/mapper/dataSTG_vg-dataSTG_lv

ext3 197G 188M 187G 1% /opt/dataSTG

[root@zos_linux1 /]#

14. The End!!

IBM AIX - NIM Made Easy - A complete Overview!!

2012-10-03T05:20:00.000+05:30

Master: It refers the machine where you setup and maintain your NIM environment

Client: It can be target for NIM Master-operations. Such as installation, updation.

NIM Classes: Machines, Network, Resources, Groups

Group: Collection of machines or resources

Resources : lpp_source, SPOT, mksysb, bosinst_data, script, image_data, installp_bundle

lsnim – extract the contents in nim master

lsnim –c machines Shows the machine names

lsnim –l

/etc/bootptab: This file is used by the bootpd daemon. With no operations this file empty. This file gets updated automatically by the NIM master when a NIM operation is executed that requires the client machine to boot from a NIM SPOT.

/etc/exports: Any sort of installation, boot, mksysb savevg etc operation requires the use of NFS. This file will be updated with which locations are NFS exported from the master to the client and the permissions associated with those exports.

/etc/hosts: It gives a relationship between a system’s hostname and an IP address. If your IP address does not match up to the correct hostname your installation fails.

/etc/niminfo: This file should always exist on the NIM master. This file is built when you first initialize the NIM environment. This is required to run nim commands and perform nim operations. If the /etc/niminfo file accidentally deleted you can rebuild the file.

/tftpboot: The main purpose of this directory is to hold the boot images that are created by nim when a boot or installation is initiated. This directory also holds informational files about the clients that are having a boot or installation operation performed.

SPOT: Shared product object tree.Its a directory of code(installed filesets). That is used during client booting procedure. This content equals to /usr file system(Binaries, executables and libraries, header files and shell scripts).

boot images can exist in the /tftpboot directory. kernels will be stored in /tftpboot directory.

lsnim -t spot -> list the different available spots

To find oslevel -r output by lsnim -l . If the SPOT and mksysb are not at the same level, installation will only work if the SPOT is at higher level than the mksysb.

lpp_source: Similar to AIX install CD’s. It contains AIX licensed program products(LPPs) in Backup File Format.

Lpp_source with attribute simages=yes means create a SPOT, and to install the AIX operating system.

Lpp_source with attribute simages=no means can not be used to install base AIX operating system.

lpp_source types: lsnim -t lpp_source

Mksysb:this resource is a file containing the image of the root volume group of machine.

It is used to restore a machine.

Defining MKSYSB resource:Nim –o define –t mksysb –a source= -a server=master –a location= resource name.

Lsnim –t mksyb

bosinst_data: bosinst_data resource is a flat ascii file, like bosinst.data used for restoring system backup images from tape or CD/DVD. this resource is for Push/pull installation of multiple machines at the same time.

script: contains all the commands to perform customization. such as file system resizing, additional user creation ..

To start a nim environment

Select a machine to be the master
Install AIX for the master
install NIM file sets : bos.sysmgt.nim.master, bos.sysmgt.nim.spot
Configure the selected machine as a NIM Master using smitty nimconfig Mention Network name, Interface : nimconfig –a netname=net_10_1_1 –a pif_name=en0 –a netboot_kernel=mp –a cable_type=tp –a client_reg=no
When machine added to NIM environment, the /etc/niminfo file is created.
To rebuild the NIM master /etc/niminfo file, use the nimconfig –r command
To rebuild and recover NIM client /etc/niminfo file use the niminit command. Ex: niminit –a master= -a name=
Create file systems for nim The lpp_source and SPOT resources are directories and the related filesystems must be created.
Define basic resources(lpp_source, SPOT) smitty nim_mkres
Define the client (smitty nim_mkmac)
Start the client installation(smitty nim_task_inst)
Verify the /etc/bootptab
Verify the boot files created or not in the /bootptab

NIM Daemons: nimesis, nimd, bootpd, tftpd

NIM Master uses the bootpd and tftpd

The bootpd daemon will also use the /etc/bootptab file when a NIM client is configured to be booted from the NIM master.

The tftpd daemon uses the /etc/tftpaccess.ctl file to determine which directory hierarchy is allowed to share.

/var/adm/ras directory contains the nim master log files.

/usr/ad/ras/nimlog file contains information about failed NIM operations.

Alog command to view the nim logs: alog –f /usr/adm/ras/nimlog -o

Estimation of minimum disk requirements: lpp_source 6GB, SPOT 2GB, mksysb 40GB

File System Hierarchy:

/tftpboot: This is used for NIM master boot images(Kernels) and info files for the NIM clients.

/export/lpp_source: Used for storing versions of AIX base level filesets in specific directories

/export/spot: Used for storing non /usr

/export/images: This is used for storing system backup images. Images can be created by NIM mksysb.

/export/mksysb: This directory for the mksysb image files to install on clients-approx 1.5GB per image.

/export/res: for bosinst_data, image_data and scripts.

/export/53 contains lppsource_53TL6 and spot_53TL6

NIM server size depends upon how many versions of AIX filesets, TLs, PTFs, Service Packs

Filesets for NIM Master.: bos.net.tcp.server, bos.net.nfs.server, bos.sysmgt.nim.master, bos.sysmgt.nim.spot.

Master config: smitty nim configure NIM environment advanced configuration Initialize nim master only. ( give details like network name and interface)

Making the lppsource:

Copy software from CD or DVD into /export/53 file system Smitty bffcreate ( give input device, software package to copy , directory for storing sw package)
Define it as a NIM resource: smitty nim configure the NIM environment Advanced configuration Create basic installation resources create a new LPP_source ( give resource server, LPP_source name, LPP_source directory)

Making the SPOT: smitty NIM configure the NIM environment Advanced configuration Create Basic installation resources Create a New Spot ( give Resource server, input device, SPOT name and SPOT directory.

NIM Configuration:

Define Client Machine: smitty nim perform nim administration tasks manage machines define a machine(NIM machine name, machine type(standalone), hardware platform type(chrp), kernel to use for network boot(mp), cable type(tp)

Display NIM network objects: lsnim –l –c networks

The Basic NIM installation resources:

1) one nim lpp_source and one SPOT

2) for mksysb installation mksysb resource and SPOT

Define lpp_source: nim –o define –t lpp_source –a server=master –a location=/export/lpp_source/lpp5300 –a source=/dev/cd0 lpp5300

Creating a NIM lpp_source from a directory Nim –o define –t lpp_source –a server=master –a location=/export/lpp_source/lpp5300 lpp5300

Removing NIM lpp_source: nim –o remove lpp5300

Check a NIM lpp_source: nim –Fo check lpp5304

Creating a NIM spot: nim –o define –t spot –a server=master –a location=/export/spot –a source=lpp5300 –a installp_flags=-aQg spot5300

Listing Filesets in a SPOT: nim –o lslpp –a filesets=all –a lslpp_flags=La spot6100-01

Nim –o lslpp spot6100-01

Listing fixes in a SPOT: nim –o fix_query spot6100-01

TL of a SPOT: lsnim –l spot6100-01|grep oslevel

Listing Client Filesets: nim –o lslpp –a filesets=all –a lslpp_flags=-La client.

Removing the NIM spot nim –o remove spot5300

Checking the SPOT nim –o check spot5300

Resetting the NIM spot nim –Fo check spot5300

Create a nim client nim –o define –t standalone –a if1=”net_10_1_1 lpar55 0 ent0” LPAR55

Define NIM machines using smit nim_mkmac

Removing NIM client Definition: nim –o remove LPAR55

Installing NIM Clients:

Base Operating System Installation

System Clone installation

Automated customization after a generic BOS install.

BOS install through NIM:

Nim –o allocate –a spot=spot5304 –a lpp_source=lpp5304 LPAR55
Initiate the install: nim –o bos_inst –a source=spot5304 –a installp_flags=agX –a accept_licenses=yes LPAR55
If the installation is unsuccessful, you need to reallocate the resources
Reset and deallocate NIM resources: Nim –Fo reset LPAR55, Nim –Fo deallocate –a subclass=all LPAR55
View the progress of installation: Nim –o showlog –a log_type=boot LPAR55

Using SMIT to install standalone client: smitty nim_bosinst select a target for the operation select the installation type select the lpp_source select the spot

After Initial program load SMS Menu setup remote IPL interpartition logical LAN Select IP parameters(Client IP, Server IP, Gateway, Subnetmask) Ping Test Execute Ping Test Select Boot Option Select install/Boot Device(Network) Select normal boot mode

Steps to migrate the NIM master to AIX 5L V5.3

Unmount all NFS mounts
Document the AIX and NIM master configuration(snap –ac, lsnim)
Perform NIM database backup smitty nim_backup_db Backup the NIM database
Perform a mksysb of the NIM Master
insert Aix 5l v5.3 CD volume 1 into the CD drive

Creating mksysb from NIM client:

Nim –o define –t mksysb –a server=master –a source=lpar5 –a mk_image=yes –a location=/export/images/mksysb.lpar5 mksysb_lpar5

Backup the VIO server:

Backupios –file /home/padmin/viobackup/VIO.mksysb –mksysb

Restoring the VIO server:

Defining mksysb resource: smitty nim_mkres(select mksysb) Define Spot resource: smitty nim_mkres(select spot) perform the BOS installation

NIM Commands

nimconfig -a pif_name=en0 -a netname=net1 To initialise the NIM master with network name net1

nimconfig -r To rebuild /etc/niminfo file which contains the variables for NIM

nim -o define -t lpp_source -a source=/dev/cd0 -a server=master –a location=/export/lpp_source/lpp_source1 lpp_source1 To define lpp_source1 image in /export/lpp_source/lpp_source directory from source cd0

nim -o define -t mksysb -a server=master -a location=/resources/mksysb.image mksysb1 To define mksysb resource mksysb1, from source /resources/mksysb.image on master

nim -o remove inst_resource To remove the resource

nim –o showres lpp_source6100 Listing contents of the lpp_source.

Nim –o showres –a instfix_flags=T lppsource_61_01

nim -o check lpp_source1 To check the status of lpp_source lpp_source1

nim -o allocate -a spot=spot1 -a lpp_source=lpp_source1 node1 To allocate the resources spot1 and lpp_source1 to the client node1

nim -o bos_inst node1 To initialise NIM for the BOS installation on node1 with the allocated resources

nim -o dkls_init dcmds To initialize the machine dcmds as diskless operation

nim -o dtls_init dcmds To initialize the machine dcmds for dataless operation

nim -o cust dcmds To initialize the machine dcmds for customize operation

nim -o diag dcmds To initialize the machine dcmds for diag operation

nim -o maint dcmds To initialize the machine dcmds for maintenance operation

nim -o define -t standalone -a platform=rspc -a if1=”net1 dcmds xxxxx” -a cable_type1=bnc dcmds To define the machine dcmds as standalone with platform as rspc and network as net1 with cable

type bnc and mac address xxxxx

nim -o unconfig master To unconfigure nim master master

nim -o allocate -a spot=spot1 dcmds To allocate the resource spot1 from machine dcmds

nim -o deallocate -a spot=spot1 dcmds To de allocate the resource spot1 from machine dcmds

nim -o remove dcmds To remove machine dcmds after removing all resources associated to it

nim -o reboot dcmds To reboot ther client dcmds

nim -o define -t lpp_source -a location=/software/lpp1 -a server=master -a source=/dev/cd0 lpp1 To define lppsource lpp1 on master at /software/lpp1 directory from source device /dev/cd0

lsnim To list the nim resources

lsnim -l dcmds To list the detailed info about the object dcmds

lsnim -O dcmds To list the operation dcmds object can support

lsnim -c resources dcmds To list the resources allocated to the machine dcmds

nimclient The client version of nim command (User can obtain same results of nim in server )

NIM Master Configuration:

Nim Installation:

File sets required for NIM installation:

bos.sysmgt.nim.master
bos.sysmgt.nim.client
bos.sysmgt.nim.spot

Put volume 1 of your media installp –acgXd /dev/cd0 bos.sysmgt.nim OR use smit install_all

Initial Setup: smit nim_config_env

Initializing the NIM master: nimconfig –a pif_name=en0 –a master_port=1058 –a netname=master_net –a cable_type=bnc

Or smitty nimconfig.

Lsnim –l master you will see information about NIM master

Lsnim –l |more The boot resource created a /tftpboot directory to hold all of your boot images. All NIM clients that are on the same subnet as this master will be assigned to master_net network.

Set up first lpp_source resource: Create file system called /export/nim/lpp_source.

Nim –o define –t lpp_source –a location=/export/nim/lpp_source/53_05 –a server=master –a comments=’5300-05 lpp_source’ –a multi_volume=yes –a source=/dev/cd0 –a packages=all 5305_lpp

Smit nim_mkres select lpp_source

If you wish to add other volumes you can use

A) bffcreate the volumes into the lpp_source

B) Use NIM to add the volumes smitty nim_res_op select lpp_source select update give target lpp_source and source

Lsnim –l 5305_lpp

Rstate: If this is not set to ‘ready for use’ then you cannot use this resource. Running a check on the lpp_source will allow you to clear this up. Nim –o check

Set up first SPOT resource: create file system called /export/nim/spot.

Nim –o define –t spot –a server=master –a source=5305_lpp –a location=/export/nim/spot –a auto_expand=yes –a comments=’5300-05 spot’ 5305_spot

Smitty nim_mkres select SPOT.

Lsnim –l 5305_spot

Unconfiguring NIM master: nim –o unconfigure master.

Installing software on a client: smitty nim (or smit nim_inst_latest) Perform NIM software installation and Maintenance tasks Install and update software Install Software select the client and the lpp_source.

Updating client software to a latest level: smitty nim(or nim_update_all) perform nim software installation and maintenance tasks install and update software update installed software to latest level select the client then select the lpp_source.

Alternate Disk Install for new TLs: smitty nim(or nim_alt_clone) Perform NIM software installation and Maintenance tasks Alternate Disk Installation Clone the rootvg to an alternate disk ( select taget machine and disk)

Alternate disk install for a new release: smit nim(or nimadm_migrate) Perform NIM software installation and Maintenance tasks Alternate disk installation NIM alternate disk migration perform nim alternate disk migration( select client, disk name, LPP source and SPOT name)

Performing Installs from the client: smit nim(or nim_client_inst) install and upgrade software.

RTE installation:

Requires lpp_source and spot
Default is to install the BOS.autoi bundle
Define the client on the NIM master
Prepare the NIM master to supply RTE install resources to the client
Initiate the installation from the client

Defining the client: smit nim_mkmac (give hostname) enter give machine type standalone, hardware platform type chrp, communication protocol need by client nimsh, cable type N/A.

Client on a new network: smit nim_mkmac give hostname and enter. Type of network attached to network install interface ent(Ethernet network) enter. Give NIM network network2 and subnetmask 255.255.255.0, default gateway used by machine and master.

Setting up the master to install: smit nim_bosinst select target machine select the installation type (rte) select the lpp_source select the SPOT install the base OS on standalone clients.

Checking the NIM master: lsnim –l client, tail –l /etc/bootptab(bf field in /etc/bootptab specifies the boot file that will

be transferred to the client using TFTP after the client contacts the master using BOOTP) , ls –l /tftpboot(Actually a symbolic link) , showmont –e ( shows exported files)

Typical Install Sequence:

Client initates BOOTP request to NIM server.
NIM server responds with information about the boot file (bootptab file)
Client initates TFTP of boot file from NIM server.
Client runs boot file
Client NFS mounts SPOT and lpp_source
Install Operating system

Accessing SMS: Open HMC select LPAR Activate select profile (default) click on open a terminal window Advanced select boot mode SMS ok select remote IPL select the adapter select internet protocol version (IPv4) select network service(BOOTP) Setting IP parameters( select client IP, server IP, gateway, subnet mask) setting the bootlist(select install/boot device select network select network service(BOOTP) select the normal boot mode) setting the boot(are you sure you want to exit SMS(yes).

Monitoring progress on the master: lsnim –l client ( info prompting_for_data_at_console)

Installation: Main BOS installation menu ( select install now with default settings)

To view the bosinst log nim –o showlog –a log_type=bosinst client.

Listing valid operations for an object type: lsnim –Pot master

Listing valid operations for an object: lsnim –O client

Rebuilding the /etc/niminfo file: nimconfig –r

Niminit -a name=client –a master=master

Backing up the NIM database: smitty nim_backup_db (default value is /etc/objrepos/nimdb.backup)

Restore the previously created backup: smitty nim_restore_db

NIM Log files:

/var/adm/ras/nimlog

/var/adm/ras/nim.installp

/var/adm/ras/nimsh.log

/var/adm/ras/bosinstlog

/var/adm/ras/nim.setup

High availability ( Alternate NIM master)

/etc/niminfo: Lists the active NIM master, and a list of valid alternate masters.

Configure alternate NIM master: smit niminit_altmstr

Synchronizing NIM database: smit nim_altmstr ( select synchronize alternate master’s NIM DB)

IBM AIX - HACMP Made Easy - A complete Overview!!

2012-10-03T05:08:00.000+05:30

HACMP : High Availability Cluster Multi-Processing

High Availability : Elimination of both planned and unplanned system and application downtime. This is achieved through elimination of H/W and S/W single points of failure.

Cluster Topology : The Nodes, networks, storage, clients, persistent node ip label/devices

Cluster resources: HACMP can move these components from one node to others Ex: Service labels, File systems and applications
RSCT Version: 2.4.2
SDD Version: 1.3.1.3

HA Configuration :

Define the cluster and nodes
Define the networks and disks
Define the topology
Verify and synchronize
Define the resources and resource groups
Verify and synchronize

After Installation changes : /etc/inittab,/etc/rc.net,/etc/services,/etc/snmpd.conf,/etc/snmpd.peers,/etc/syslog.conf,
/etc/trcfmt,/var/spool/cron/crontabs/root,/etc/host.

Software Components:
Application server
HACMP Layer
RSCT Layer
AIX Layer
LVM Layer
TCP/IP Layer

HACMP Services :
Cluster communication daemon(clcomdES)
Cluster Manager (clstrmgrES)
Cluster information daemon(clinfoES)
Cluster lock manager (cllockd)
Cluster SMUX peer daemon (clsmuxpd)

HACMP Deamons: clstrmgr, clinfo, clmuxpd, cllockd.
HA supports up to 32 nodes
HA supports up to 48 networks
HA supports up to 64 resource groups per cluster
HA supports up to 128 cluster resources

IP Label : The label that is associated with a particular IP address as defined by the DNS (/etc/hosts)

Base IP label : The default IP address. That is set on the interface by aix on startup.

Service IP label: a service is provided and it may be bound on a single/multiple nodes. These addresses that HACMP keep highly available.

IP alias: An IP alias is an IP address that is added to an interface. Rather than replacing its base IP address.
RSCT Monitors the state of the network interfaces and devices.

IPAT via replacement : The service IP label will replace the boot IP address on the interface.

IPAT via aliasing: The service IP label will be added as an alias on the interface.

Persistent IP address: this can be assigned to a network for a particular node.
In HACMP the NFS export : /use/es/sbin/cluster/etc/exports

Shared LVM:

Shared volume group is a volume group that resides entirely on the external disks shared by cluster nodes
Shared LVM can be made available on Non concurrent access mode, Concurrent Access mode, Enhanced concurrent access mode.

NON concurrent access mode: This environment typically uses journaled file systems to manage data.

Create a non concurrent shared volume group: smitty mkvgàGive VG name, No for automatically available after system restart, Yes for Activate VG after it is created, give VG major number.

Create a non concurrent shared file system: smitty crjfsàRename FS names, No to mount automatically system restart, test newly created FS by mounting and unmounting it.

Importing a volume group to a fallover node:

· Varyoff the volume group
· Run discover process
· Import a volume group

Concurrent Acccess Mode: It’s not supported for file systems. Instead must use raw LV’s and Physical disks.
Creating concurrent access volume group:

· Verify the disk status using lsdev –Cc disk
· Smitty cl_convgàCreate a concurrent volume groupàenter
· Import the volume group using importvg –C –y vg_name physical_volume_name
· Varyonvg vgname

Create LV’s on the concurrent VG: smitty cl_conlv.

Enhanced concurrent mode VG’s: This can be used for both concurrent and non concurrent access. This VG is varied on all nodes in the cluster, The access for modifying the data is only granted to the node that has the resource group active.
Active or passive mode:
Active varyon: all high level operations permitted.
Passive varyon: Read only permissions on the VG.
Create an enhanced concurrent mode VG: mkvg –n –s 32 –C –y myvg hdisk11 hdisk12

Resource group behaviour:
Cascading: Fallover using dynamic node priority. Online on first available node
Rotating : Failover to next priority node in the list. Never fallback. Online using distribution policy.
Concurrent : Online on all available nodes . never fallback
RG dependencies:Clrgdependency –t
/etc/hosts : /etc/hosts for name resolution. All cluster node IP interfaces must be added on this file.
/etc/inittab : hacmp:2:once:/usr/es/sbin/cluster/etc/rc.init>/dev/console 2> &1 will strat the clcomdES and clstrmgrES.
/etc/rc.net file is called by cfgmgr. To configure and start TCP/IP during the boot process.
C-SPOC uses clcomdES to execute commands on remote nodes.
C-SPC commands located in /usr/es/sbin/cluster/cspoc
you should not stop a node with the forced option on more than one node at a time and also the RG in concurrent mode.
Cluster commands are in /usr/es/sbin/cluster
User Administration : cl_usergroup
Create a concurrent VG — > smitty cl_convg
To find the resource group information: clrginfo –P

HACMP Planning:
Maximum no.of nodes in a cluster is 32
In an HACMP Cluster, the heartbeat messages are exchanged via IP networks and Point-to-Point networks
IP Label represents the name associated with a specific IP address
Service IP label/address: The service IP address is an IP address used for client access.
2 types of service IP addresses:
Shared Service IP address: It can be active only on one node at a time.
Node bound service IP address: An IP address that can be configured only one node
Method of providing high availability service IP addresses:
IP address takeover via IP aliases
IPAT via IP replacement
IP alias is an IP address that is configured on a communication interface in addition to the base ip address. IP alias is an AIX function that is supported by HACMP. AIX supports multiple IP aliases on each communication interface. Each IP alias can be a different subnet.
Network Interface:
Service Interface: This interface used for providing access to the application running on that node. The service IP address is monitored by HACMP via RSCT heartbeat.
Boot Interface: This is a communication interface. With IPAT via aliasing, during failover the service IP label is aliased onto the boot interface
Persistent node IP label: Its useful for administrative purpose.
When an application is started or moved to another node together with its associated resource group, the service IP address can be configured in two ways.

Replacing the base IP address of a communication interface. The service IP label and boot IP label must be on same subnet.
Configuring one communication interface with an additional IP address on top of the existing one. This method is IP aliasing. All Ip addresses/labels must be on different subnet.

Default method is IP aliasing.
HACMP Security: Implemented directly by clcomdES, Uses HACMP ODM classes and the /usr/es/sbin/cluster/rhosts file to determine partners.
Resource Group Takeover relationship:
Resource Group: It’s a logical entity containing the resources to be made highly available by HACMP.
Resources: Filesystems, NFS, Raw logical volumes, Raw physical disks, Service IP addresses/Labels, Application servers, startup/stop scripts.
To made highly available by the HACMP each resource should be included in a Resource group.
Resource group takeover relationship:

Cascading
Rotating
Concurrent
Custom

Cascading:

Cascading resource group is activated on its home node by default.
Resource group can be activated on low priority node if the highest priority node is not available at cluster startup.
If node failure resource group falls over to the available node with the next priority.
Upon node reintegration into the cluster, a cascading resource group falls back to its home node by default.
Attributes:

1. Inactive takeover(IT): Initial acquisition of a resource group in case the home node is not available.
2. Fallover priority can be configured in default node priority list.
3. cascading without fallback is an attribute that modifies the fall back behavior. If cwof flag is set to true, the resource group will not fall back to any node joining. When the flag is false the resource group falls back to the higher priority node.
Rotating:

At cluster startup first available node in the node priority list will activate the resource group.
If the resource group is on the takeover node. It will never fallback to a higher priority node if one becomes available.
Rotating resource groups require the use of IP address takeover. The nodes in the resource chain must all share the same network connection to the resource group.

Concurrent:

A concurrent RG can be active on multiple nodes at the same time.

Custom:

Users have to explicitly specify the desired startup, fallover and fallback procedures.
This support only IPAT – via aliasing service IP addresses.

Startup Options:

Online on home node only
Online on first available node
Online on all available nodes
Online using distribution policyàThe resource group will only be brought online if the node has no other resource group online. You can find this by lssrc –ls clstrmgrES

Fallover Options:

Fallover to next priority node in list
Fallover using dynamic node priorityàThe fallover node can be selected on the basis of either its available CPU, its available memory or the lowest disk usage. HACMP uses RSCT to gather all this information then the resource group will fallover to the node that best meets.
Bring offlineàThe resource group will be brought offline in the event of an error occur. This option is designed for resource groups that are online on all available nodes.

Fallback Options:

Fallback to higher priority node in the list
Never fallback

Basic Steps to implement an HACMP cluster:

Planning
Install and connect the hardware
Configure shared storage
Installing and configuring application software
Install HACMP software and reboot each node
Define the cluster topology
Synchronize the cluster topology
Configure cluster resources
Configure cluster resource group and shared storage
Synchronize the cluster
Test the cluster

HACMP installation and configuration:
HACMP release notes : /usr/es/lpp/cluster/doc
Smitty install_all à fast path for installation
Cluster.es and cluster.cspoc images must be installed on all servers
Start the cluster communication daemon à startsrc –s clcomdES
Upgrading the cluster options: node by node migration and snapshot conversion
Steps for migration:

Stop cluster services on all nodes
Upgrade the HACMP software on each node
Start cluster services on one node at a time

Convert from supported version of HAS to hacmp

Current s/w should be commited
Save snapshot
Remove the old version
Install HA 5.1 and verify

Check previous version of cluster: lslpp –h “cluster”
To save your HACMP configuration, create a snapshot in HACMP
Remove old version of HACMP: smitty install_remove ( select software name cluster*)
Lppchk –v and lppchk –c cluster* both commands run clean if the installation is ok.
After you have installed HA on cluster nodes you need to convert and apply the snapshot. converting the snapshot must be performed before rebooting the cluster nodes
Clconvert_snapshot –C –v version –s à It converts HA old version snapshot to new version
After installation rebooting the cluster services is required because to activate the new cluster manager.
Verification and synchronization : smitty hacmpàextended configurationà extended verification and configuration à verify changes only
Perform Node-by-Node Migration:

Save the current configuration in snapshot.
Stop cluster services on one node using graceful with takeover
Verify the cluster services
Install hacmp latest version.
Check the installed software using lppchk
Reboot the node.
Restart the HACMP software ( smitty hacmpàSystem ManagementàManage cluster servicesàstart cluster services
Repeat above steps on all nodes
Logs documenting on /tmp/hacmp.out /tmp/cm.log /tmp/clstrmgr.debug
Config_too_long message appears when the cluster manager detects that an event has been processing for more than the specified time. To change the time interval ( smitty hacmpà extended configurationàextended event configurationàchange/show time until warning)

Cluster snapshots are saved in the /usr/es/sbin/cluster/snapshots.
Synchronization process will fail when migration is incomplete. To back out from the change you must restore the active ODM. (smitty hacmp à Problem determination toolsà Restore HACMP configuration database from active configuration.)
Upgrading HACMP new version involves converting the ODM from previous release to the current release. That is done by /usr/es/sbin/cluster/conversion/cl_convert –F –v 5.1
The log file for the conversion is /tmp/clconvert.log.
Clean up process once installation interrupted.( smitty installà software maintenance and installationà clean up after a interrupted installation)
Network Configuration:
Physical Networks: TCP/IP based, such as Ethernet and token ring Device based, RS 232 target mode SSA(tmssa)
Configuring cluster Topology:
Standard and Extended configuration
Smitty hacmpàInitialization and standard configuration
IP aliasing is used as the default mechanism for service IP label/address assignment to a network interface.

Configure nodes : Smitty hacmpàInitialization and standard configurationàconfigure nodes to an hacmp clusterà (Give cluster name and node names)
Configure resources: Use configure resources to make highly available ( configure IP address/label, Application server, Volume groups, Logical volumes, File systems
Configure resource groups: Use configure HACMP resource groups . you can choose cascading, rotating, custom, concurrent
Assign resources to each resource group: configure HACMP resource groupsà Change/show resources for a Resource group.
Verify and synchronize the cluster configuration
Display the cluster configuration

Steps for cluster configuration using extended path:

Run discovery: Running discovery retrieves current AIX configuration information from all cluster nodes.
Configuring an HA cluster: smitty hacmpàextended configurationàextended topology configurationàconfigure an HACMP clusteràAdd/change/show an HA cluster
Defining a node: smitty hacmpàextended configurationàextended topology configurationàconfigure HACMP nodesàAdd a node to the HACMP cluster
Defining sites: This is optional.
Defining network: Run discover before network configuration.

IP based networks: smitty hacmpàextended configurationàextended topology configurationàconfigure HACMP networksàAdd a network to the HACMP clusteràselect the type of networkà(enter network name, type, netmask, enable IP takeover via IP aliases(default is true), IP address offset for heartbeating over IP aliases.

Defining communication interfaces: smitty hacmpàextended configurationàextended topology configurationàHACMP cotmmunication interfaces/DevicesàSelect communication interfacesàadd node name, network name, network interface, IPlabel/address, network type
Defining communication devices: smitty hacmpàextended configurationàextended topology configurationàconfigure HACMP communication interface/devicesàselect communication devices
To see boot IP labels on a node use netstat –in
Defining persistent IP labels: It always stays on the same node, does not require installing an additional physical interface, its not part of any resource group.smitty hacmpàextended topology configurationàconfigure persistent node IP label/addressesàadd persistent node IP label(enter node name, network name, node IP label/address)

Resource Group Configuration

Smitty hacmpàinitialization and standard configurationàConfigure HACMP resource groupsà Add a standard resource groupà Select cascading/Rotating/Concurrent/Custom (enter resource group name, participating node names)
Assigning resources to the RG. Smitty hacmpàinitialization and standard configurationà Configure HACMP resource groupsàchange/show resources for a standard resource group( add service IP label/address, VG, FS, Application servers.

Resource group and application management:

Bring a resource group offline: smitty cl_adminàselect hacmp resource group and application managementàBring a resource group offline.
Bring a resource group online: smitty hacmp àselect hacmp resource group and application managementàBring a resource group online.
Move a resource group: smitty hacmp à select hacmp resource group and application managementà Move a resource group to another node

C-SPOC: Under smitty cl_admin

Manage HACMP services
HACMP Communication interface management
HACMP resource group and application manipulation
HACMP log viewing and management
HACMP file collection management
HACMP security and users management
HACMP LVM
HACMP concurrent LVM
HACMP physical volume management

Post Implementation and administration:
C-Spoc commands are located in the /usr/es/sbin/cluster/cspoc directory.
HACMP for AIX ODM object classes are stored in /etc/es/objrepos.
User group administration in hacmp is smitty cl_usergroup
Problem Determination:
To verify the cluster configuration use smitty clverify.dialog
Log file to store output: /var/hacmp/clverify/clverify.log
HACMP Log Files:
/usr/es/adm/cluster.log: Generated by HACMP scripts and daemons.
/tmp/hacmp.out: This log file contains line – by – line record of every command executed by scripts.
/usr/es/sbin/cluster/history/cluster.mmddyyyy: System creates cluster history file everyday.
/tmp/clstrmgr.debug: This messages generated by clstrmgrES activity.
/tmp/cspoc.log: generated by hacmp c-spoc commands
/tmp/dms_loads.out: stores log messages every time hacmp triggers the deadman switch
/var/hacmp/clverify/clverify.log: cluster verification log.
/var/ha/log/grpsvcs, /var/ha/log/topsvcs, /var/ha/log/grpglsm: daemon logs.
Snapshots: The primary information saved in a cluster snapshot is the data stored in the HACMP ODM classes(HACMPcluster, HACMPnode, HACMPnetwork, HACMPdaemons).
The cluster snapshot utility stores the data it saves in two separate files:
ODM data file(.odm), Cluster state information file(.info)
To create a cluster snapshot: smitty hacmpàhacmp extended configurationàhacmp snapshot configurationàadd a cluster snapshot

Cluster Verification and testing:
High and Low water mark values are 33 and 24
The default value for syncd is 60.
Before starting the clu ster clcomd daemon is added to the /etc/inittab and started by init.
Verify the status of the cluster services: lssrc –g cluster ( cluster manager daemon(clstrmgrES), cluster SMUX peer daemon(clsmuxpd) and cluster topology services daemon(topsvcd) should be running.
Status of different cluster subsystems: lssrc –g topsvcs and lssrc –g emsvcs.
In /tmp/hacmp.out file look for the node_up and node_up_complete events.
To check the HACMP cluster status: /usr/sbin/cluster/clstat. To use this command you should have started the clinfo daemon.
To change the snmp version : /usr/sbin/snmpv3_ssw -1.
Stop the cluster services by using smitty clstop : graceful, takeover, forced. In the log file /tmp/hacmp.out search for node_down and node_down_complete.
Graceful: Node will be released, but will not be acquired by other nodes.
Graceful with takeover: Node will be released and acquired by other nodes.
Forced: Cluster services will be stopped but resource group will not be released.
Resource group states: online, offline, aquiring, releasing, error, temporary error, or unknown.
Find the resource group status: /usr/es/sbin/cluster/utilities/clfindres or clRGinfo.
Options: -t : If you want to display the settling time –p: display priority override locations
To review cluster topology: /usr/es/sbin/cluster/utilities/cltopinfo.
Different type of NFS mounts: hard and soft
Hard mount is default choice.
NFS export file: /usr/es/sbin/cluster/etc/exports.
If the adapter configured with a service IP address : verify in /tmp/hacmp.out event swap_adapter has occurred, Service IP address has been moved using the command netstat –in .
You can implement RS232 heartbeat network between any 2 nodes.
To test a serial connection lsdev –Cc tty, baud rate is set to 38400, parity to none, bits per character to 8
Test to see RSCT is functioning or not : lssrc –ls topsvcs
RSCT verification: lssrc –ls topsvcs. To check RSCT group services: lssrc –ls grpsvcs
Monitor heartbeat over all the defines networks: cllsif.log from /var/ha/run/topsvcs.clustername.
Prerequisites:
PowerHA Version 5.5 à AIX v5300-9 àRSCT levet 2.4.10
BOS components: bos.rte.*, bos.adt.*, bos.net.tcp.*,
Bos.clvm.enh ( when using the enhanced concurrent resource manager access)
Cluster.es.nfs fileset comes with the powerHA installation medium installs the NFSv4. From aix BOS bos.net.nfs.server 5.3.7.0 and bos.net.nfs.client 5.3.7.0 is required.
Check all the nodes must have same version of RSCT using lslpp –l rsct
Installing powerHA: release notes: /usr/es/sbin/cluster/release_notes
Enter smitty install_allàselect input deviceàPress f4 for a software listingàenter
Steps for increase the size of a shared lun:

Stop the cluster on all nodes
Run cfgmgr
Varyonvg vgname
Lsattr –El hdisk#
Chvg –g vgname
Lsvg vgname
Varyoffvg vgname
On subsequent cluster nodes that share the vg. (run cfgmgr, lsattr –El hdisk#, importvg –L vgname hdisk#)
Synchronize

PowerHA creates a backup copy of the modified files during synchronization on all nodes. These backups are stored in /var/hacmp/filebackup directory.
The file collection logs are stored in /var/hacmp/log/clutils.log file.

User and group Administration:
Adding a user: smitty cl_usergroupàselect users in a HACMP clusteràAdd a user to the cluster.(list users, change/show characteristics of a user in cluster, Removing a user from the cluster
Adding a group: smitty cl_usergroupàselect groups in a HACMP clusteràAdd a group to the cluster.(list groups, change/show characteristics of a group in cluster, Removing a group from the cluster

Command is used to change password on all cluster nodes: /usr/es/sbin/cluster/utilities/clpasswd

Smitty cl_usergroupàusers in a HACMP cluster

Add a user to the cluster
List users in the cluster
Change/show characteristics of a user in the cluster
Remove a user from the cluster

Smitty cl_usergroupàGroups in a HACMP cluster

Add a group to the cluster
List groups to the cluster
Change a group in the cluster
Remove a group

Smitty cl_usergroupàPasswords in an HACMP cluster
Importing VG automatically: smitty hacmpàExtended configurationàHACMP extended resource configurationàChange/show resources and attributes for a resource group Automatically import volume groups to true.

C-SPOC LVM: smitty cl_admin à HACMP Logical Volume Management

Shared Volume groups
Shared Logical volumes
Shared File systems
Synchronize shared LVM mirrors (Synchronize by VG/Synchronize by LV)
Synchronize a shared VG definition

C-SPOC concurrent LVM: smitty cl_admin à HACMP concurrent LVM

Concurrent volume groups
Concurrent Logical volumes
Synchronize concurrent LVM mirrors

C-SPOC Physical volume management: smitty cl_adminàHACMP physical volume management

Add a disk to the cluster
Remove a disk from the cluster
Cluster disk replacement
Cluster datapath device management

Cluster Verification: smitty hacmpàExtended verificationàExtended verification and synchronization. Verification log files stored in /var/hacmp/clverify.
/var/hacmp/clverify/clverify.log à Verification log
/var/hacmp/clverify/pass/nodename à If verification succeeds
/var/hacmp/clverify/fail/nodename à If verification fails
Automatic cluster verification: Each time you start cluster services and every 24 hours.
Configure automatic cluster verification: smitty hacmpàproblem determination toolsàhacmp verification à Automatic cluster configuration monitoring.
Cluster status Monitoring: /usr/es/sbin/cluster/clstat –a and o.
/usr/es/sbin/cluster/utilities/cldumpàIt provides snapshot of the key cluster status components.
Clshowsrv: It displays the status

Disk Heartbeat:

It’s a non-IP heartbeat
It’s use dedicated disk/LUN
It’s a point to point network
If more than 2 nodes exist in your cluster, you will need a minimum of n number of non-IP heartbeat networks.
Disk heartbeating will typically requires 4 seeks/second. That is each of two nodes will write to the disk and read from the disk once/second. Filemon tool monitors the seeks.

Configuring disk heartbeat:

Vpaths are configured as member disks of an enhanced concurrent volume group. Smitty lvmàselect volume groupsàAdd a volume groupàGive VG name, PV names, VG major number, Set create VG concurrent capable to enhanced concurrent.
Import the new VG on all nodes using smitty importvg or importvg –V 53 –y c23vg vpath5
Create the diskhb networkàsmitty hacmpàextended configuration àextended topology configurationàconfigure hacmp networksàAdd a network to the HACMP clusteràchoose diskhb
Add 2 communication devicesà smitty hacmpàextended configuration àextended topology configurationàConfigure HACMP communication Interfaces/DevicesàAdd communication interfaces/devicesàAdd pre-defined communication interfaces and devicesà communication devicesàchoose the diskhb
Create one communication device for other node also

Testing Disk Heartbeat connectivity:/usr/sbin/rsct/dhb_read is used to test the validity of a diskhb connection.
Dhb_read –p vpath0 –r for receives data over diskhb network
Dhb_read –p vpath3 –t for transmits data over diskhb network.
Monitoring disk heartbeat: Monitor the activity of the disk heartbeats via lssrc –ls topsvcs. Monitor the Missed HBS field.
Configure HACMP Application Monitoring: smitty cm_cfg_appmonàAdd a process application monitoràgive process names, app startup/stop scripts
Application availability analysis tool: smitty hacmpàsystem managementàResource group and application managementàapplication availability analysis
Commands:
List the cluster topology : /usr/es/sbin/cluster/utilities/cllsif
/usr/es/sbin/cluster/clstat
Start cluster : smitty clstart .. Monitor with /tmp/hacmp.out and check for node_up_complete.
Stop the cluster : smitty cl_stop àMonitor with /tmp/hacmp.out and check fr node_down_complete.
Determine the state of cluster: /usr/es/sbin/cluster/utilities/clcheck_server
Display the status of HACMP subsystems: clshowsrv –v/-a
Display the topology information: cltopinfo –c/-n/-w/-i
Monitor the heartbeat activity: lssrc –ls topsvcs [ check for dropped, errors]
Display resource group attributes: clrginfo –v, -p, -t, -c, -a OR clfindres

IBM AIX - VIO Made Easy - A Complete Overview!!

2012-10-03T05:06:00.001+05:30

PowerVM: It allows to increase the utilization of servers. Power VM includes Logical partitioning, Micro Partitioning, Systems Virtualization, VIO, hypervisor and so on.

Simultaneous Multi Threading : SMT is an IBM microprocessor technology that allows 2 separate H/W instruction streams to run concurrently on the same physical processor.

Virtual Ethernet : VLAN allows secure connection between logical partitions without the need for a physical IO adapter or cabling. The ability to securely share Ethernet bandwidth across multiple partitions increases H/W utilization.

Virtual SCSI: VSCSI provides secure communication between the partitions and VIO server.The combination of VSCSI and VIO capabilities allows you to share storage adapter bandwidth and to subdivide single large disks into smaller segments. The adapters and disks can shared across multiple partitions, increase utilization.

VIO server : Physical resources allows you to share the group of partitions.The VIO server can use both virtualized storage and network adapters, making use of VSCSI and virtual Ethernet.

Redundant VIO server: AIX or linux partitions can be a client of one or more VIO servers at the same time. A good strategy to improve availability for sets of client partitions is to connect them to 2 VIO servers. The reason for redundancy is ability to upgrade latest technologies without affecting production workloads.

Micro Partitioning: Sharing the processing capacity from one or more logical partitions. The benefit of Micro Partitioning is that it allows significantly increased overall utilization . n of processor resources. A micro partition must have 0.1 processing units. Maximum no.of partitions on any system P server is 254.

Uncapped Mode : The processing capacity can exceed the entitled capacity when resources are available in the shared processor pool and the micro partition is eligible to run.

Capped Mode : The processing capacity can never exceed the entitled capacity.

Virtual Processors :A virtual processor is a representation of a physical processor that is presented to the operating system running in a micro partition.

If a micro partition is having 1.60 processing units , and 2 virtual processors. Each virtual processor will have 0.80 processing units.

Dedicated processors : Dedicated processors are whole processors that are assigned to dedicated LPARs . The minimum processor allocation for an LPAR is one.

IVM(Integrated virtualization manager): IVM is a h/w management solution that performs a subset of the HMC features for a single server, avoiding the need of a dedicated HMC server.

Live partition Mobility: Allows you to move running AIX or Linux partitions from one physical Power6 server to another without disturb.

VIO

Version for VIO 1.5

For VIO command line interface is IOSCLI

The environment for VIO is oem_setup_env

The command for configuration through smit is cfgassist

Initial login to the VIO server is padmin

Help for vio commands ex: help errlog

Hardware requirements for creating VIO :

Power 5 or 6
HMC
At least one storage adapter
If you want to share Physical disk then one big Physical disk
Ethernet adapter
At least 512 MB memory

Latest version for vio is 2.1 fixpack 23

Copying the virtual IO server DVD media to a NIM server:

Mount /cdrom

Cd /cdrom

Cp /cdrom/bosinst.data /nim/resources

Execute the smitty installios command

Using smitty installios you can install the VIO S/w.

Topas –cecdisp flag shows the detailed disk statistics

Viostat –extdisk flag shows detailed disk statistics.

Wklmgr and wkldagent for handling workload manager. They can be used to record performance data and that can be viewed by wkldout.

Chtcpip command for changing tcpip parameters

Viosecure command for handling the secure settings

Mksp : to create a storage pool

Chsp: Adds or removes physical volumes from the storage pool

Lssp: lists information about storage pool

Mkbdsp: Attaches storage from storage pool to virtual SCSI adapter

Rmbdsp: removes storage from virtual scsi adapter and return it to storage pool

Default storage pool is rootvg

Creation of VIO server using HMC version 7 :

Select the managed system -> Configuration -> Create Logical Partition -> VIO server

Enter the partition name and ID.

Check the mover service box if the VIO server partition to be created will be supporting partition mobility.

Give a partition profile name ex:default

Processors : You can assign entire processors to your partition for dedicated use, or you can assign partial processors units from the shared processor pool. Select shared.

Specify the minimum, desired and maximum processing units.

Specify minimum, desired and maximum virtual processors. And select the uncapped weight is 191

The system will try to allocate the desired values

The partition will not start if the managed system cannot provide the minimum amount of processing units.

You cannot dynamically increase the amount of processing units to more than the maximum,

Assign the memory also min, desired and max.

The ratio between minimum and maximum amount of memory cannot be more than 1/64

IO selects the physical IO adapters for the partition. Required means the partition will not be able to start unless these are available in this partition. Desired means that the partition can start also without these adapters. A required adapter can not be moved in a dynamic LPAR operation.

VIO server partition requires a fiber channel adapter to attach SAN disks for the client partitions. It also requires an Ethernet adapter for shared Ethernet adapter bridging to external networks.

VIO requires minimum of 30GB of disk space.

Create Virtual Ethernet and SCSI adapters: increase the maximum no of virtual adapters to 100

The maximum no of adapters must not set more than 1024.

In actions -> select create -> Ethernet adapter give Adapter ID and VLAN id.

Select Access External Network Check Box to use this adapter as a gateway between internal and external network.

And also create SCSI adapter also.

VIO server S/W installation :

Place the CD/DVD in P5 Box
Activate the VIO server by clicking the activate. Select the default partition
Then check the Open terminal window or console section and click the advanced. And OK.
Under the boot mode drop down list select SMS.

After installation is complete login with padmin and press a(for s/w maintenance agreement terms)

License –accept for accepting the license.

Creating a shared Ethernet adapter

lsdev –virtual ( check the virtual Ethernet adapter)
lsdev –type adapter ( Check the physical Ethernet adapter)
you use the lsmap –all –net command to check the slot numbers of the virtual Ethernet adapter.
mkvdev –sea ent0 –vadapter ent2 –default ent2 –defaultid 1
lsmap –all –net
use the cfgassist or mktcpip command configure the tcp/ip or
mktcpip –hostname vio_server1 –inetaddr 9.3.5.196 –interface ent3 –netmask 255.255.244.0 –gateway 9.3.4.1

Defining virtual disks

Virtual disks can either be whole physical disks, logical volumes or files. The physical disks can be local or SAN disks.

Create the virtual disks

login to the padmin and run cfgdev command to rebuild the list of visible devices.
lsdev –virtual (make sure virtual scsi server adapters available ex:vhost0)
lsmap –all --> to check the slot numbers and vhost adapter numbers.
mkvg –f –vg rootvg_clients hdisk2 --> Creating rootvg_clients vg.
mklv –lv dbsrv_rvg rootvg_clients 10G

Creating virtual device mappings:

lsdev –vpd |grep vhost
mkvdev –vdev dbsrv_rvg -vadapter vhost2 –dev dbsrv_rvg
lsdev –virtual
lsmap –all

fget_config –Av command provided on the IBM DS4000 series for a listing of LUN names.

Virtual SCSI Optical devices:

A dvd or cd device can be virtualized and assigned to client partitions. Only one VIO client can access the device at a time.

Steps :

let the DVD drive assign to VIO server
Create a server SCSI adapter using the HMC.
Run the cfgdev command to get the new vhost adapter. Check using lsdev –virtual
Create the virtual device for the DVD drive.(mkvdev –vdev cd0 –vadapter vhost3 –dev vcd)
Create a client scsi adapter in each lpar using the HMC.
Run the cfgmgr

Moving the drive :

Find the vscsi adapter using lscfg |grep Cn(n is the slot number)
rmdev –Rl vscsin
run the cfgmgr in target LPAR

Through dsh command find which lpar is currently holding the drive.

Unconfiguring the dvd drive :

rmdev –dev vcd –ucfg
lsdev –slots
rmdev –dev pci5 –recursive –ucfg
cfgdev
lsdev –virtual

Mirroring the VIO rootvg:

chvg –factor 6 rootvg (rootvg can include upto 5 PVs with 6096 PPs)
extendvg –f rootvg hdisk2
lspv
mirrorios –f hdisk2
lsvg –lv rootvg
bootlist –mode –normal –ls

Creating Partitions :

Create new partition using HMC with AIX/linux
give partition ID and Partition name
Give proper memory settings(min/max/desired)
Skip the physical IO
give proper processing units (min/desired/max)
Create virtual ethernet adapter ( give adapter ID and VLAN id)
Create virtual SCSI adapter
In optional settings

· Enable connection monitoring
· Automatically start with managed system
· Enable redundant error path reporting

bootmodes select normal

Advanced Virtualization:

Providing continuous availability of VIO servers : use multiple VIO servers for providing highly available virtual scsi and shared Ethernet services.

IVM supports a single VIO server.

Virtual scsi redundancy can be achieved by using MPIO and LVM mirroring at client partition and VIO server level.

Continuous availability for VIO

Shared Ethernet adapter failover
Network interface backup in the client
MPIO in the client with SAN
LVM Mirroring

Virtual Scsi Redundancy:

Virtual scsi redundancy can be achieved using MPIO and LVM mirroring.

Client is using MPIO to access a SAN disk, and LVM mirroring to access 2 scsi disks.

MPIO: MPIO for highly available virtual scsi configuration. The disks on the storage are assigned to both virtual IO servers. The MPIO for virtual scsi devices only supports failover mode.

Configuring MPIO:

Create 2 virtual IO server partitions
Install both VIO servers
Change fc_err_recov( to fast_fail and dyntrk(AIX tolerate cabling changes) to yes. ( chdev –dev fscsi0 –attr fc_err_recov=fast_fail dyntrk=yes –perm
Reboot the VIO servers
Create the client partitions. Add virtual Ethernet adapters
Use the fget_config(fget_config –vA) command to get the LUN to hdisk mappings.
Use the lsdev –dev hdisk –vpd command to retrieve the information.
The reserve_policy for each disk must be set to no_reserve.(chdev –dev hdisk2 –attr reserve_policy=no_reserve)
Map the hdisks to vhost adapters.( mkvdev –vdev hdisk2 –vadapter vhost0 –dev app_server)
Install the client partitions.
Configure the client partitions
Testing MPIO

Configure the client partitions:

Check the MPIO configuration (lspv, lsdev –Cc disk)
Run lspath
Enable the health check mode (chdev –l hdisk0 –a hcheck_interval=50 –P
Enable the vscsi client adapter path timeout ( chdev –l vscsi0 –a vscsi_path_to=30 –P)
Changing the priority of a path( chpath –l hdisk0 –p vscsi0 –a priority=2)

Testing MPIO:

Lspath
Shutdown VIO2
Lspath
Start the vio2
Lspath

LVM Mirroring: This is for setting up highly available virtual scsi configuration. The client partitions are configured with 2 virtual scsi adapters. Each of these virtual scsi adapters is connected to a different VIO server and provides one disk to the client partition.

Configuring LVM Mirroring:

Create 2 virtual IO partitions, select one Ethernet adapter and one storage adapter
Install both VIO servers
Configure the virtual scsi adapters on both servers
Create client partitions. Each client partition needs to be configured with 2 virtual scsi adapters.
Add one or two virtual Ethernet adapters
Create the volume group and logical volumes on VIO1 and VIO2
A logical volume from the rootvg_clients VG should be mapped to each of the 4 vhost devices.( mkvdev –vdev nimsrv_rvg –vadapter vhost0 –dev vnimsrv_rvg)
Lsmap –all
When you bring up the client partitions you should have hdisk0 and hdisk1. Mirror the rootvg.
Lspv
Lsdev –Cc disk
Extendvg rootvg hdisk1
Mirrorvg –m rootvg hdisk1
Test LVM mirroring

Testing LVM mirroring:

Lsvg –l rootvg
Shutdown VIO2
Lspv hdisk1 (check the pvstate, stale partitions)
Reactivate VIO and varyonvg rootvg
Lspv hdisk1
Lsvg –l rootvg

Shared Ethernet adapter: It can be used to connect a physical network to a virtual Ethernet network. Several client partitions to share one physical adapter.

Shared Ethernet Redundancy: This is for temporary failure of communication with external networks. Approaches to achieve continuous availability:

Shared Ethernet adapter failover
Network interface backup

Shared Ethernet adapter failover: It offers Ethernet redundancy. In a SEA failover configuration 2 VIO servers have the bridging functionality of the SEA. They use a control channel to determine which of them is supplying the Ethernet service to the client. The client partition gets one virtual Ethernet adapter bridged by 2 VIO servers.

Requirements for configuring SEA failover:

One SEA on one VIOs acts as the primary adapter and the second SEA on the second VIOs acts as a backup adapter.
Each SEA must have at least one virtual Ethernet adapter with the “access external network flag(trunk flag) checked. This enables the SEA to provide bridging functionality between the 2 VIO servers.
This adapter on both the SEA’s has the same pvid
Priority value defines which of the 2 SEA’s will be the primary and which is the secondary. An adapter with priority 1 will have the highest priority.

Procedure for configuring SEA failover:

Configure a virtual Ethernet adapter via DLPAR. (ent2)

Select the VIO-->Click task button-->choose DLPAR-->virtual adapters
Click actions-->Create-->Ethernet adapter
Enter Slot number for the virtual Ethernet adapter into adapter ID
Enter the Port virtual Lan ID(PVID). The PVID allows the virtual Ethernet adapter to communicate with other virtual Ethernet adapters that have the same PVID.
Select IEEE 802.1
Check the box “access external network”
Give the virtual adapter a low trunk priority
Click OK.

Create another virtual adapter to be used as a control channel on VIOS1.( give another VLAN ID, do not check the box “access external network” (ent3)
Create SEA on VIO1 with failover attribute. ( mkvdev –sea ent0 –vadapter ent2 –default ent2 –defaultid 1 –attr ha_mode=auto ctl_chan=ent3. Ex: ent4
Create VLAN Ethernet adapter on the SEA to communicate to the external VLAN tagged network ( mkvdev –vlan ent4 –tagid 222) Ex:ent5
Assign an IP address to SEA VLAN adapter on VIOS1. using mktcpip
Same steps to VIO2 also. ( give the higher trunk priority:2)

Client LPAR Procedure:

Create client LPAR same as above.

Network interface backup : NIB can be used to provide redundant access to external networks when 2 VIO servers used.

Configuring NIB:

Create 2 VIO server partitions
Install both VIO servers
Configure each VIO server with one virtual Ethernet adapter. Each VIO server needs to be a different VLAN.
Define SEA with the correct VLAN ID
Add virtual Scsi adapters
Create client partitions
Define the ether channel using smitty etherchannel

Configuring multiple shared processor pools:

Configuration --> Shared processor pool management --> Select the pool name

VIOs Security:

Enable basic firewall settings: viosecure –firewall on

view all open ports on firewall configuration: viosecure –firewall view

To view current security settings: viosecure –view nonint

Change system security settings to default: viosecure –level default

List all failed logins : lsfailedlogin

Dump the global command log: lsgcl

Backup:

Create a mksysb file of the system on a nfs mount: backupios –file /mnt/vios.mksysb –mksysb

Create a backup of all structures of VGs and/or storage pools: savevgstruct vdiskvg ( data will be stored to /home/ios/vgbackups)

List all backups made with savevgstruct: restorevgstruct –ls

Backup the system to a NFS mounted file system: backupios –file /mnt

Performance Monitoring:

Retrieve statistics for ent0: entstat –all ent0

Reset the statistics for ent0: entstat –reset ent0

View disk statistics: viostat 2

Show summary for the system in stats: viostat –sys 2

Show disk stats by adapter: viostat –adapter 2

Turn on disk performance counters: chdev –dev sys0 –attr iostat=true

Topas –cecdisp

Link aggregation on the VIO server:

Link aggregation means you can give one IP address to two network cards and connect to two different switches for redundancy purpose. One network card will be active on one time.

Devices --> communication --> Etherchannel/IEEE 802.3 ad Link Aggregation --> Add an etherchannel / Link aggregation

Select ent0 and mode 8023ad

Select backup adapter as redundancy ex: ent1

Automatically virtual adapter will be created named ent2.

Then put IP address : smitty tcpip --> Minimum configuration and startup --> select ent2 --> Put IP address

Linux LVM - Creating LV and mounting it

2012-09-15T19:38:00.001+05:30

We had created a VG already here, we are going to use that VG to create some LVs or filesystems on it.

At first going to look for the VG size and free space available, vgdisplay and vgs commands will do that for us,

Here we find that only one VG is available on the server. If there are many VGs and if you want the details of the particular VG, you can use vgs or vgdisplay .

Currently i do not have any LVs available on the server apart from the root / filesystem.

We also have other useful commands to verify PV, VG and LV (pvscan ; vgscan ; lvscan), just for additional information.

Ooops ok.. thanks for your patience, lets start creating LVs.

There are several methods of creating a LV, which will be discussed later. The most commonly used default method of creating LV as below,

Syntax:

lvcreate -L  -n  

Example:

lvcreate -L 100M -n newLV1 newVG

So, now the LV is created successfully.

To verify,

So now we had created an LV successfully and verified.

Now the next step is to format the filesystem before mounting it to a mount point.

The device can formated in many different types, latest redhat/centOS versions has ext4.

Command used is mkfs.ext4.

The version which i use, do not have ext4 type format. So we are going to format it with ext3.

To format the LV, we need to know the complete path of the LV device created. Which can be seen in lvdisplay and lvscan outputs from the previous and below screen shots in this post.

Note the "newLV1" linked to "/dev/mapper/newVG-newLV1" which will be the one will be used as the device path for the mount point, even if you use /dev/newVG/newLV1. This can be identified in "mount -l" output after mounting it to a mount point.

Current "mount -l' output

Also the formatted filesystem type will also be verified with the "mount -l" command only after mounting it to a mount point.

Lets start formatting the LV device and mount it to a mount point.

Syntax:

mkfs.ext3 

Example:

mkfs.ext3 /dev/newVG/newLV1

Create a mount point, make a directory which is going to be a mountpoint for this LV. Which can be any path and located any where in the server.

I am going to create it in / directory itself. Which is /newFS.

mkdir /newFS

Mounting it to the created directory, which is called as the mount point.

mount /dev/newVG/newLV1 /newFS

Verify with df -h before and after mounting the filesystem, also with "mount -l".

After Mounting, from "mount -l" outptut.

/dev/mapper/newVG-newLV1 on /newFS type ext3 (rw)

So now successfully mounted the created filesystem. One last and final step is to we need to add this mount point and filesystem details in /etc/fstab for automount while booting.

Verifying for the current /etc/fstab entry.

Edit the /etc/fstab file and add the new mountpoint as below.

That ends the entire LVM.

Quick Recap of complete LVM

1. Adding an additional disk in VMware for Linux VM

2. Scan and Detect a new disk added from VMware to a Linux VM

3. Format a new disk for Linux LVM

4. Linux LVM - Creating PVs

5. Linux LVM - Creating VG

6. Linux LVM - Creating LV and mounting it

Linux LVM - Creating VG

2012-09-14T21:38:00.000+05:30

For creating a VG we need free PVs, i am going to use the PVs created from my previous post,

Below are the PVs going to be used for the new VG, make a note of the attributes on the below output,

1. Command to create VG with above PVs /dev/sdc1 and /dev/sdc2,

vgcreate  

Example: vgcreate newVG /dev/sdc1

Here i want 2 devices to be added to the VG,

vgcreate newVG /dev/sdc1 /dev/sdc2

2. Verify the created VG,

with pvs and pvdisplay command,

with vgs and vgdisplay,

Linux LVM - Creating PVs

2012-09-14T15:35:00.003+05:30

Linux LVM - Creating PVs

How to create Physical volume (PV)?

Before creating a PV verify if it is formatted with appropriate partition's system id, click here for the previous post how to format with Linux LVM partion id?

We are going to create a PV which is based on the disk formatted on my previous post.

Created 2 partitions on /dev/sdc. To display it use fdisk -l /dev/sdc

1. Execute pvdisplay or pvs commands to check and make a note of the previously created physical volumes,

I had no PV created already, so nothing displayed below,

2. So here is the simple command to create the PVs, each partitions mentioned below are 500MB.

pvcreate /dev/sdc1
pvcreate /dev/sdc2

3. Verifying the created PVs with pvdisplay and pvs commands,

PVs created successfully,

For creating VG click here.

Format a new disk for Linux LVM

2012-09-14T04:18:00.001+05:30

Format a new disk in Linux LVM

1. Find the new disk from fdisk -l,

2. Format the disk using fdisk command. I am going to format the device /dev/sdc with 2 partitions.

Used the below options,

For first partition /dev/sdc1

a) Command (m for help): n -----> New Partition

b) Command action
e extended
p primary partition (1-4)
p -----> Primary Partition

c) Partition number (1-4): 1
First cylinder (1-130, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-130, default 130): +500M -----> last cylinder we have a option by mentioning the size and create a partition instead of end cylinder number.

d) Command (m for help): t ----> To toggle the system type of the partition, here the filesystem type we need is Linux LVM
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

e) Command (m for help): p

Disk /dev/sdc: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 62 497983+ 8e Linux LVM

For Second Partition,

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p

Partition number (1-4): 2
First cylinder (63-130, default 63):
Using default value 63
Last cylinder or +size or +sizeM or +sizeK (63-130, default 130): +500M

Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): 8e
Changed system type of partition 2 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/sdc: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id System
/dev/sdc1               1          62      497983+ 8e Linux LVM
/dev/sdc2              63         124      498015   8e Linux LVM

Command (m for help): w -----> To write all the modification at the end.
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@tilakhomelinux ~]# partprobe -----> informs the operating system kernel of partition table changes, by requesting that the operating system re-read the partition table.

Next Click here for how to create PV.

Scan and Detect a new disk added from VMware to a Linux VM.

2012-09-14T03:00:00.001+05:30

Scan and Detect a new disk added from VMware to a Linux VM

1. Before scanning a VMware SCSI disk, make a note of an already available disks on the server with "fdisk -l" command and the LUN ids from "cat /proc/scsi/scsi" file.

2. Check how many scsi hostid's present in "ls -l /sys/class/scsi_host". I had only one scsi hostid (host0) present in the server as below,

3. Now lets scan and detect the VMware Scsi disk assigned to this server with the below command,

echo "- - -" > /sys/class/scsi_host/hostx/scan - where x is the hostid from the "ls -l /sys/class/scsi_host" output.

Had executed the below since i had only one hostid "host0".

echo "- - -" > /sys/class/scsi_host/host0/scan

4. For the servers who have more scsi host id's, execute the below forloop script to scan the new disks.

"for a in `ls /sys/class/scsi_host`; do echo $a; echo "- - -" > /sys/class/scsi_host/$a/scan; done"

5. Now verify the new disk on the server with "fdisk -l" command and the LUN ids from "cat /proc/scsi/scsi" file.

6. At next we will format the new disks in Linux LVM and create a FileSystem.

Adding an additional disk in VMware for Linux VM

2012-09-14T01:38:00.000+05:30

Adding an additional disk in VMware for Linux VM

1. Right click on the VM which you need to add a disk and goto settings from your VMware Workstation.

You will get the below window,

2. Make a note of already assigned disk to the VM. And click on Add.

3. Select Hardisk and click on next,

4. Select any one of the option from below, which ever suits the environment. I prefer the first one since it is my home machine.

5. Since my VM is currently active and i wanted to add the disk on the fly, i got below option only with SCSI disk.

6. Mention the required size of the new disk, Allocate all disk space should be enabled if it going to be a production environment, else the disk will grow by the usage till it reaches the required size.

7. Specify the name of the new disk file to be created and on which path or partition where you got the required disk space. And click on Finish.

8. We are done now, verify the disk is added here on the below box and click on OK.

9. Now click here for how to get the disk on the VM or Server.

Linux - Booting Process

2012-09-13T03:10:00.002+05:30

Linux - Booting Process

After Powering On a Linux Machine,

1. BIOS

BIOS stands for Basic Input/Output System
Performs some system integrity checks
Searches, loads, and executes the boot loader program.
It looks for boot loader in floppy, cd-rom, or hard drive. You can press a key (typically F12 of F2, but it depends on your system) during the BIOS startup to change the boot sequence.
Once the boot loader program is detected and loaded into the memory, BIOS gives the control to it.
So, in simple terms BIOS loads and executes the MBR boot loader.

2. MBR

MBR stands for Master Boot Record.
It is located in the 1st sector of the bootable disk. Typically /dev/hda, or /dev/sda
MBR is less than 512 bytes in size. This has three components 1) primary boot loader info in 1st 446 bytes 2) partition table info in next 64 bytes 3) mbr validation check in last 2 bytes.
It contains information about GRUB (or LILO in old systems).
So, in simple terms MBR loads and executes the GRUB boot loader.

3. GRUB

GRUB stands for Grand Unified Bootloader.
If you have multiple kernel images installed on your system, you can choose which one to be executed.
GRUB displays a splash screen, waits for few seconds, if you don’t enter anything, it loads the default kernel image as specified in the grub configuration file.
GRUB has the knowledge of the filesystem (the older Linux loader LILO didn’t understand filesystem).
Grub configuration file is /boot/grub/grub.conf (/etc/grub.conf is a link to this). The following is sample grub.conf of CentOS.

#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-194.el5PAE)
          root (hd0,0)
          kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
          initrd /boot/initrd-2.6.18-194.el5PAE.img

As you notice from the above info, it contains kernel and initrd image.
So, in simple terms GRUB just loads and executes Kernel and initrd images.

4. Kernel

Mounts the root file system as specified in the “root=” in grub.conf
Kernel executes the /sbin/init program
Since init was the 1st program to be executed by Linux Kernel, it has the process id (PID) of 1. Do a ‘ps -ef | grep init’ and check the pid.
initrd stands for Initial RAM Disk.
initrd is used by kernel as temporary root file system until kernel is booted and the real root file system is mounted. It also contains necessary drivers compiled inside, which helps it to access the hard drive partitions, and other hardware.

5. Init

Looks at the /etc/inittab file to decide the Linux run level.
Following are the available run levels
- 0 – halt
- 1 – Single user mode
- 2 – Multiuser, without NFS
- 3 – Full multiuser mode
- 4 – unused
- 5 – X11
- 6 – reboot
Init identifies the default initlevel from /etc/inittab and uses that to load all appropriate program.
Execute ‘grep initdefault /etc/inittab’ on your system to identify the default run level
If you want to get into trouble, you can set the default run level to 0 or 6. Since you know what 0 and 6 means, probably you might not do that.
Typically you would set the default run level to either 3 or 5.

6. Runlevel programs

When the Linux system is booting up, you might see various services getting started. For example, it might say “starting sendmail …. OK”. Those are the runlevel programs, executed from the run level directory as defined by your run level.
Depending on your default init level setting, the system will execute the programs from one of the following directories.
- Run level 0 – /etc/rc.d/rc0.d/
- Run level 1 – /etc/rc.d/rc1.d/
- Run level 2 – /etc/rc.d/rc2.d/
- Run level 3 – /etc/rc.d/rc3.d/
- Run level 4 – /etc/rc.d/rc4.d/
- Run level 5 – /etc/rc.d/rc5.d/
- Run level 6 – /etc/rc.d/rc6.d/
Please note that there are also symbolic links available for these directory under /etc directly. So, /etc/rc0.d is linked to /etc/rc.d/rc0.d.
Under the /etc/rc.d/rc*.d/ directories, you would see programs that start with S and K.
Programs starts with S are used during startup. S for startup.
Programs starts with K are used during shutdown. K for kill.
There are numbers right next to S and K in the program names. Those are the sequence number in which the programs should be started or killed.
For example, S12syslog is to start the syslog deamon, which has the sequence number of 12. S80sendmail is to start the sendmail daemon, which has the sequence number of 80. So, syslog program will be started before sendmail.

Linux - Runlevel and Init process

2012-09-13T01:36:00.002+05:30

Linux - Runlevel and Init process

Different Linux systems can be used in many ways. This is the main idea behind operating different services at different operating levels. For example, the Graphical User Interface can only be run if the system is running the X-server; multiuser operation is only possible if the system is in a multiuser state or mode, such as having networking available. These are the higher states of the system, and sometimes you may want to operate at a lower level, say, in the single user mode or the command line mode.

Such levels are important for different operations, such as for fixing file or disk corruption problems, or for the server to operate in a run level where the X-session is not required. In such cases having services running that depend on higher levels of operation, makes no sense, since they will hamper the operation of the entire system.

Each service is assigned to start whenever its run level is reached. Therefore, when you ensure the startup process is orderly, and you change the mode of the machine, you do not need to bother about which service to manually start or stop.

The main run-levels that a system could use are:

RunLevel	Target	Notes
0	runlevel0.target, poweroff.target	Halt the system
1	runlevel1.target, rescue.target	Single user mode
2, 4	runlevel2.target, runlevel4.target, multi-user.target	User-defined/Site-specific runlevels. By default, identical to 3
3	runlevel3.target,multi-user.target	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5	runlevel5.target, graphical.target	Multi-user, graphical. Usually has all the services of runlevel3 plus a graphical login - X11
6	runlevel6.target, reboot.target	Reboot
Emergency	emergency.target	Emergency shell

The system and service manager for Linux is now “systemd”. It provides a concept of “targets”, as in the table above. Although targets serve a similar purpose as runlevels, they act somewhat differently. Each target has a name instead of a number and serves a specific purpose. Some targets may be implemented after inheriting all the services of another target and adding more services to it.

Backward compatibility exists, so switching targets using familiar telinit RUNLEVEL command still works. On Fedora installs, runlevels 0, 1, 3, 5 and 6 have an exact mapping with specific systemd targets. However, user-defined runlevels such as 2 and 4 are not mapped that way. They are treated similar to runlevel 3, by default.

For using the user-defined levels 2 and 4, new systemd targets have to be defined that makes use of one of the existing runlevels as a base. Services that you want to enable have to be symlinked into that directory.

The most commonly used runlevels in a currently running linux box are 3 and 5. You can change runlevels in many ways.

A runlevel of 5 will take you to GUI enabled login prompt interface and desktop operations. Normally by default installation, this would take your to GNOME or KDE linux environment. A runlevel of 3 would boot your linux box to terminal mode (non-X) linux box and drop you to a terminal login prompt. Runlevels 0 and 6 are runlevels for halting or rebooting your linux respectively.

Although compatible with SysV and LSB init scripts, systemd:

Provides aggressive parallelization capabilities.
Offers on-demand starting of daemons.
Uses socket and D-Bus activation for starting services.
Keeps track of processes using Linux cgroups.
Maintains mount and automount points.
Supports snapshotting and restoring of the system state.
Implements an elaborate transactional dependency-based service control logic.

Systemd starts up and supervises the entire operation of the system. It is based on the notion of units. These are composed of a name, and a type as shown in the table above. There is a matching configuration file with the same name and type. For example, a unit avahi.service will have a configuration file with an identical name, and will be a unit that encapsulates the Avahi daemon. There are seven different types of units, namely, service, socket, device, mount, automount, target, and snapshot.

To introspect and or control the state of the system and service manager under systemd, the main tool or command is “systemctl”. When booting up, systemd activates the default.target. The job of the default.target is to activate the different services and other units by considering their dependencies. The ‘system.unit=’ command line option parses arguments to the kernel to override the unit to be activated. For example,

systemd.unit=rescue.target is a special target unit for setting up the base system and a rescue shell (similar to run level 1);

systemd.unit=emergency.target, is very similar to passing init=/bin/sh but with the option to boot the full system from there;

systemd.unit=multi-user.target for setting up a non-graphical multi-user system;

systemd.unit=graphical.target for setting up a graphical login screen.

Linux - File & Directory Structure

2012-09-13T00:06:00.001+05:30

Linux File and Directory Structure

The file and directory structure is very important, because different unix flavours have to follow standard directory and file structure.

< / >
The root directory. The starting point of your directory structure. This is where the Linux system begins. Every other file and directory on your system is under the root directory. Usually the root directory contains only subdirectories, so it's a bad idea to store single files directly under root.
Don't confuse the root directory with the root user account, root password (which obviously is the root user's password) or root user's home directory.

< /boot >
As the name suggests, this is the place where Linux keeps information that it needs when booting up. For example, this is where the Linux kernel is kept. If you list the contents of /boot, you'll see a file called vmlinuz - that's the kernel.

< /etc >
The configuration files for the Linux system. Most of these files are text files and can be edited by hand. Some interesting stuff in this directory:

/etc/inittab
A text file that describes what processes are started at system bootup and during normal operation. For example, here you can determine if you want the X Window System to start automatically at bootup, and configure what happens when a user presses Ctrl+Alt+Del.

/etc/fstab
This file contains descriptive information about the various file systems and their mount points, like floppies, cdroms, and so on.

/etc/passwd
A file that contains various pieces of information for each user account. This is where the users are defined.

< /bin, /usr/bin >
These two directories contain a lot of programs (binaries, hence the directory's name) for the system. The /bin directory contains the most important programs that the system needs to operate, such as the shells, ls, grep, and other essential things. /usr/bin in turn contains applications for the system's users. However, in some cases it really doesn't make much difference if you put the program in /bin or /usr/bin.

< /sbin, /usr/sbin >
Most system administration programs are stored in these directories. In many cases you must run these programs as the root user.

< /usr >
This directory contains user applications and a variety of other things for them, like their source codes, and pictures, docs, or config files they use. /usr is the largest directory on a Linux system, and some people like to have it on a separate partition. Some interesting stuff in /usr:

/usr/doc
Documentation for the user apps, in many file formats.

/usr/share
Config files and graphics for many user apps.

/usr/src
Source code files for the system's software, including the Linux kernel.

/usr/include
Header files for the C compiler. The header files define structures and constants that are needed for building most standard programs. A subdirectory under /usr/include contains headers for the C++ compiler.

/usr/X11R6
The X Window System and things for it. The subdirectories under /usr/X11R6 may contain some X binaries themselves, as well as documentation, header files, config files, icons, sounds, and other things related to the graphical programs.

< /usr/local >
This is where you install apps and other files for use on the local machine. If your machine is a part of a network, the /usr directory may physically be on another machine and can be shared by many networked Linux workstations. On this kind of a network, the /usr/local directory contains only stuff that is not supposed to be used on many machines and is intended for use at the local machine only.
Most likely your machine isn't a part of a network like this, but it doesn't mean that /usr/local is useless. If you find interesting apps that aren't officially a part of your distro, you should install them in /usr/local. For example, if the app would normally go to /usr/bin but it isn't a part of your distro, you should install it in /usr/local/bin instead. When you keep your own programs away from the programs that are included in your distro, you'll avoid confusion and keep things nice and clean.

< /lib >
The shared libraries for programs that are dynamically linked. The shared libraries are similar to DLL's on Winblows.

< /home >
This is where users keep their personal files. Every user has their own directory under /home, and usually it's the only place where normal users are allowed to write files. You can configure a Linux system so that normal users can't even list the contents of other users' home directories.

< /root >
The superuser's (root's) home directory. Don't confuse this with the root directory (/) of a Linux system.

< /var >
This directory contains variable data that changes constantly when the system is running. Some interesting subdirectories:

/var/log
A directory that contains system log files. They're updated when the system runs, and checking them out can give you valuable info about the health of your system. If something in your system suddenly goes wrong, the log files may contain some info about the situation.

/var/mail
Incoming and outgoing mail is stored in this directory.

/var/spool
This directory holds files that are queued for some process, like printing.

< /tmp >
Programs can write their temporary files here.

< /dev >
The devices that are available to a Linux system. Remember that in Linux, devices are treated like files and you can read and write devices like they were files. For example, /dev/fd0 is your first floppy drive, /dev/cdrom is your CD drive, /dev/hda is the first IDE hard drive, and so on. All the devices that a Linux kernel can understand are located under /dev, and that's why it contains hundreds of entries.

< /mnt >
This directory is used for mount points. The different physical storage devices (like the hard disk drives, floppies, CD-ROM's) must be attached to some directory in the file system tree before they can be accessed. This attaching is called mounting, and the directory where the device is attached is called the mount point.
The /mnt directory contains mount points for different devices, like /mnt/floppy for the floppy drive, /mnt/cdrom for the CD-ROM, and so on. However, you're not forced to use the /mnt directory for this purpose, you can use whatever directory you wish. Actually in some distros, like Debian and SuSE, the default is to use /floppy and /cdrom as mount points instead of directories under /mnt.

< /proc >
This is a special directory. Well, actually /proc is just a virtual directory, because it doesn't exist at all! It contains some info about the kernel itself. There's a bunch of numbered entries that correspond to all processes running on the system, and there are also named entries that permit access to the current configuration of the system. Many of these entries can be viewed.

< /lost+found >
Here Linux keeps the files that it restores after a system crash or when a partition hasn't been unmounted before a system shutdown. This way you can recover files that would otherwise have been lost.

Redhat Linux - Finding the filesystem type of a partition in linux

2012-09-12T14:36:00.000+05:30

Finding the filesystem type of a partition in linux

To find the type of filesystem a partition or a media is of we can use the commands "df" or "mount".

Using df

$ df -T 
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/sda1     ext4    53067292  47601336   2770228  95% /
tmpfs        tmpfs      127140         0    127140   0% /lib/init/rw
udev         tmpfs      121484       220    121264   1% /dev
tmpfs        tmpfs      127140         4    127136   1% /dev/shm

The column with the heading "Type" gives the filesystem type. So the partition /dev/sda1 is of type ext4

To find the filesystem type of a specific partition pass the partition as the argument.

$ df -T /dev/sda1 
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/sda1     ext4    53067292  47601332   2770232  95% /

Using mount

$ mount 
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
none on /proc/fs/vmblock/mountPoint type vmblock (rw)

As listed the partition /dev/sda1 is of type ext4.
We can find the specific partition type by combining mount with grep.

$ mount | grep /dev/sda1
/dev/sda1 on / type ext4 (rw,errors=remount-ro)

Mapping Disk from VIO Server to LPAR

2012-09-07T22:02:00.000+05:30

Mapping Disk from VIO Server to LPAR

mkvdev -vdev -vadapter -dev

mkvdev: command used to create a mapping disk from VIO to Client LPAR

-vdev: Flag used to mention the disk name. eg: -vdev hdiskx , where x is number of the hdisk. This can be physical disk id or lvname which you are going to map. You are always have a alternative option to create a VG and create some LVs to the required size and map them as well as like hdisk.

-vadapter: Flag used to mention the vhostID which is created for the LPAR.

eg: -vadapter vhostx, where x is number of the vhost.

-dev: VTD(Virtual Target Device) Name which is created for the LPAR identification. It is optional, but it will be very useful to identify the vhostid and the hdisk assigned for a LPAR. Mostly the VTD name will be set with LPAR Partition id with Managed system name. On some environments it will be with LPAR name with Managed system.

Examples:

---------

1. VTD name with LPAR Partion ID and Managed System Name,

mkvdev -vdev hdisk10 -vadapter vhost4 -dev tilakmanservr_lparid03

2. VTD name with LPAR name with Managed system,

mkvdev -vdev hdisk10 -vadapter vhost4 -dev tilakmanserver_aixtest

where,

tilakmanservr - Managed System Name

lparid03 - LPAR id of the server. Can be identified from HMC - Managed Server - It will list all LPARs and LPAR ids assigned to it.

aixtest - Which is my LPAR name on the Managed server to which i am mapping the disk.

From lsmap -all, searched for the hdisk10 mapping. It will look simalarly as below.

SVSA           
Physloc                                     
Client Partition ID

---------------
-------------------------------------------- ------------------

vhost4        
U9117.MMB.10215EP-V2-C39                    
0x00000011

VTD                  
tilakmanservr_lparid03

Status               
Available

LUN                  
0x8100000000000000

Backing
device        hdisk10

Physloc              
U78C0.001.DBJ2978-P2-C2-T1-W50060E80054315BE-L4000000000000

$ oem_setup_env

# lsdev -Cc adapter | grep -i vhost

vhost4   
Available         Virtual SCSI Server
Adapter

# lspv | grep -i hdisk10

hdisk10        
00f6100f2429032e                   
None

Now run cfgmgr on the client LPAR to get the disk.

aixtest# lsdev -Cc disk

hdisk1
Available          Virtual SCSI
Disk Drive

aixtest# lspv | grep -i hdisk1

hdisk1         
00f6100f2429032e                   
none          none

The above PVID "00f6100f2429032e" will be the same of the VIO server's hdisk10.

If you don't have vhost and vscsi adapters already present in both the servers, you may need to visit here - how to create it before mapping the disks.

Creating Virtual SCSI Adapter for VIO & LPAR through HMC

2012-09-07T20:50:00.001+05:30

Creating Virtual SCSI Adapter for VIO & LPAR through HMC

For VIO

Creating Virtual SCSI Adapter on VIO Dynamically, which will be removed on the next reboot. To make it static check

the next step (b)

a. Login to HMC - Navigate to VIO server - Select the VIO server - Select Dynamic Logical Partition - Select Virtual

Adapter - Goto Actions - Create Virtual Adapter - SCSI Adapter

Create Virtual SCSI Adapter:
tilakvio1

Virtual SCSI adapter 

Adapter : 6

Type of adapter : Server

[ ] This adapter is required for
partition activation.

( ) Any client partition can connect

(•) Only selected client partition
can connect

Client partition : aixtest(03)

Client adapter ID : 04

Click on OK

To make the Virtual SCSI Adapter for VIO Permanently.

b. Once created make the same entry on

Login to HMC - Navigate to VIO server - Select the VIO server - Select Configuration - Manage Profile - Select the

profile - Goto Actions - Edit - Select Virtual Adapters - Actions - Create Virtual Adapter - SCSI Adapter

Put exactly the same as we created through DLPAR above and click on OK.

Where,

Create Virtual SCSI Adapter: VIO
Server name will be displayed

Adapter : Adapter ID (Leave it as
default if you wish)

[ ] This adapter is required for
partition activation. - Haven't selected this option, since i am not using it
for 

rootvg.

( ) Any client partition can connect
- If this selected you can map it to any LPAR

(•) Only selected client partition
can connect - Selected this option for it should map only to this LPAR and
given 

the details as below,

Client partition : aixtest(03)
--> is my LPAR name and on the bracket it will auto display the LPAR ID,
where i am 

going to map

Client adapter ID : 04 - Leave it as
default.

And notedown LPAR name Adapter ID and Client adapter ID.

Save the profile.

__________________________________________________________________________________

For LPAR

Creating Virtual SCSI Adapter for LPAR Dynamically,

a. Login to HMC - Navigate to LPAR - Select the LPAR(aixtest(03)) - Select Dynamic Logical Partition - Select Virtual

Adapter - Goto Actions - Create Virtual Adapter - SCSI Adapter

Create Virtual SCSI Adapter: aixtest

Virtual SCSI adapter 

Adapter : 04

Type of adapter : Client

Server partition : tilakvio1(1)

Server adapter ID : 6

Click on OK

Note: Here the adapter id and Server adapter ID should be matched as per we created the adapter on VIO.

VIOs Client adapter id should be the adapter ID in LPAR

VIOs Adapter id should be the Server adapter ID in LPAR.

Same should be updated in Managed Profile and Save the profile.

b. Login to HMC - Navigate to LPAR - Select the LPAR(aixtest(03)) - Select Configuration - Manage Profile - Select the

profile - Goto Actions - Edit - Select Virtual Adapters - Actions - Create Virtual Adapter - SCSI Adapter

__________________________________________________________________________________

Run configuration Manager on Both VIO and LPAR to get the Virtual Adapter

Now Run the cfgdev in VIO and cfgmgr on LPAR to get those adapters, And make a note of created vhost name and vscsi

name from Hardware profiles of VIO and LPAR.

On VIO

$ cfgdev

$ oem_setup_env

# lsdev -Cc adapter | grep -i vhost

vhost4 Available Virtual SCSI Server Adapter

On LPAR

aixtest# cfgmgr

aixtest# lsdev -Cc adapter | grep -i
vscsi

vscsi1 Available Virtual SCSI Client Adapter