Saturday, March 16, 2019

How to migrate a aix server from AIX 6.1 to 7.1 easily?

How to migrate a aix server from AIX 6.1 to 7.1 easily?




There are different ways to migrate your system from one AIX version to another AIX version:


Migration by using NIM / CD-DVD / mksysb / alternate disk migration.


Sometimes you will be in a position to migrate a NIM master from AIX 6.1 to AIX 7.1.
It is difficult to migrate a nim server using another nim server as you facing some difficulties. 


Sometimes your server sitting in beyond the firewall (DMZ) area, you could not able to enable rsh/ssh/ping to the server from outside, at that time the above method will help you to migrate it easily.


The below steps are really really easy to perform the aix migration from AIX 6.1 to AIX 7.1 which does not required much requirements to meet.


Take a mksysb of the target server
server1# mksysb -ieX /backup/server1_aix61.mksysb



SCP the mksysb over to your NIM master and define it as a NIM mksysb resource
server1# scp /backup/server1_aix61.mksysb root@nimserver:/backupfs/.



Make sure you got the lpp_source and SPOT from the base AIX ISO images at the level you want to upgrade the system to. If not please create it.

nimserver# lsnim -l aix71_TL05_SP02_spot
nimserver# lsnim -l aix71_TL05_SP02_lppsource



Create the mksysb resource using the mksysb taken on the lpar mksysb

nimserver# nim -o define -t 'mksysb' -a server=master -a location=/backupfs/server1_aix61.mksysb server1_AIX61_mksysb



Use the 'nimadm' command to migrate the existing mksysb to a new + upgraded mksysb image with the following command

nimadm -s <spot> -l <lpp_source> -j <volume group for cache> -Y -T <old_mksysb_resource> -O <new mksysb resource file pathname> -N <new_mksysb_resource>

nimserver# nimadm -s aix71_TL05_SP02_spot -l aix71_TL05_SP02_lppsource -j nimadmvg -Y -T server1_AIX61_mksysb -O /backupfs/server1_7.1_mksysb -N server1_AIX71_mksysb




once that completes you would take the new mksysb file that was created and upgraded and scp it back to the lpar it was taken from

server1# scp /backupfs/server1_7.1_mksysb root@server1:/backup/



Install the "bos.alt_disk_install.rte" and "bos.alt_disk_install.boot_images" fileset to that system at the same TL/SP level as the level you upgraded that mksysb to

server1# mount nimserver:/aix71_TL05_SP02_lppsource  /mnt    -> where we hold the AIX 7.1 package

server1# smitty installp  -> install the "bos.alt_disk_install.rte" and "bos.alt_disk_install.boot_images"
(or)
          server1# installp -acgXYd .  bos.alt_disk_install.rte bos.alt_disk_install.boot_images

server1# alt_disk_mksysb -m -k  /backup/server1_7.1_mksysb -d hdisk2

Note: -k specifies that mksysb devices be kept (formally the ALT_KEEP_MDEV variables) This option is to having the customized network related settings to be cloned with mksysb from the old image to new image. 

If you are not using the "-k" option, there might be the chance to losing your network connectivity after the reboot.
           


Boot up from the upgraded disk

Server1# bootlist -m normal -o hdisk2


For the first reboot, it will take long time to reboot as the server booted from the pugraded OS. Please patience.  Once the server rebooted, please check the OS version and other post checks.

Server1# oslevel -s; lppchk -vm3; instfix -i|egrep -i 'tl|sp'; oslevel -rl7100-05

Server1# oslevel -s
7100.05.02.1134



see your server successfully migrated to AIX 7.1








Tuesday, February 19, 2019

crfs:mkpatch:/etc/locks: Do not specify an existing file in aix?

crfs:mkpatch:/etc/locks: Do not specify an existing file issue in aix?

Investigation:
=========

The issue "crfs:mkpatch:/etc/locks: Do not specify an existing file" is occured while we trying to create a filesystem on the AIX server.

Check the /etc/locks file on the server

tstaix01# ls -l /etc/locks
lrwxrwxrwx     1     root    system 12  13 2008 /etc/hosts -> /var/locks

The /etc/locks file is symbolic linked with /var/locks directory, check the /var/locks directory on the server, if the /var/locks directory is not present, then we need to create it manually.

tstaix01# cd /var
tstaix01# ls -ld locks
ls: 0653-341 The directory locks does not exist
tstaix01# 

Solution:
======

Please create a "locks" directory as it was not present on the /var filesystem, the server will allow you to create a filesystem once you create a locks directory under /var

tstaix01# cd /var
tstaix01# mkdir locks
tstaix01# cd locks
tstaix01# mkdir fs
tstaix01# 

Now create a filesystem 

tstaix01# crfs -v jfs2 -d oraclevol -m /opt/oraclefs
Filesystem created successfully
6144000 kilobytes total disk space
New file system size is 11496770
tstaix01# 

Now try to mount it

tstaix01# mount /opt/oraclefs
tstaix01# 
tstaix01# df -gt /opt/oraclefs
Filesystem     GB blocks    Used     Free     %Used     mounted on
/dev/oraclevol   6.00          0.00       6.00         1%      /opt/oraclefs
tstaix01# 







Thursday, November 1, 2018

How to deal with the concept of micro-partition in aix?

How to deal with the concept of micro-partition in Aix?

 It is really hard to get the exact concept/purpose of micro-partition of Aix in google or from IBM site. However, The below is the "what is what" description for the micro-partition concept in Aix. I am sure when you complete to read this, you will get a good understanding about capacity planning in aix. It will help you if you are prepare for your aix interview. 


Power VM:

     PowerVM is the virtualization solution for AIX on IBM Power technology.


Power Hypervisor:

     As the foundation of PowerVM is the Power hypervisor. It is a firmware layer sitting between the hosted operating systems and the server hardware and the power hypervisor delivers the virtualized functions


Micro partition:

     Micro-Partitioning technology allows allocating fractions of processors to a logical partition. A logical partition using fractions of processors is also known as a Micro-Partition. Micro-Partitions run over a set of processors called a Physical Shared-processor pool or simply Shared-Processor Pool.


Processing mode:

      Assign entire processors for dedicated use or assign processor which can be shared with other micro-partitions.


Dedicating processing mode:

      In dedicated mode, physical processors cores are assigned as a whole to partitions. Thus the processing capacity, in this case, is fixed and can’t go beyond that. For example, if you have assigned 2 processors to a partition in a dedicated processing mode, that’s it. It can’t access beyond two processors if required.


Shared dedicated mode:

      The problem with dedicated processing mode is that processing capacity is fixed and during low workload timings, processing capacity get wasted. In power 6, In this Shared Dedicated Mode, unused cycles are harvested and then donated to the physical shared-processor pool associated with Micro-Partitioning. This ensures the opportunity for maximum processor utilization throughout the system.

The Power hypervisor ensures that only spare CPU cycles are donated, hence enabling this feature can help to increase system utilization, without affecting the critical partitions configured in a dedicated processor mode.

 When the CPU utilization of the core goes below a threshold, and all the SMT threads of the CPU are idle from a hypervisor perspective, the CPU will be donated to the shared processor pool. The donated processor is returned instantaneously (within micro-seconds) to the dedicated processor partition when the timer of one of the SMT threads on the donated CPU expires, which means thread got instructions to execute.


·“Allow when the partition is inactive” - if checked, will allow the processors assigned for the dedicated processor partition to be included in the shared processor pool when the partition is powered off (that’s why inactive).


 · “Allow when partition is active” - if checked, will allow the processors assigned for the dedicated processor partition to be included in the shared processor pool when the partition is active, but not making full use of the processors (Shared dedicated processing mode).



Shared Processing Mode:

      In shared processing mode, partitions get fractions of a physical processor. The processing capacity assigned to a partition is known as its entitled capacity and expressed in processing units (PUs). At minimum, a partition can get 0.1 processing units (in other words 10% of a processor’s capacity) and after that any value with an increment of 0.01.

The guaranteed capacity available to a partition within one dispatch cycle, which is 10ms.

Note: The total entitled capacity of all the partitions configured on the system can never exceed the number of processor in that system.



Processing unit:
Desired processing unit / Min / Max processing unit:

      The desired processing units define the processing capacity you desire for this partition to have and Min/Max processing units decide a valid range in which you can change the processing units for this partition.


Virtual processor:
Desired virtual processor / Min / Max Virtual processor:

      Desired virtual processors is the number of virtual processors you want this partition to have and Min/Max defines a valid range for the dynamic movement.


Capped:  Limited to the entitled capacity
•      Example:  1.5 capped processing units means a partition can use up to 15 ms of execution time during each timeslice, but no more than that


Uncapped: If a partition needs extra CPU cycles (more than its entitled capacity), it can utilize unused capacity in the shared pool
      Example:  An uncapped partition with 1.5 processing units is guaranteed to be able to use 1.5 units, but may use more if necessary (and more is available)


Simultaneous Multithreading (SMT):

       Simultaneous multithreading was first introduced on Power5 offerings, supporting two threads and has been further enhanced in Power7 offerings by allowing four separate threads to run concurrently on the same physical processor core. In the vmstat, with SMT on, the lcpu=2 means you have one core. It’s possible to use mpstat –s to see how the threads are being dispatched.


Virtual Processors

       A virtual processor (VP or VCPU) is a depiction of a physical processor that is presented to the operating system running in a micro-partition. Virtual processors are allocated in whole numbers. Each virtual processor can represent between 0.1 and 1.0 CPUs, known as processing units (PU). So a virtual processor can never consume more than 1.0 physical processor.


In other words, the capacity of a virtual processor will always be equal to or less than the processing capacity of a physical processor. A shared partition can define number of virtual processors up to 10 times the number of processing units assigned to the partition.


Concept of virtual processors:

       virtual processors determine how many cores a partition thinks it has. If 2 virtual processors configured on a partition, it will think it has two physical cores. The number of virtual processors configured for a micro-partition establishes the usable range of processing units. 

For example, a partition with one virtual processor can operate with between 0.1 and 1.0 processing units and with two virtual processors can get between 0.2 and 2.0 processing units. The upper limit of processing capacity, up to which an uncapped micro-partition can grow, is determined by the number of virtual processors that it possesses


For example, if you have a partition with entitled capacity of 0.50 processing units and one virtual processor, the partition cannot exceed 1.00 processing units. However, if the same partition is assigned two virtual processors and processing resources are available in the shared processor pool, the partition can go up to 2.00 processing units (an additional 1.50 processing units) and 4.00 processing units in case of 4 virtual processors


By default, the number of processing units that you specify is rounded up to the minimum whole number of virtual processors needed to satisfy the assigned number of processing units.


 For example:
· If you specify 0.50 processing units, one virtual processor will be assigned.
· If you specify 2.25 processing units, three virtual processors will be assigned.


A micro-partition must have enough virtual processors to satisfy its assigned processing capacity. For example, if a micro-partition has an entitled capacity of 2.5 processing units then the minimum number of virtual processors would be 3


Processing Capacity: Desired, Minimum, and Maximum:


 ·  Minimum, desired, and maximum processing units
 · Minimum, desired, and maximum virtual processors

The desired processing units and desired virtual processor values can be changed dynamically without stopping or reactivating the partition and that’s where minimum and maximum values come into picture.


The minimum and maximum settings for both processing units and virtual processors represent the extremes between which the desired values can be dynamically changed. Maximum value is only used as an upper limit for the dynamic operation and doesn’t play any role in processing capacity allotment for the partition.



Deep understanding about the micro partition:

       A desired value defines a value which you desire or like to have. This is not an ensured processing capacity because there might not be enough capacity in the shared-processor pool. In addition to define a lower boundary for dynamic operations, the minimum value defines a minimum value which must be available in the shared-processor pool for the partition to start, failing which partition will not start.


When a partition is started, preference is given to the desired value you set. When there is enough capacity in the shared-processor pool, the allocated entitled capacity will be equal to the desired value. Otherwise, the entitled capacity will be lower than the desired value, a value greater than or equal to the minimum capacity attribute. If the minimum capacity requirement cannot be met, the micro-partition will not start.
The entitled processor capacity is allocated among the partitions in the sequence the partitions are started. Consider a scenario where a physical shared-processor pool has 2.0 processing units available and there are 3 partitions started in the sequence 


Partitions 1, 2, and 3 with following attributes: -
Partition 1 (Minimum: 0.5, Desired: 1.5, Maximum: 1.8)
Partition 2 (Minimum: 1.0, Desired: 1.5, Maximum: 2.0)
Partition 3 (Minimum: 0.5, Desired: 1.0, Maximum: 1.5)


 Since Partition 1 is started first, it will get the entitled processing capacity of 1.5 because there is enough processing capacity of 2.0 processing units available in the physical-processor pool. Partition2 will not be able to start because after allocating 1.5 processing units to partition 1, only 0.5 processing units are left in the physical processing pool and Partition 2 minimum capacity requirement is greater than that. Partition 3 will get started with entitled capacity of 0.5, which is the capacity left in the physical-processing pool. This value is less than Partition 3’s desired capacity requirement. The allocated capacity entitlements are summarized below:

· Partition 1 will be activated with allocated capacity entitlement of 1.5, which is the desired value. 
· Partition 2 will not start because minimum capacity requirements will not met.
 · Partition 3 will be activated with allocated capacity entitlement of 0.5, which is lesser than the desired value but sufficient enough to start the partition.

note: My sincere thanks to Neeraj.
----------------------------------------------------------------------------------------------------------------------------------


Sunday, September 30, 2018

How to check the oslevel of altinst_rootvg in aix?

How to check the oslevel of altinst_rootvg in aix?


How to check the oslevel of the altaltinst_rootvg in aix?

Sometimes we will be in the situation to identify the oslevel / TL / SP of the altinst_rootvg to proceed further for our activity (next task), Using the below steps we can easily identify the os version of the altinst_rootvg in aix


Test2:/# oslevel -s
7100-01-04-1141
Test2:/# 

Test2:/# lspv
hdisk0        00d342e7131c6b47                  rootvg          active
hdisk1        00d342d637j21a59                  altinst_rootvg
Test2:/# 


Test2:/# alt_rootvg_op -W -d hdisk1
Waking up altinst_rootvg volume group ...

Test2:/# 


Now the altinst_rootvg is in Active state also alt filesystems are in mounted state on the server


Test2:/# lspv
hdisk0        00d342e7131c6b47                  rootvg          active
hdisk1        00d342d637j21a59                  altinst_rootvg  active
Test2:/# 


Test2:/# df
Filesystem    512-blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4          524288    380024   28%     3091     3% /
/dev/hd2         3801088    396856   90%    34020     8% /usr
/dev/hd9var      2621440   2279336   14%     3560     2% /var
/dev/hd3          524288    499272    5%      105     1% /tmp
/dev/hd1          524288    507336    4%      102     1% /home
/proc                  -         -    -         -     -  /proc
/dev/hd10opt      524288    278872   47%     3370     6% /opt
/dev/alt_hd4      524288    365552   31%     3871     3% /alt_inst
/dev/alt_hd1      524288    507336    4%      104     1% /alt_inst/home
/dev/alt_hd10opt 1310720   562888   58%     5694     4% /alt_inst/opt
/dev/alt_hd3     524288    499120    5%      116     1% /alt_inst/tmp
/dev/alt_hd2     5636096   184120   97%   103336    15% /alt_inst/usr
/dev/alt_hd9var  2621440   1835656   30%   6632     3% /alt_inst/var

We need to start the chroot shell within the alternate rootvg to identify the OS level/TL/SP information.

Test2:/# chroot /alt_inst /usr/bin/ksh

Test2:/# oslevel -s
7100-01-01-1216
Test2:/# 
Test2:/# exit

you can return to the rootvg environment by exit from the alt shell.


Now it is really really important to put the cloned rootvg back to sleep.


Test2:/# alt_rootvg_op -S altinst_rootvg
Putting volume group altinst_rootvg to sleep ...
forced unmount of /alt_inst/var
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/home
forced unmount of /alt_inst
Fixing LV control blocks...
Fixing file system superblocks...
The bootlist command confirms that you will reboot using the alternate rootvg disk (hdisk1).

Test2:/# bootlist -m normal -o
hdisk1 blv=hd5 pathid=0
hdisk1 blv=hd5 pathid=1

Test2:/# lspv
hdisk0        00d342e7131c6b47                  rootvg          active
hdisk1        00d342d637j21a59                  altinst_rootvg
Test2:/# 

you can use the same steps to get the os level information from old_rootvg as well.




Saturday, September 1, 2018

How to find out WWPN number of the HBA (FC) card in aix?

How to find out WWPN number of the HBA (FC) card in aix?


More often, We are in the situation to find out the wwpn number of the hba card in aix.

we are normally using "lscfg -vpl fcs(X)", or somebody using "lscfg -vpl fcs(X)|grep -i network"

But using the below for loop, we can easily identify all the hba card and its wwpn number of the server immediately.

Please keep this in your notepad, so that you can use it whenever it required.


for i in $(lscfg |grep fcs |awk '{print $2}'); do echo $i && lscfg -vl $i|grep Network;done


The output is like below. 

fcs0     Network Address.............10000000ABCD1234
fcs1     Network Address.............10000000EFGH4567
fcs2     Network Address.............10000000IJKL88900
fcs3     Network Address.............10000000ABEF4567