Technology Magazine Post: IBM AIX EXTENDING MIRRORING SYNCHRONIZING ROOTVG

From:

Technology Magazine

http://www.techmagazinez.com/2013/10/ibm-aix-extending-mirroring.html?spref=fb

IBM AIX : Extending Mirroring Synchronizing ROOTVG

 Usually we get an old_rootvg or altinst_rootvg volume group  after alt_disk backup, upgrade or migration. On this tutorial we will  detail the steps of removing altinst_rootvg , then extending rootvg  and Mirror rootvg with background synchronization.

Let’s  See

Step 1: List the PV with command lspv as below to see which PV hold the old_rootvg / altinst_rootvg  VG . On this example, you can see the altinst_rootvg on hdisk6
removing altinst_rootvg
Step 2:Now let remove  altinst_rootvg using alt_disk_install command with -X flag as below.
After removing altinst_rootvg
Step 3 : After removing altinst_rootvg  list again the PVs again now the hdisk6 become None.
Cleaning up AIX ALTINST
Step 4: Extending rootvg to include hdisk6 using extendvg( -f for force ) command as below and list PVs to verify  now it is part of rootvg. Now we can see hdisk6 is assigned to rootvg.
Cleaning up AIX ALTINST
Cleaning up AIX ALTINST
Step 5 : Now Mirror and Synchronized the rootvg VG using mirrorvg command with -S flag , which will run synchronization in background.
a) Before Mirroring LPs and PPs number is same means it is not mirrored yet.
Cleaning up AIX ALTINST
b) Mirroring using “mirrorvg –S rootvg .
Cleaning up AIX ALTINST
From the man page of mirrorvg
-S Background Sync Returns the mirrorvg command immediately and starts a background syncvg of the volume group. With this option, it is not obvious when the mirrors have completely finished their synchronization. owever, as portions of the mirrors become synchronized, they are immediately used by the operating system in mirror usage.
c) After Mirroring: It might take several minutes to sync LVs as you can see in the below lots of LVs are still in stale state
Cleaning up AIX ALTINST
d) After Full Sync The Out Put will be like below
Cleaning up AIX ALTINST
Step 6 : Re Create the boot image on both rootvg’s PV hdisk6 and hdisk7 and include in boot list.
bootlist -o -m normal
# output: hdisk7 blv=hd5

bosboot -ad hdisk7
# output: bosboot: Boot image is 22698 512 byte blocks.
bosboot -ad hdisk6
# output: bosboot: Boot image is 22698 512 byte blocks

bootlist -o -m normal   hdisk7 blv=hd5  hdisk6 blv=hd5
# output: hdisk7 blv=hd5
# output: hdisk6 blv=hd5

UPDATE: Kimber’s POWER Sys Ref Docs – 10/4/2013

Kimber has updated his POWER doc collections.

For those that will always have network connections whenever needing POWER docs:

http://pref.kimberc.com/public/p7.html

For those that are not assured of having network connectivity;  Doug Ranz has slipstreamed all the docs into standalone PDFs:

 p4:  http://www.RealityDistortionField.com/POWER4%20Install%20&%20Service%20Guides.pdf
p5:  http://www.RealityDistortionField.com/POWER5%20Sys%20Ref.pdf
p6:  http://www.RealityDistortionField.com/POWER6%20Sys%20Ref.pdf
p7:  http://www.RealityDistortionField.com/POWER7%20Sys%20Ref.pdf

 

AIX 6.1 TL7 introduced a new flag for the ‘lspv’ command which shows the unique id (UUID) of disks in additional columns of the lspv output.

AIX 6.1 TL7 introduced a new flag for the ‘lspv’ command which shows
the unique id (UUID) of disks in additional columns of the lspv
output.

This new ‘lspv -u’ is particularly useful in VIO environments using
VSCSI because the VIO client LPAR hdisk UDID contains the real UDID
from the VIO server hdisk.

For example on a client LPAR using VSCSI for the rootvg (merged
columns and spaces in the UDID are not a paste error):

Client LPAR # lspv -u
hdisk0          00000000fb8a0572                    rootvg          active      533E3E21360170E50202E5A5A0000025E50A12AB20F1746      FAStT03IBMfcp05VDASD03AIXvscsi8060a98a-0292-e2c9-0382-b5263f2a7e61

VIO1 # lspv -u
hdisk0          0000000017b33224                    rootvg          active              2A1135000C5005474B9C30BST9146853SS03IBMsas                          b98fed26-76da-f15c-45c9-b65a814e3d75
hdisk1          000000009c4ae1f9                    rootvg          active              2A1135000C500546FA9330BST9146853SS03IBMsas                          c3435ec2-3db2-6c0e-f14e-947243ba482d
hdisk2          000000000572fb8a                    None                                3E21360170E50202E5A5A0000025E50A12AB20F1746      FAStT03IBMfcp      a9be7b27-42fd-b0d6-a5ba-da61929cf4fc
hdisk3          0000000038963f05                    None                                3E21360170E50202E5A5A0000037350A526780F1746      FAStT03IBMfcp      7ed82295-3d9e-36dc-d6e9-e094d0d1a4ee

VIO2 # lspv -u
hdisk0          00000000b46edc87                    rootvg          active              2A1135000C5004CE6C7FF0BST9146853SS03IBMsas                          a36f5dae-8281-4df7-7fa7-e9fbf619c7d5
hdisk1          00000000605de1f9                    rootvg          active              2A1135000C5004CE6CF8F0BST9146853SS03IBMsas                          d1148dc8-ea98-a255-bf34-2921a56e8ca1
hdisk2          000000000572fb8a                    None                                3E21360170E50202E5A5A0000025E50A12AB20F1746      FAStT03IBMfcp      a9be7b27-42fd-b0d6-a5ba-da61929cf4fc
hdisk3          0000000038963f05                    None                                3E21360170E50202E5A5A0000037350A526780F1746      FAStT03IBMfcp      7ed82295-3d9e-36dc-d6e9-e094d0d1a4ee

Our client UDID contains the UDID from the VIO server with a prefix
and suffix:

client hdisk0: 533E3E21360170E50202E5A5A0000025E50A12AB20F1746      FAStT03IBMfcp05VDASD03AIXvscsi
vio1   hdisk2: ^^^^3E21360170E50202E5A5A0000025E50A12AB20F1746      FAStT03IBMfcp^^^^^^^^^^^^^^^^^

where ^ indicates the prefix and suffix added by the VIO server.

Using UDIDs the client can be cross referenced to the server quickly
with the most significant bytes of the UDID, in this case the middle
15 digits.

Historically to find the real LUN that a client is using in a VIO
environment would require the following steps for each VIO server:

– Obtain client hdisk parent vscsi device hardware location code and
LUN number
– Lookup on HMC which VIO server and slot the client vscsi device is
linked to
– Lookup vhost adapter on VIO server by slot number
– Lookup VSCSI mappings for vhost adapter to location hdisk on VIO server

A client with dual VIO would have to repeat the procedure twice. PVIDs
can also shortcut the process, but they may not show up on the VIO
server’s lspv output until after they are written to by the client and
the VIO server is rebooted. If the client rewrites the PVID, the VIO
server can also be out of date. Thus UDID’s are the preferred method
because they are static values.

The output can stretch the columns until they merge and spaces in the
UDID break the columns, which I hope is fixed in a future release.

 

——————————————————————
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

IBM PowerHA SystemMirror for AIX Adds Support for the New IBM Power7+ 710/730 (8231-E1D/E2D)

IBM PowerHA SystemMirror for AIX Adds Support for the New IBM Power7+ 710/730 (8231-E1D/E2D)

May 02, 2013IBM PowerHA SystemMirror for AIX* adds support for the new IBM Power7+ 710/730 (8321-E1D/E2D).

Please refer to the following information for support details.

Power 7+ 710/730 (8321-E1D/E2D)
AIX V6.1
AIX V7.1
PowerHA SystemMirror V6.1
PowerHA V6.1 TL 6
AIX V6.1 TL 8
PowerHA V6.1 TL 6
AIX V7.1 TL 2
PowerHA SystemMirror V7.1
PowerHA V7.1.2
AIX 6.1 TL 8
PowerHA V7.1.2
AIX V7.1 TL 2

Clients are advised to obtain the latest service updates for this support.

Notes:

  • Integrated Virtualization Manager (IVM) is also supported.

IBM Service can be obtained from the IBM Electronic Fix Distribution site at: 

http://www.ibm.com/support/fixcentral/

For questions or concerns, please send a note to HA Feedback at:

HA Solutions Feedback/Poughkeepsie/IBM or hafeedbk@us.ibm.com

* Trademark or registered trademark of International Business Machines Corporation.
Other company, product, and service names may be trademarks or service marks of others.

 

ALERT: AIX v6.1 TL8 SP1 missing requisite fileset – devices.pciex.151438c1.rte.6.1.7.15

This alert comes from my mentor, fix central will fix it sooner or later…

I personally just encountered a packaging error in the AIX v6.1 TL8 SP1 package on Fix Central web site. This was just released last week.

oslevel -s will NOT return 6100-08-01-12xx after completing update_all with no errors

oslevel -rl 6100-08 returns:

/ #===> oslevel -rl 6100-08
Fileset Actual Level Recommended ML
——————————————————
devices.pciex.151438c1.rte 6.1.7.0 6.1.7.15

oslevel -s returns:

6100-07-03-1207

Since the missing fileset update is actually part of TL7, you have to open a PMR to have them extract and send you the missing fileset update, or download the entire ML7 package just to extract the single missing fileset update.

FLRT Frequently Asked Question

Abstract: Where can one find the Fix Level Recommendation Tool for administrators of IBM Power Systems?

The Fix Level Recommendation Tool (FLRT) provides minimum recommended fix level information on key components of IBM Power Systems running the AIX and IBM i operating systems. FLRT can be useful for those who are planning to upgrade key components or for those wishing to verify the current health of a system. 

Fix Level Recommendation Tool: http://www14.software.ibm.com/webapp/set2/flrt/home

Flash Update: Update for AIX 7.1 and 6.1 Daylight Savings Time Issue

****UPDATE****

Abstract

Notice: This document was originally published March 2012. It has been updated to reflect the availability of formal service packs for the reported problem and to provide additional details.

THERE IS NO NEW DST ISSUE. UPDATES TO THIS DOCUMENT ARE TO PROVIDE MORE CLARIFICATION ON DETERMINING IF THIS PROBLEM AFFECTS YOUR SYSTEMS AND TO UPDATE THE LIST OF AFFECTED AIX LEVELS.

IF ACTION HAS ALREADY BEEN TAKEN FROM THE PREVIOUS UPDATE IN MARCH 2012 AND YOUR SYSTEMS ARE NOT AT ONE OF THE AFFECTED LEVELS IDENTIFIED IN THIS UPDATE, THEN NO FURTHER ACTION IS NEEDED.

AIX systems or applications that use the POSIX time zone format may not change time properly at Daylight Savings Time start or end dates. Applications that use the AIX date command, or time functions such as localtime() and ctime(), on these systems may be affected.

Systems and applications using the Olson time zone format are NOT affected. Do not take any action if you use Olson format.

————————————————————————————————-

Flash Update: Update for AIX 7.1 and 6.1 Daylight Savings Time Issue

IBM has updated the Alert (Flash) document with additional content, including information on additional levels affected. Click on the link for more information.

http://www.ibm.com/support/docview.wss?uid=isg3T1013017

Your system is using a POSIX format time zone and the system or an application on the system is using a custom DST setting.

Possible Action Required: System time may not change properly at DST start/end dates on AIX 7.1 and AIX 6.1

Flash (Alert)

Abstract

Notice: This document was originally published March 2012. It has been updated to reflect the availability of formal service packs for the reported problem.

AIX systems or applications that use the POSIX time zone format may not change time properly at Daylight Savings Time start or end dates. Applications that use the AIX date command, or time functions such as localtime() and ctime(), on these systems may be affected.

Systems and applications using the Olson time zone format are NOT affected. Do not take any action if you use Olson format.

Content

 

>>> Indicates changes made on 2012-10-24

Levels affected

If your country observes Daylight Savings Time, the information in this document may pertain to you. You should read this document carefully to determine if you need to take action.

This problem is exposed on your system if you have both of these underlying conditions:

  1. Your system is at one of the affected AIX levels (listed below)
  2. Your system is using a POSIX format time zone

AIX levels affected

The following AIX levels are the only levels affected by this issue. If your system is not at one of these levels, do not take any action.

  • 7100-01-03-1207
  • 7100-01-02-1150
  • 7100-01-01-1141
  • 6100-07-03-1207
  • 6100-07-02-1150
  • 6100-07-01-1141
  • >>> 6100-06-07-1207
  • 6100-06-06-1140
  • >>> 6100-05-08-1207
  • 6100-05-07-1140
  • 6100-04-11-1140

Determining if you are using the POSIX Time Zone format

If your system is at one of the affected AIX levels, you need to evaluate whether you are using the POSIX time zone format or the Olson time zone format.

POSIX time zone format is the traditionally used format for AIX systems and provides a slight performance advantage over the Olson time zone format. The capability to use the Olson time zone format was initially included with AIX 6.1 in 2007.

If your system is not using POSIX time zone format OR your system is not at one of the affected AIX levels, then your system is not exposed to the problem and you do not need to take action.

To determine if you are using the POSIX time zone format, enter this command:
echo $TZ

Sample results Description
Europe/Paris Your system is using Olson time format and your system is not affected by this problem.
CET-1CEST
GMT0BST
EST5EDT
Your system is using POSIX time zone format.
CET-1CEST,M3.5.0/02:00:00,M10.5.0/03:00:00 Your system is using the POSIX Time format with customized Daylight Savings Time override values.

When to take action

If your system is using POSIX time zone format and is at one of the affected AIX levels and you observe a Daylight Savings Time change then you need to take action before your next change.

How does this problem affect my applications?

Applications that are sensitive to time and date information may be negatively affected on AIX systems using the POSIX time zone format. Examples of applications that are time sensitive include SAP and Tivoli Workload Scheduler. The AIX date command is also affected.

If you use Olson time zone format, your applications are not affected. Do not take any action.

Recommended actions

Do one of the following options.

Option 1. Change the time zone to use Olson format

Change the time zone format to use Olson format instead of POSIX format.

You MUST reboot to ensure that applications see the changes, regardless of your AIX level. The changes are stored in /etc/environment and are loaded at boot time. See the man page for the chtz command or use smitty chtz_date. More information about the use of Olson time format is included below

OR

Option 2. Install the appropriate Service Pack

If changing your system to use Olson time zone format is not an option for you, you can install a service pack.

Installing the service pack requires that you reboot. If you have previously installed an iFix for this problem and you choose to install a Service Pack, you will be required to deinstall the iFix first. For instructions on deinstalling an iFix, read Managing Interim Fixes on AIX.

Downloadable packages
Level APAR Service Pack Requires reboot?
7100-01-03-1207 IV16514 7100-01-04 or higher Yes
7100-01-02-1150 IV16514 7100-01-04 or higher Yes
7100-01-01-1141 IV16514 7100-01-04 or higher Yes
6100-07-03-1207 IV16587 6100-07-04 or higher Yes
6100-07-02-1150 IV16587 6100-07-04 or higher Yes
6100-07-01-1141 IV16587 6100-07-04 or higher Yes
>>> 6100-06-07-1207 IV16567 6100-06-08 or higher Yes
6100-06-06-1140 IV16567 6100-06-08 or higher Yes
>> 6100-05-08-1207 IV16568 6100-05-09 or higher Yes
6100-05-07-1140 IV16568 6100-05-09 or higher Yes
6100-04-11-1140 IV16569 Not available *

(*) Normal service ended for this level on November 2011. IBM recommends upgrading to a higher AIX 6.1 level or migrating to AIX 7.1.

Do I have to reboot?

Yes. Both the Option 1 and Option 2 require a reboot.

VIOS potential impact is minor

The PowerVM Virtual I/O Server (VIOS) is also affected by this problem but the potential impact is reduced because only VIOS times would be affected.

Olson time zone format versus POSIX time zone format

The TZ environment variable is used to represent time zone information. The value of TZ can be specified in one of the two formats in AIX: POSIX or Olson.

POSIX format specification

The TZ variable specified in POSIX format contains all the information required to identify time zone, specify when to switch DST on and off, and specify the offset from UTC (Universal Time). Note that the system internally does everything in UTC time, and any display of time to the users is a computed offset depending on the time zone and DST rules specified.

The advantage of POSIX is that you can easily and explicitly specify time zone and DST details manually, however you wish. The performance of applications that call time functions will be faster than using Olson specification. And whenever a nation’s government decides to change its DST rules, the POSIX format is simpler because you can simply change the variable definition. There is no need to install of any new patch to update time database files, as Olson requres.

Note: Clients using POSIX time format in regions that do not use the US DST time change will always use Customized override values for Daylight SavingsTime because the default POSIX time zones change DST on the US dates.

A disadvantage with the POSIX is that it cannot track the history of time zone-related changes. When a government changes the rules and you update your TZ variable, it is assumed to be the same DST rule for all years past and future. Another disadvantage is pure readability: Olson uses known names of Cities or Regions, while POSIX format may look cryptic to anyone unfamiliar with it.

Olson format specification

This style of specification overcomes the disadvantages of the POSIX approach. In this method a database is maintained for each time zone, with details of history of time zone and DST changes. You can specify the time zone name in a simple, more human-friendly format, such as “America/Sao_Paulo” rather than specifying the more complex TZ=GRNLNDST3GRNLNDDT,M10.3.0/00:00:00,M2.4.0/00:00:00.

The advantage with this approach is that the time zone name is easy to specify and Olson keeps a history of time zone and DST related changes.

The disadvantage with this approach is that Olson has to load the database file for each time zone specified, and then parse it to find the time zone and DST details. This process can have a modest performance penalty compared to POSIX format . Additionally, when a government changes a time zone or DST rule, a new patch becomes necessary for the Olson time database file.

Olson time zone format has been available in AIX since Version 6.1 in 2007 and has been in use in client environments for many years.

Additional information on AIX levels at risk

To determine if your system is at risk, run the following commands and evaluate the output against the list of affected levels .

lslpp -Ou -qlc bos.rte.date
lslpp -Ou -qlc bos.rte.libc

If any filesets match any of the following levels, you are at risk.

Affected levels
libc Library Date Control Commands AIX oslevel -s
bos.rte.libc 7.1.1.2 bos.rte.date 7.1.1.2 7100-01-03-1207
bos.rte.libc 7.1.1.1 bos.rte.date 7.1.1.1 7100-01-02-1150
bos.rte.libc 7.1.1.0 bos.rte.date 7.1.1.0 7100-01-01-1141
bos.rte.libc 6.1.7.2 6100-07-03-1207
bos.rte.libc 6.1.7.1 6100-07-02-1150
bos.rte.libc 6.1.7.0 6100-07-01-1141
>>> bos.rte.libc 6.1.6.17 6100-06-07-1207
bos.rte.libc 6.1.6.16 6100-06-06-1140
>>> bos.rte.libc 6.1.5.8 6100-05-08-1207
bos.rte.libc 6.1.5.7 6100-05-07-1140
bos.rte.libc 6.1.4.10 6100-04-11-1140

TIP: VIO Server level 2.2.1.4: “lspv -free” command has been redesigned

This info was just posted today 10/5/2012 on Linked In Group “AIX and POWER System Administrators”. I’ve edited to remove most editorial comments and leave the technical facts.

VIO Server level 2.2.1.4

The command ‘lspv -free’ has been redesigned to no longer show disks which have a VGID. So in brief, any disk that has ever been used will no longer be shown as free, even if you have intentionally freed the disk, unless you specifically overwrite the VGID.  IBM claims to have done this to support knowing when a disk is in use by various types of clusters outside of the knowledge of the specific VIO server. The documentation clearly states that this option, “Lists only physical volumes that are available for use as a backing device.” However, with this new change it does not do that. IBM’s response so far is that they may have to change the documentation to match the new design of the command.